And better alternatives exist - like qmail and djbdns. Is there any reason to run those pieces of shit besides legacy config files?
To quote the Makefile for/usr/ports/mail/qmail:
NO_PACKAGE= djb's packaging license does not allow non-standard qmail binary distributions
I would guess this is a big showstopper for using qmail in the FreeBSD basesystem. However, I think it was recently added some glue to sysinstall to let you choose MTA during install.
Guys, what happens if I remove a piece of software after it's been installed and lots of other software depends on it. Will "Ports" warn me about what will break, or will it just go ahead and do it, and leave me scratching my head trying to figure out what happened?
It will warn you that there are other ports depending on this port. However you can forcefully remove it if you wish (and then you're on your own..)
Maybe FreeBSD should add a single file, like/etc/with.conf, where all of those WITH_FOO=yes knobs are listed and which is sourced before each port is build. So portupgrade would respect those, too
You do know that portupgrade reads the/usr/local/etc/pkgtools.conf file when upgrading, reinstalling, etc ports? This is a excellent place to put your WITH_* knobs. There's even a few examples in the file to get you going..
Also, I believe they can be put in/etc/make.conf, but then they will be global and will be used for all ports!
The scheduler is far from finished, and would likely need a lot more work. Integrating it into 5.0-CURRENT (and bringing in the SMP support along with it) is already under way, but could probably take some time.
Slashdot Mirror
To quote the Makefile for /usr/ports/mail/qmail:
NO_PACKAGE= djb's packaging license does not allow non-standard qmail binary distributions
I would guess this is a big showstopper for using qmail in the FreeBSD basesystem. However, I think it was recently added some glue to sysinstall to let you choose MTA during install.
You do know that portupgrade reads the
Also, I believe they can be put in
I might be way wrong here, but I thought the SMP machines had cache-coherence so that this sort of problem shouldn't occur?
The tcp_syncache.c sonewconn() panic is supposedly reproducable on 4.7 too.
The scheduler is far from finished, and would likely need a lot more work. Integrating it into 5.0-CURRENT (and bringing in the SMP support along with it) is already under way, but could probably take some time.
I belive there is an NFS client called "Omni NFS", try looking at their webpage
There is a Outlook Express (and Internet Explorer) version available for Solaris (SPARC) and HP-UX.