We've been hearing about new TLDs for almost two years now. I think we desperately need them. Domain names need to map (at least somewhat loosely) onto international trademark law so that McDonalds.food and McDonalds.bank don't conflict in any way. Trademark law is built around the concept of avoiding consumer confusion.
But I remain sceptical. ICANN has a difficult job, no doubt about it. But so far, they haven't managed to make much progess.
Albuquerque is remote but it's not that remote. New Mexico is poor and as a result we have suffered from poor connectivity. That's no one's fault but it is shortsighted.
I'm not aware of ATT currently offering connections to anyone locally. The pop you are referring to must be brand-new or not yet active.
That said, I work for a company (osogrande.net) that does have UUnet and Qwest connectivity. You don't have to resort to the Verios of the world just to get Internet connectivity in Albuquerque. You also don't have to pay $10K extra per month for a DS3 (you just have to negotiate well;-).
As an aside, John Brown moved back here from California about 3 years ago, so he does know what he's missing.
It's amusing to see John Brown complaining about not being able to get UUnet service in New Mexico. we've managed to do it and it didn't cost $10K/month for the backhaul into Phoneix. We've got DS3-level connections To Qwest and UUnet in Albuquerque.
I'm not saying there is no problem. Clearly there is. But whining about things that clearly are available is not going to solve the issue.
...And one more thing: I thought that TurboLinux had come under significant criticism for failing to GPL their clustering software (which was alleged to bear some resemblance to the Linux Virtual Server technology which RedHat started to package in 6.x and is open source).
The VP of Marketing here contends that "...it's all GPLed". Is he right?
Let me just say that I believe that Open Source companies will find development models and sales models that work. On the other hand...
This is two high-profile Linux companies with significant lay-offs in a short amount of time. With Redhat, Caldera and even (somewhat) VA Linux stock in the toilet right now, things don't look all that rosy for some open source camps. That's the bad news.
The good news is that I think realistic business models and business plans are, on the whole, good for everyone, including Open Source. Companies like Redhat and VA Linux were always more focused on product quality and value to customers (and delivering on a plan) than going public and making money quick on the NASDAQ (even though it turned out that way for those two). I think that as more organizations do some belt-tightening, the overall tone of the high-tech and open-source economy will improve.
Businesses with good products and services and a plan to deliver them to people who want them for reasonable prices deserve to survive. Other businesses don't. That's just the way it is.
This is a sad, sad state of affairs (but the experiences that the author describes are far from uncommon). The reality is that as long as a single organization gets to mediate access to the physical copper plant *and* to make money off of advanced services provided on that plant.
We all paid for the copper decades ago. In fact, we paid for it again, because of some creative acconting that the Baby Bells (RBOCs) used in the late 90s (96-97) becuase they convinced regulators and auditors that they were planning on replacing the entire copper plant with fiber and so they should be able to write the whole thing off since it was worthless. Copper. Worthless. You know how DSL gets into your house? Copper. Hmmmmmm.
I work at an ISP that provides DSL from three different carriers, two of them CLECS (competitive local exchange carriers) and one an RBOC (regional bell operating company - US West). The three-party problems that the author described have been made *much* worse by Covad's unwillingness to deal directly with smaller ISPs (they now want a minimum 20,000 - 25,000 line commitment) so most of the people providing Covad DSL don't have a relationship with Covad; they are reselling DSL services from some other regional ISP (increasing the problems to 4 parties!).
One thing we keep telling commercial customers who are compelled by the low prices of DSL: When your T1 line goes down we have a $200-400 / month stick to beat up the phone company with. Mean time to respond for us (we have hundreds of circuits) is about 1 hour, mean time to repair is about 2 hours. When your DSL line goes down we have a $19 / month stick to beat up the phone company with and we can't even talk to them. We have to call the DSL carrier who has to beat them up with the $19 twig. It takes a week. Sometimes longer.
This is the key problem with DSL: enterprise speeds with romper room repair times. In the the current setup there is no obvious way to fix it.
It's unfortunate that this issue is going to be confused by the fact that the censorware caused it. This will leave many network administrators with the impression that as long as they are not doing content-based filtering or blocking, they're ok.
In fact, this is the first remote-root exploit in a commercial firewall in a long time and it is due entirely to the fact that commercial vendors are under pressure by the market to throw the damned kitchen sink into their products. Firewalls need to be simple enough to be auditable. Simple enough to be understandable by a human at a time and place by herself.
Commercial firewalls like Checkpoint's FW1 and Gauntlet (among many other offenders) are selling like hotcakes for bad reasons. Smart organizations are implementing simpler solutions like OpenBSD-based ipfilter (Darren Reed's well-tested stateful packet filtering running on Theo Raadt's well-audited kernel). They are then (as other folx have suggested) supplementing with things like squid for proxying (and hopefully on a box separate from the firewall!) and even still using things like the TIS toolkit (now from NAI but originally authored by Marcus Ranum. Smart organizations run secure MTAs like qmail and do virus filtering on the mail server only if they have to (it's a task better taken care of at the client, IMHO).
These are not fancy tools, but they perform their objectives simply enough that they can be trusted.
Security should not be about features, ever. It should be about verifiability and trustworthiness.
I'm a little bit surprised that it's a cobalt and it's running a 2.0 kernel. I had thought that the Cobalt stuff had all migrated to 2.2 at this point (I know that they stuck with 2.0 for quite a while, but it's been quite a while). We have a raq3i here running the 2.2(.5, it looks like) kernel. Maybe the qubes are still at 2.0, though.
They are really excellent little boxes for people who don't know what they're doing (they're underpowered and kindof annoying for people who do, but that's a separate story). We use them for schools and small offices that don't have an on-site network administrator but want to get local mail and drive sharing. The fact that they do smb, nfs *and* appletalk is the big selling point for some places.
The big gripe: why the hell don't they do print spooling? It's not hard to do (basically you get the lpd srpm from redhat, you rebuild (because most of the boxes are MIPS, you install and you configure. not rocket science). This is something that lots of offices need and they just don't do at all, as far as I know. annoying.
very interesting article. it starts by addressing the first yucky thing i found about python (that whitespace and indentation actually *matter*!). it goes on to convince me that this is a language i really need to learn.
There are seriously cool things making their way into the kernel these days. My two favorites are LVM (the logical volume manager: Heinz Maushagen's baby that mimics the capabilities of HPUX and AIX logical volume managers; more info at http://linux.msede.com/lvm/) and ReiserFS (ok, not really in yet, but they're making great progress).
But there are major problems with really fundamental stuff left. The VM system has been undergoing somewhat fundamental changes in the past week and a half. If 2.4 comes out any time in the next month, I'm waiting for 2.4.5 or 2.4.10 before I put this thing into production.
Still, with the rewritten pci device interface and cleaner APIs to a bunch of kernel functionality, I'm more excited than ever to start working with the new kernel in development mode at least.
Interestingly enough, Eric Raymond just yesterday posted that he has produced a beta version of a new configuration and build management system for the kernel.
Since he's known for metalanguages and minilanguages (computer languages of minimal scope), not surprisingly, he rewrote the configuration management language used to control kernel builds.
Two relevant points here, though:
1) I don't think that this will help your situation of *installing* rather than *building* a new kernel.
2) It's written in Python. If you read ESR's piece in Linux Journal last month, this is no surprise at all, but the reception on the kernel list was decidedly cool, on balance. ESR held his own with arguments about 'freeze' which can produce compilable C code from a python program (albeit somewhat inelegantly) and arguments about the existing perl and tk/tcl dependencies that are already in the kernel build system, but there was still widespread (and sometimes unprincipled) opposition to the whole idea of using Python at all.
I doubt that the new config system will get incorporated until 2.5, though.
When Linuxcare was expanding from 30 to 200 employees over the course of a six-month period, people with good Linux skills should have been snapped up (since all the while Linuxcare was complaining about the lack of qualified employees).
This really was a case (cited in the article) of poor business practices and poor execution.
Do you know the *massive* amounts of money they spent on wacky, closed-source server technology for their knowledge base and other IT projects? (which, I might add, didn't work very well).
At least one of the problems that Linuxcare has had is the use of closed source technology (their CTO came from e*Trade, if I recall correctly, where he built a massive (and verrrrryyyy slow) electronic trading infrastructure entirely on Java and some other proprietary technologies. Linuxcare was always hindered by the use of closed technologies in its efforts.
The other problems plague most start ups: growing too fast, no direction, wasting money. I had a friend who positively had to *work* to get hired by Linuxcare (and he was pretty qualified). They have been funding some open source projects but don't appear to have a theory of why. They have hired some famous people but with no particular rhyme or reason.
Anyway, it should be interesting to continue watching them. I think they can pull it off, but it will not be easy.
That's exactly the trouble, though: speech and action are *very* difficult to tell apart. From a practical standpoint, the supreme court has a host of rulings about this (ranging from the basic: shouting 'fire' in a crowded theatre is ruled to be action, not speech).
at a more academic level, catherine mackinnon has some excellent writing on this issue (regardless of whether you agree with her points about pornography or not, she is a brilliant legal theorist and the speech-action division is a central area of interest).
blythly commenting that speech is one thing and action another does not make the two easy to distinguish.
I know that most./ers are avid free-speechers (and, for the most part, I am, too).
I think, however, that free speech proponents have a hard time dealing with the perniciousness that has been the nazi movement throughout this century. The French (and Germans) are understandably much more sensitive on this issue than Americans (having undergone the holocost more directly than most of us). The understand the way in which speech directly contributed to the rise of Naziism.
We need to figure out a way to deal with this kind of European feeling while still honoring our own freedom of speech tenants (which, on the whole, work well in free societies).
Excellent piece. I enjoyed the narrative and have been wondering about the RH certification process, so it was good to know more about it.
I had never seen the service script and so immediately tried it. It didn't work on my RH6.1 system (They've fixed it in 6.2, but 6.1 is totally broken).
The line:
elif [ -x "/etc/rc.d/init.d/$1" ]; then "/etc/rc.d/init.d/$1" $*
had to be changed (since $* *includes* $1. duh!) i fixed this with:
elif [ -x "/etc/rc.d/init.d/$1" ]; then "/etc/rc.d/init.d/"$*
but in RH6.2 they've changed it to:
elif [ -x "/etc/rc.d/init.d/$1" ]; then "/etc/rc.d/init.d/$1" "basename \"$0\""
anyway, great review.
Free BSD with trusted base without OpenBSD audit
on
TrustedBSD Announced
·
· Score: 1
The only question I have is why they wanted to base this on FreeBSD instead of OpenBSD. Last I checked FreeBSD and NetBSD both had "sub-optimal" code that had been fixed during the OpenBSD audit.
I know lot's of people are nervous about Linuxcare. The have a mixed reputation of employing open source in their own shop and have often seemed more hype than substance. I, for one, question the business model of being able to provide high quality support services for Linux, Apache, PHP, Perl, etc. without actively participating in the development of the technologies.
Other people clearly do, too (including at Linuxcare). That's why Redhat employs kernel developers. That's why Linuxcare have hired Andrew Tridgell and Rasmus Lerdorf and other developers of open source projects.
They have a fantastic idea for how to do this stuff (execution is a different story): hire good developers, project managers, trainers and techical writers; get them to produce new products using open source technologies; give the products away (open source, remember?); sell support. This model is a good one and can work, but in order to work, Linuxcare needs the credibility of several high-profile, really useful open source projects. I have heard about one or two failed projects so far, but haven't seen anything concrete yet.
All great developers have crappy personalities. djb (Daniel Bernstein, of qmail fame) is high on the list of "the usual buttheads". the problem is that he is always right. Wietse Venema is a jerk lots of the time. even linus (who is positively easy going compared to djb) can be pretty acerbic and short with people.
who cares? choosing your OS or MTA by the personality of the developer is just backwards. evaluate the code, evaluate the features. people who are on a mission are obnoxious but do good work (except for the kooks). the rest of us should just learn to live with that.
ipfilter doesn't run on modern versions of linux (there are some patches to get it to compile under libc5 i think, but no glibc at all, eg).
so the next question becomes what variant of BSD do you want to run. if you're running a general purpose server or workstation, FreeBSD seems appropriate: full featured, well configured and basically solid. But if you're running ipfilter, you don't care about what *does* run on the box, you care about what *doesn't*.
OpenBSD has been thoroughly audited by some very paranoid people for a long time. that makes me feel much better about my firewalls.
The main reason that we use OpenBSD for firewalls is the presence of ipfilter. the stateful inspection of ipfilter makes it easier to configure secure firewalls and is the only way of configuring securely in certain kinds of conditions (windows, for example, treats an incoming packet with SYN+ACK as a SYN and cheerfully opens the connection, so unless you have state on your firewall, you won't catch that the connection doesn't already exist).
ipfilter doesn't work on modern linuxes because of the lack of support of the bpf (berkely packet filter) hack.
What happens with the Daniel J. Bernstein (djb of qmail, tcp syncookies, etc. fame) case? The last I heard, the case was in dubious standing as a result of the recent changes in cryptography regulations (in fact, the way I recall it, the case was pending only because djb was concerned about the speech issues rather than the export issues since you still have to apply for an export permit.
This ruling will certainly get challenged and possibly overruled on appeal anyway... (cynically speaking).
Cobalt has seen a number of fairly serious security problems in the past six months. Since a NetBSD port is now done, an OpenBSD port cannot be far behind.
OpenBSD is my favorite, secure out-of-the box distro for general purpose, outside the firewall use.
Then again, the Cobalt hardware is far from cheap, given what it is. What you're really paying for is the integration and ease of management. Get ride of that, and I'll take a cheap intel clone in a rackmount case any day.
Slashdot Mirror
We've been hearing about new TLDs for almost two years now. I think we desperately need them. Domain names need to map (at least somewhat loosely) onto international trademark law so that McDonalds.food and McDonalds.bank don't conflict in any way. Trademark law is built around the concept of avoiding consumer confusion.
But I remain sceptical. ICANN has a difficult job, no doubt about it. But so far, they haven't managed to make much progess.
Albuquerque is remote but it's not that remote. New Mexico is poor and as a result we have suffered from poor connectivity. That's no one's fault but it is shortsighted.
;-).
I'm not aware of ATT currently offering connections to anyone locally. The pop you are referring to must be brand-new or not yet active.
That said, I work for a company (osogrande.net) that does have UUnet and Qwest connectivity. You don't have to resort to the Verios of the world just to get Internet connectivity in Albuquerque. You also don't have to pay $10K extra per month for a DS3 (you just have to negotiate well
As an aside, John Brown moved back here from California about 3 years ago, so he does know what he's missing.
I'm not saying there is no problem. Clearly there is. But whining about things that clearly are available is not going to solve the issue.
...And one more thing: I thought that TurboLinux had come under significant criticism for failing to GPL their clustering software (which was alleged to bear some resemblance to the Linux Virtual Server technology which RedHat started to package in 6.x and is open source).
The VP of Marketing here contends that "...it's all GPLed". Is he right?
Let me just say that I believe that Open Source companies will find development models and sales models that work. On the other hand...
This is two high-profile Linux companies with significant lay-offs in a short amount of time. With Redhat, Caldera and even (somewhat) VA Linux stock in the toilet right now, things don't look all that rosy for some open source camps. That's the bad news.
The good news is that I think realistic business models and business plans are, on the whole, good for everyone, including Open Source. Companies like Redhat and VA Linux were always more focused on product quality and value to customers (and delivering on a plan) than going public and making money quick on the NASDAQ (even though it turned out that way for those two). I think that as more organizations do some belt-tightening, the overall tone of the high-tech and open-source economy will improve.
Businesses with good products and services and a plan to deliver them to people who want them for reasonable prices deserve to survive. Other businesses don't. That's just the way it is.
This is a sad, sad state of affairs (but the experiences that the author describes are far from uncommon). The reality is that as long as a single organization gets to mediate access to the physical copper plant *and* to make money off of advanced services provided on that plant.
We all paid for the copper decades ago. In fact, we paid for it again, because of some creative acconting that the Baby Bells (RBOCs) used in the late 90s (96-97) becuase they convinced regulators and auditors that they were planning on replacing the entire copper plant with fiber and so they should be able to write the whole thing off since it was worthless. Copper. Worthless. You know how DSL gets into your house? Copper. Hmmmmmm.
I work at an ISP that provides DSL from three different carriers, two of them CLECS (competitive local exchange carriers) and one an RBOC (regional bell operating company - US West). The three-party problems that the author described have been made *much* worse by Covad's unwillingness to deal directly with smaller ISPs (they now want a minimum 20,000 - 25,000 line commitment) so most of the people providing Covad DSL don't have a relationship with Covad; they are reselling DSL services from some other regional ISP (increasing the problems to 4 parties!).
One thing we keep telling commercial customers who are compelled by the low prices of DSL: When your T1 line goes down we have a $200-400 / month stick to beat up the phone company with. Mean time to respond for us (we have hundreds of circuits) is about 1 hour, mean time to repair is about 2 hours. When your DSL line goes down we have a $19 / month stick to beat up the phone company with and we can't even talk to them. We have to call the DSL carrier who has to beat them up with the $19 twig. It takes a week. Sometimes longer.
This is the key problem with DSL: enterprise speeds with romper room repair times. In the the current setup there is no obvious way to fix it.
It's unfortunate that this issue is going to be confused by the fact that the censorware caused it. This will leave many network administrators with the impression that as long as they are not doing content-based filtering or blocking, they're ok.
In fact, this is the first remote-root exploit in a commercial firewall in a long time and it is due entirely to the fact that commercial vendors are under pressure by the market to throw the damned kitchen sink into their products. Firewalls need to be simple enough to be auditable. Simple enough to be understandable by a human at a time and place by herself.
Commercial firewalls like Checkpoint's FW1 and Gauntlet (among many other offenders) are selling like hotcakes for bad reasons. Smart organizations are implementing simpler solutions like OpenBSD-based ipfilter (Darren Reed's well-tested stateful packet filtering running on Theo Raadt's well-audited kernel). They are then (as other folx have suggested) supplementing with things like squid for proxying (and hopefully on a box separate from the firewall!) and even still using things like the TIS toolkit (now from NAI but originally authored by Marcus Ranum. Smart organizations run secure MTAs like qmail and do virus filtering on the mail server only if they have to (it's a task better taken care of at the client, IMHO).
These are not fancy tools, but they perform their objectives simply enough that they can be trusted.
Security should not be about features, ever. It should be about verifiability and trustworthiness.
I'm a little bit surprised that it's a cobalt and it's running a 2.0 kernel. I had thought that the Cobalt stuff had all migrated to 2.2 at this point (I know that they stuck with 2.0 for quite a while, but it's been quite a while). We have a raq3i here running the 2.2(.5, it looks like) kernel. Maybe the qubes are still at 2.0, though.
They are really excellent little boxes for people who don't know what they're doing (they're underpowered and kindof annoying for people who do, but that's a separate story). We use them for schools and small offices that don't have an on-site network administrator but want to get local mail and drive sharing. The fact that they do smb, nfs *and* appletalk is the big selling point for some places.
The big gripe: why the hell don't they do print spooling? It's not hard to do (basically you get the lpd srpm from redhat, you rebuild (because most of the boxes are MIPS, you install and you configure. not rocket science). This is something that lots of offices need and they just don't do at all, as far as I know. annoying.
It took me a while to find it (the search engine on linuxjournal.com is really not what it should be!) but here's a link:
3 882.html
http://www2.linuxjournal.com/lj-issues/issue73/
very interesting article. it starts by addressing the first yucky thing i found about python (that whitespace and indentation actually *matter*!). it goes on to convince me that this is a language i really need to learn.
There are seriously cool things making their way into the kernel these days. My two favorites are LVM (the logical volume manager: Heinz Maushagen's baby that mimics the capabilities of HPUX and AIX logical volume managers; more info at http://linux.msede.com/lvm/) and ReiserFS (ok, not really in yet, but they're making great progress).
But there are major problems with really fundamental stuff left. The VM system has been undergoing somewhat fundamental changes in the past week and a half. If 2.4 comes out any time in the next month, I'm waiting for 2.4.5 or 2.4.10 before I put this thing into production.
Still, with the rewritten pci device interface and cleaner APIs to a bunch of kernel functionality, I'm more excited than ever to start working with the new kernel in development mode at least.
Interestingly enough, Eric Raymond just yesterday posted that he has produced a beta version of a new configuration and build management system for the kernel.
Since he's known for metalanguages and minilanguages (computer languages of minimal scope), not surprisingly, he rewrote the configuration management language used to control kernel builds.
Two relevant points here, though:
1) I don't think that this will help your situation of *installing* rather than *building* a new kernel.
2) It's written in Python. If you read ESR's piece in Linux Journal last month, this is no surprise at all, but the reception on the kernel list was decidedly cool, on balance. ESR held his own with arguments about 'freeze' which can produce compilable C code from a python program (albeit somewhat inelegantly) and arguments about the existing perl and tk/tcl dependencies that are already in the kernel build system, but there was still widespread (and sometimes unprincipled) opposition to the whole idea of using Python at all.
I doubt that the new config system will get incorporated until 2.5, though.
When Linuxcare was expanding from 30 to 200 employees over the course of a six-month period, people with good Linux skills should have been snapped up (since all the while Linuxcare was complaining about the lack of qualified employees).
This really was a case (cited in the article) of poor business practices and poor execution.
You're kidding, right?
Do you know the *massive* amounts of money they spent on wacky, closed-source server technology for their knowledge base and other IT projects? (which, I might add, didn't work very well).
At least one of the problems that Linuxcare has had is the use of closed source technology (their CTO came from e*Trade, if I recall correctly, where he built a massive (and verrrrryyyy slow) electronic trading infrastructure entirely on Java and some other proprietary technologies. Linuxcare was always hindered by the use of closed technologies in its efforts.
The other problems plague most start ups: growing too fast, no direction, wasting money. I had a friend who positively had to *work* to get hired by Linuxcare (and he was pretty qualified). They have been funding some open source projects but don't appear to have a theory of why. They have hired some famous people but with no particular rhyme or reason.
Anyway, it should be interesting to continue watching them. I think they can pull it off, but it will not be easy.
That's exactly the trouble, though: speech and action are *very* difficult to tell apart. From a practical standpoint, the supreme court has a host of rulings about this (ranging from the basic: shouting 'fire' in a crowded theatre is ruled to be action, not speech).
at a more academic level, catherine mackinnon has some excellent writing on this issue (regardless of whether you agree with her points about pornography or not, she is a brilliant legal theorist and the speech-action division is a central area of interest).
blythly commenting that speech is one thing and action another does not make the two easy to distinguish.
I know that most ./ers are avid free-speechers (and, for the most part, I am, too).
I think, however, that free speech proponents have a hard time dealing with the perniciousness that has been the nazi movement throughout this century. The French (and Germans) are understandably much more sensitive on this issue than Americans (having undergone the holocost more directly than most of us). The understand the way in which speech directly contributed to the rise of Naziism.
We need to figure out a way to deal with this kind of European feeling while still honoring our own freedom of speech tenants (which, on the whole, work well in free societies).
Excellent piece. I enjoyed the narrative and have been wondering about the RH certification process, so it was good to know more about it.
I had never seen the service script and so immediately tried it. It didn't work on my RH6.1 system (They've fixed it in 6.2, but 6.1 is totally broken).
The line:
elif [ -x "/etc/rc.d/init.d/$1" ]; then
"/etc/rc.d/init.d/$1" $*
had to be changed (since $* *includes* $1. duh!)
i fixed this with:
elif [ -x "/etc/rc.d/init.d/$1" ]; then
"/etc/rc.d/init.d/"$*
but in RH6.2 they've changed it to:
elif [ -x "/etc/rc.d/init.d/$1" ]; then
"/etc/rc.d/init.d/$1" "basename \"$0\""
anyway, great review.
The only question I have is why they wanted to base this on FreeBSD instead of OpenBSD. Last I checked FreeBSD and NetBSD both had "sub-optimal" code that had been fixed during the OpenBSD audit.
Interesting choice.
I know lot's of people are nervous about Linuxcare. The have a mixed reputation of employing open source in their own shop and have often seemed more hype than substance. I, for one, question the business model of being able to provide high quality support services for Linux, Apache, PHP, Perl, etc. without actively participating in the development of the technologies.
Other people clearly do, too (including at Linuxcare). That's why Redhat employs kernel developers. That's why Linuxcare have hired Andrew Tridgell and Rasmus Lerdorf and other developers of open source projects.
They have a fantastic idea for how to do this stuff (execution is a different story): hire good developers, project managers, trainers and techical writers; get them to produce new products using open source technologies; give the products away (open source, remember?); sell support. This model is a good one and can work, but in order to work, Linuxcare needs the credibility of several high-profile, really useful open source projects. I have heard about one or two failed projects so far, but haven't seen anything concrete yet.
I wish them well but It's wait-and-see for now.
All great developers have crappy personalities. djb (Daniel Bernstein, of qmail fame) is high on the list of "the usual buttheads". the problem is that he is always right. Wietse Venema is a jerk lots of the time. even linus (who is positively easy going compared to djb) can be pretty acerbic and short with people.
who cares? choosing your OS or MTA by the personality of the developer is just backwards. evaluate the code, evaluate the features. people who are on a mission are obnoxious but do good work (except for the kooks). the rest of us should just learn to live with that.
ipfilter doesn't run on modern versions of linux (there are some patches to get it to compile under libc5 i think, but no glibc at all, eg).
so the next question becomes what variant of BSD do you want to run. if you're running a general purpose server or workstation, FreeBSD seems appropriate: full featured, well configured and basically solid. But if you're running ipfilter, you don't care about what *does* run on the box, you care about what *doesn't*.
OpenBSD has been thoroughly audited by some very paranoid people for a long time. that makes me feel much better about my firewalls.
The main reason that we use OpenBSD for firewalls is the presence of ipfilter. the stateful inspection of ipfilter makes it easier to configure secure firewalls and is the only way of configuring securely in certain kinds of conditions (windows, for example, treats an incoming packet with SYN+ACK as a SYN and cheerfully opens the connection, so unless you have state on your firewall, you won't catch that the connection doesn't already exist).
ipfilter doesn't work on modern linuxes because of the lack of support of the bpf (berkely packet filter) hack.
What happens with the Daniel J. Bernstein (djb of qmail, tcp syncookies, etc. fame) case? The last I heard, the case was in dubious standing as a result of the recent changes in cryptography regulations (in fact, the way I recall it, the case was pending only because djb was concerned about the speech issues rather than the export issues since you still have to apply for an export permit.
This ruling will certainly get challenged and possibly overruled on appeal anyway... (cynically speaking).
Cobalt has seen a number of fairly serious security problems in the past six months. Since a NetBSD port is now done, an OpenBSD port cannot be far behind.
OpenBSD is my favorite, secure out-of-the box distro for general purpose, outside the firewall use.
Then again, the Cobalt hardware is far from cheap, given what it is. What you're really paying for is the integration and ease of management. Get ride of that, and I'll take a cheap intel clone in a rackmount case any day.