Anybody working on removing sendmail from base?
dillon at apollo.backplane.com
Wed Oct 1 11:34:15 PDT 2003
: 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?
<dillon at xxxxxxxxxxxxx>
:hmp at xxxxxxxxxxxxx
More information about the Kernel