Re: Anybody working on removing sendmail from base?

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:	Err, ok, let's not get side tracked here guys.  It's like to be
:	"penny wise, and pound fool" -- it's the best way to put this.
:
:	We cannot keep supporting the old 486s for very long, just
:	because some 10% of the people still use it.  As new ideas
:...

    486 is easy to support, because the instruction set and segmentation
    model is basically the same as on the Pentium through the pentium 4.
    Also, the 486 model is still heavily used in the embedded space.

    I don't have a problem keeping old drivers around to support old machines
    as long as they do not intefere with new drivers, my concern is 
    basically about core kernel constructions.

    It's the 386 that we are not going to bother supporting any more.

:: I know it goes against the grain to think about a "real" or unix-like OS
:: shippig without a compiler, but at the same time, I know that there is no
:: need to have a compiler built in to the base system.
:
:	It might be good to remove GCC from the "source base", but it
:	is not a good idea to nuke GCC for a release, because that
:	just defies everything.
:
:	If you mean remove from "source base", i.e. no longer maintain
:	it in the CVS repo, then I agree, otherwise, I don't.  Our
:	release framework needs to be restructured in a way that it
:	will be able to fetch the required "third-party base utilities"
:	from the net (at release-build time) and then apply any local
:	patches we have.

    Yes, I agee with this too.  Obviously GCC is going to be part of the
    release, but it could very easily be moved out of the base source and
    into a port and we would version it the same way we would version any
    other major application and use variant symlinks (or similar entities)
    to 'set' the version the system uses, making multiple installed versions
    easy to manage.

    I would say that it is pretty obvious that the next thing we need to
    throw into the DragonFly kernel is variant-symlink support, as it appears
    to be becoming far more key to version control and ports then the VFS
    environments idea that I had.  I still think we will need VFS 
    environments, but it is obvious that variant symlinks will take care
    of 85% of the problem space.

    I am still working on the namecache code and will probably be working on
    the namecache code for a while, but this shouldn't stop others from
    investigating the variant-symlink idea more.

    I seem to recall that someone had variant symlinks working a number of
    years ago but that it never got accepted into FreeBSD.  Could someone
    try to dig up that info?

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>


:
:	Regards,
:
:-- 
:Hiten Pandya
:hmp@xxxxxxxxxxxxx