Slashdot Mirror

Here the REAL UPDATE: http://www.openbsd.org/

"Our improved and secured version of Apache 1.3"

Yeah, that's an update.

Yet another reason that validates OpenBSD developers having spent years improving the quality of random number generation.

Say what you want about Theo, but their developers are top-notch and their stuff really works.

All the ranting of Theo de Raadt doesn't seem so paranoid anymore.

"Freedom means you cannot dictate to anyone"

OpenBSD takes the approach of proactive code audits and of fixing all bugs found, even those that have no apparent potential for exploitation. This has really paid off over the years. Often when vulnerabilities came to light, they were found to not affect OpenBSD because the underlying bug had already been fixed.

So they're basically "reinventing" how BSD does things? They even blatantly copied an OpenBSD image for this presentation...

(Compare slide 13 from the presentation with OpenBSD 4.9 art)

In all seriousness though, it's a pretty good plan. Everyone knows that BSD means real engineering while Linux is "just a hobby, won't be big and professional"

What's the matter bubba? Windows got you down? Then check out OpenBSD!

OpenBSD: "Only two remote holes in the default install, in a heck of a long time!"

The OpenBSD project produces a FREE, multi-platform 4.4BSD-based UNIX-like operating system. Our efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography. ...and more!

Offer maybe be invalid in Soviet Russia, Cuba, Brigadoon, Shangri-La, Lands End, and certain other localities.

And now, back to our regularly scheduled post-a-grams, after this message ...

What's the matter bubba? Windows got you down? Then check out OpenBSD!

OpenBSD: "Only two remote holes in the default install, in a heck of a long time!"

The OpenBSD project produces a FREE, multi-platform 4.4BSD-based UNIX-like operating system. Our efforts emphasize portability, standardization, correctness, proactive security and integrated cryptography. ...and more!

Offer maybe be invalid in Soviet Russia, Cuba, Brigadoon, Shangri-La, Lands End, and certain other localities.

And now, back to our regularly scheduled post-a-grams, after this message ...

In general, people that use BSD contribute patches back because it is in their best financial interest to do so. Not because the license says they must, but because they want to. This generally leads to better quality patches too, in my experience

Yes that is nice of some however if a company want to keep additions and modifications to BSD licensed software a secret then it is their right as defined by the BSD License . Basically a take it and do anything you want with it although the license does require you to keep the license with the code. On the other hand the GPL (particularly GPL v3) license does not mind if you take the code and modify it however you are required under the terms of the GPL to provide the source of any modifications you make if the software is distributed outside of the company.

Prove that it too does, unfortunately: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/microcode/atmel/atu-license?rev=1.3;content-type=text%2Fplain

The one system I really wanted to run NetBSD on isn't supported (SGI Octane).

Try OpenBSD. OpenBSD forked from NetBSD in the 1990's and it supports SGI Octane.

http://www.openbsd.org/sgi.html

You might want to read this.

Don't forget CARP!

You can find links to OpenBSD mail archives at the bottom of this page.

That is actually not the logo of OpenBSD but FreeBSD. I don't know why that logo is put there. The OpenBSD logo is more like this.

Just time for fact checking...

>Do closed source people share code with BSD people? Nope.

Hmm. Strange, I'm guessing that means Apple doesn't release any source from what they do with BSD source, and BSDI never contributed SMP or anything like that to FreeBSD, and Juniper never contributed anything back.

Read the links, especially the last one.

> Do GPL people? Nope.

For the most part, correct...although there are a few who insist on not converting permissive source code (Luis Rodriguez is the main one .

>Are BSD users against closed code? Obviously not...

http://www.openbsd.org/lyrics.html#43

Start with bad data, you'll get bad results.

I came back several years later and there still aren't any security holes

http://www.openbsd.org/faq/pf/authpf.html

agree. we love old hardware for personal nostalgic reasons. which is why my backup MX/secondary DNS is still on a SparcStation 20 (running OpenBSD).

To the OP, I'd recommend running OpenBSD on it, as there are a lot of servers in the project that still run on Sparc boxen. Sparc64 support is top notch, and actually supports some machines that OpenSolaris (IllumOS) & Linux don't: http://www.openbsd.org/sparc64.html

It's not a race.

The Race is there to be run, for ourselves, not for others. We do what we do to run our own race, and finish it the best we can. We don't rush off at every distraction, or worry how this will affect our image. We are here to have fun doing right.

(source)

Everyone I know who runs CARP. Redundancy is good if you care about reliability/availability.

In college I had some fun running OpenBSD on a Sun Sparc Classic. Mostly used that machine as an SSH gateway.

The trick is to use OpenBSD's manpages. They actually get updated when the code changes, for the most part are relevant to other systems, and don't scold you for not using the texinfo manual.

Alright, here's my shtick... It's a great race between two open source software ecosystems: copyLEFT and copyFREE.

The copyFREE side is a more amicable pacifist bunch, with more freedoms and more choices, and it has been gaining ground in the last decade in all software categories but one - the kernels. The copyLEFT side was founded by a bunch of militant hippies trying to destroy capitalism, and it had several years' head start, so its viral licenses were grandfathered into some of the most important pieces of open source software. The OS projects within each team like to share code, and the copyLEFT team can also mooch copyFREE code as well, but not the other way around...

This race is contested on many fronts, and one obscure comparison (that I just came up with) is: while running the race forward, to still maintain support for the 80386 platform. Only UNIX systems (sorry, sorry, sorry) that can run on a 80386 PC (sorry, sorry) with actively maintained current versions (sorry) are to be included. Let's see how the two teams compare:

THE COPYLEFT TEAM:

(1) Linux - now i486, as mentioned in this article.

THE COPYFREE TEAM:

(1) FreeBSD - i486 since 2005.

(2) OpenBSD - i486 since 2007.

(3) NetBSD - i486, "80386 support removed" in 2007.

(4) MINIX 3 - i586, 32mb RAM, 635mb HD.

So it looks like the copyLEFT camp had this little "current UNIX on 80386" advantage, and now lost it...

--libman

Alright, here's my shtick... It's a great race between two open source software ecosystems: copyLEFT and copyFREE.

The copyFREE side is a more amicable pacifist bunch, with more freedoms and more choices, and it has been gaining ground in the last decade in all software categories but one - the kernels. The copyLEFT side was founded by a bunch of militant hippies trying to destroy capitalism, and it had several years' head start, so its viral licenses were grandfathered into some of the most important pieces of open source software. The OS projects within each team like to share code, and the copyLEFT team can also mooch copyFREE code as well, but not the other way around...

This race is contested on many fronts, and one obscure comparison (that I just came up with) is: while running the race forward, to still maintain support for the 80386 platform. Only UNIX systems (sorry, sorry, sorry) that can run on a 80386 PC (sorry, sorry) with actively maintained current versions (sorry) are to be included. Let's see how the two teams compare:

THE COPYLEFT TEAM:

(1) Linux - now i486, as mentioned in this article.

THE COPYFREE TEAM:

(1) FreeBSD - i486 since 2005.

(2) OpenBSD - i486 since 2007.

(3) NetBSD - i486, "80386 support removed" in 2007.

(4) MINIX 3 - i586, 32mb RAM, 635mb HD.

So it looks like the copyLEFT camp had this little "current UNIX on 80386" advantage, and now lost it...

--libman

People touching the source code of ANYTHING are rarer than unicorns.

Does that include furry unicorns? They're everywhere!

Seriously, I read code all the time. A good coder will do a lot more reading than writing, which is especially true of C and other non-obvious lower-level programming... OpenBSD code is a great epic read (skip the perl).

The majority of computer end-users are illiterates regarding anything related to computer stuff.

They still benefit from using open source components in various ways.

Even if only 0.1% of users will review the code, in most cases that's enough people to blow the whistle if there's a backdoor, etc. Of course proprietary software can be disassembled / virtualized / memory-dumped / and analyzed in a variety of ways, and I'm sure that most Microsoft software has had more eyeballs on it than most FLOSS software, but with equal popularity open source has the advantage.

Non-devs also benefit from being able to rent a coder from a freelancer site (usually in Outsourcistan, India) to conduct a security audit or make a change for them. Again, modding proprietary software is possible, and in many cases is easier than most people think (and even than its developers would have wanted), but still a bit more ugly and expensive.

With a "time-limited hybrid source" arrangement, you get the best of both worlds. The proprietary developer would hand over the code to a reputable third party, which would build the binaries for distribution while keeping the code safe till its due date. The dev would be able to sell it like any other piece of proprietary software and possibly profit from his innovations while they're fresh, but with the added advantage that the users would eventually get the code. The dev wouldn't be able to hide any surprises (excluding in BLOBs or brilliant feats of obfuscation), and the users would know that they would eventually be unencumbered in making any modifications they wanted.

Perhaps this is how intellectual monopolies should be phased out...

--libman

People touching the source code of ANYTHING are rarer than unicorns.

Does that include furry unicorns? They're everywhere!

Seriously, I read code all the time. A good coder will do a lot more reading than writing, which is especially true of C and other non-obvious lower-level programming... OpenBSD code is a great epic read (skip the perl).

The majority of computer end-users are illiterates regarding anything related to computer stuff.

They still benefit from using open source components in various ways.

Even if only 0.1% of users will review the code, in most cases that's enough people to blow the whistle if there's a backdoor, etc. Of course proprietary software can be disassembled / virtualized / memory-dumped / and analyzed in a variety of ways, and I'm sure that most Microsoft software has had more eyeballs on it than most FLOSS software, but with equal popularity open source has the advantage.

Non-devs also benefit from being able to rent a coder from a freelancer site (usually in Outsourcistan, India) to conduct a security audit or make a change for them. Again, modding proprietary software is possible, and in many cases is easier than most people think (and even than its developers would have wanted), but still a bit more ugly and expensive.

With a "time-limited hybrid source" arrangement, you get the best of both worlds. The proprietary developer would hand over the code to a reputable third party, which would build the binaries for distribution while keeping the code safe till its due date. The dev would be able to sell it like any other piece of proprietary software and possibly profit from his innovations while they're fresh, but with the added advantage that the users would eventually get the code. The dev wouldn't be able to hide any surprises (excluding in BLOBs or brilliant feats of obfuscation), and the users would know that they would eventually be unencumbered in making any modifications they wanted.

Perhaps this is how intellectual monopolies should be phased out...

--libman

I pledge allegiance to the mighty pufferfish.

And if there is something I don't like, I'll write my own or fork.

14.16 - Can I access data on filesystems other than FFS?
Yes. Other supported filesystems include: ext2 (Linux), ISO9660 and UDF (CD-ROM, DVD media), FAT (MS-DOS and Windows), NFS, NTFS (Windows). Some of them have limited, for instance read-only, support.
...

There are two replies to this:

1) OpenBSD supports tons of hardware. Click on one of the supported platforms. First you'll notice is OpenBSD runs on more than x86. Second, click through. You have to work hard to find a class of hardware that doesn't have some support. Most mainstream hardware is supported with many vendors to select from. When you do find missing hardware it's due to the point 2 below.

2) There may be some truth to the claim that Theo has pissed-off some vendors but it plays a small part. A more significant reason there aren't tons of corporate drivers for OpenBSD is the OpenBSD community won't accept any undocumented code (settings that use magic numbers), binary blobs (other than micro code or firmware) and won't sign NDAs to get the info. For code to go in the base it also has to be licensed under a BSD or ISC license.[1]

Many vendors want us to buy their hardware and trust their giant binary blob won't crash our systems. That's their call. Refusing to buy their hardware is ours.

Because of Theo's and the developer's stand against binary blobs OpenBSD base is one of the freest OSs you'll find. If that means a few missing drivers then so be it. Our systems run fine without them.

[1] The only GPL licensed code in base I can think of is gcc.

Ponderosa Puff wouldn't take no guff
Water oughta be clean and free
So he fought the fight and he set things right
With his OpenBSD

The most secure modern operating systems you can get are OpenBSD or FreeBSD. They are based on stable mature open source, and don't have the bloat and featureitus problems of Linux.

--libman

There's a lot of reasons to switch distros. Everyone usually finds one that fits their way of thinking after two or three. People also find that the different distros work better at different tasks - you don't (generally) use Ubuntu for servers, for instance.

As far as what I run on "my" computer, it hasn't changed much: Slackware -> Debian unstable. I knew Slackware inside and out (back in the 3.x days) and now I know Debian very well (you have to, if you run unstable). I've hit a comfort zone, and I'm unlikely to change.

I switched from Slackware to Debian because Slackware was very, very far behind on switching from the libc5 C library to glibc (the second major change in Linux, the first being the switch to ELF executable format). A lot of software was being written that didn't work with the old libc5, and Pat (the maintainer of Slackware) was being stubborn on the point. He had his reasons, but I wanted new software, so I switched.

I tried Corel Linux back when it came out. That lasted about two days. It didn't live up to its promises, and when I found myself replacing the Corel repositories with Debian repositories, I knew it was in vain (BTW, doing apt-get update && apt-get upgrade from Corel to Debian is... interesting. It worked, after a lot of fixing, but I finally wiped and reinstalled Debian). It's just as well - there was only the one version of Corel Linux.

I've had to use Red Hat (not Enterprise, but old school Red Hat Linux) on a few occasions for work-related reasons. This was back in the RPM dependency hell days, and it turned me off of any distro that doesn't maintain a decently large package repository. I used Fedora Core 4 and found it to be just as bad. Same goes for Mandrake (before they became Mandriva - I had friends who ran that because it was "user friendly" - I did not find it so. It might be better now, of course.

I've used Gentoo for shits and giggles on a server I run. I was just curious about it. I've since replaced it with OpenBSD because a) I didn't have the time to learn to admin it properly and b) compiling every package in the system on an Intel Atom chip is painful. (I already knew how to admin OpenBSD.) I liked Gentoo and if I ever replaced Debian as my main distro, it would be to go to Gentoo. I just don't have the time to learn a new system anymore.

I've done LFS. I highly recommend it to anyone who wants to learn more about the underpinnings of Linux. It reminded me a lot of my Slackware days, back when you had to compile everything.

Ubuntu works, and I've run it on a few machines, but doesn't fit into my way of doing things. I like to customize my system a lot, and I like to log in as root when I'm doing admin stuff. You can do that with Ubuntu, but it's just easier with Debian.

Of course, there's the BSDs and Solaris as well, and these days I mostly do server stuff on OpenBSD (or FreeBSD if it's a fileserver). The BSDs make excellent servers and don't feel as "hacked together" as Linux does. I wouldn't use one as my main system, but if I had a technical job again I wouldn't mind a FreeBSD desktop.

So the rite of passage isn't to find the most obscure distro, but to find the distro that suits both you and your use case best. Experimentation never hurts, and you can learn a lot from running different distros.

I checked their page, and while w/ KDE, they are still w/ 3.5.10, in the case of GNOME, they are w/ GNOME 3.2.1 in fallback mode. I thought that they are real conservative about which software versions they tend to use.

All packages for Fedora and Ubuntu, and I'd be massively surprised if the case wasn't the same for OpenBSD, are signed with a project key.

But that doesn't prevent you from creating your own packages. In fact, they explain how to make your own self-signed packages should you want to build your own internal package repository. It just stops you from releasing a package that looks like it's coming from OpenBSD.

This isn't analogous to the Secure Boot fiasco where it's significantly harder for end users to get their own signing keys, and therefore can't create their own signed bootloader that would act like the one that OpenBSD would be distributing.

If they want networking hardware, linux *ISN'T* the way to go.

Juniper, Cisco, others.... (I dunno anymore but there is I'm sure).

As you said yourself, you get what you pay for. If you buy crap, you'll get crap throughput.

Actually, that isn't true at all. Linux can compete toe to toe with Cisco, Juniper, Big Iron, and others. This is specifically why Vyatta has so much invested in it. Vyatta has come up with a Linux distro that is designed to replace this proprietary hardware. To boot, Vyatta has scored several major Fortune 500 players. Additionally, OpenBSD has routing facilities that are a force to be reckoned with. Several of my clients use Lenovo M71e's with OpenBSD as routers that I built. I replaced the traditional HD with an SSD and bought high-end intel networking boards. Contrary to "conventional" wisdom, these have been near perfectly reliable. They use BGP and IPSEC to interface with my Amazon VPC.

If you can set up your gateway to export Netflow data, you get excellent data for tracking your traffic (connection metadata) without all the bulk of keeping a full copy of the traffic.

There's a large number of tools available for collecting, analyzing and otherwise dissecting collected Netflow data, with a good number most likely available via your favorite free Unix-like operating system's packages collection. My favorite combo is to set up an OpenBSD box as the gateway, have it export traffic data via the pflow(4) facility and do the collection and analysis bits somewhere via nfdump/nfsen (see eg nfsen.sourceforge.net for info).

There are various resources available within direct reach of web search, but I would also recommend taking a look at Michael W. Lucas' book Network Flow Analysis for a nice treatment of Netflow in general (it uses flow-tools, but most of what he writes will be useful in the context of other tools too).

If you can set up your gateway to export Netflow data, you get excellent data for tracking your traffic (connection metadata) without all the bulk of keeping a full copy of the traffic.

There's a large number of tools available for collecting, analyzing and otherwise dissecting collected Netflow data, with a good number most likely available via your favorite free Unix-like operating system's packages collection. My favorite combo is to set up an OpenBSD box as the gateway, have it export traffic data via the pflow(4) facility and do the collection and analysis bits somewhere via nfdump/nfsen (see eg nfsen.sourceforge.net for info).

There are various resources available within direct reach of web search, but I would also recommend taking a look at Michael W. Lucas' book Network Flow Analysis for a nice treatment of Netflow in general (it uses flow-tools, but most of what he writes will be useful in the context of other tools too).

I hope Dell puts in a decent wireless card, that works in all GNU/Linux distributions. My current Dell laptop has an Intel WiFi card and it sucks. I have to use non-free firmware and even on Windows it behaves weird.

One of these would be great: Realtek, Ralink, Amtel, ADMTek, Atheros.

Edit: Specifically, "IPv6 code was merged into NetBSD in June 1999, and is part of NetBSD."

http://www.netbsd.org/docs/network/ipv6/

So there.

Okay, checked out that page. Seems to be more of a history lesson on IPv6 support in NetBSD. One key thing I noticed - all the BSDs, be it FreeBSD or NetBSD seem to prefer the autoconfiguration as far as IP addresses go, and typically don't support DHCP6. So anyone who has issues w/ EUI-64 is SOL. They mention that routers can't be autoconfigured, and that nodes should not be manually configured. But this is one of the reasons that DHCP6 is more important in IPv6 than DHCP4 was in IPv4.

I went back to check, KAME seems to have been imported into the kernel and released at 2.7, which was back in 2000. Not long behind NetBSD. http://www.openbsd.org/plus27.html

Okay, why does this page seem to suggest that Emacs and Libre Office are included? Very strange!

So you understand, they are included as in the sentence "iPhone includes Angry Birds".

It doesn't use the normal BSD license like other BSDs?

Other BSDs use it too. It removes unnecessary terms from the classic BSD license. OpenBSD uses a version the FSF doesn't aprove of as it could be interpreted by very obtuse lawyers to mean you can't distribute unmodified copies, which would be inconvenient the next time a GPL project lifts ISC code.

They don't include Emacs (instead mg is in base, rewritten from scratch with a funny easter egg inside) neither do they include Libre Office. It's just a Makefile and some patches that are distributed. Package are a convenience for the users, and available only if the license is 'free' enough (i.e legally possible). They want to switch to pcc instead of gcc, I've heard that Theo does that.

Okay, why does this page seem to suggest that Emacs and Libre Office are included? Very strange!

They are available as convenient packages but not included in base.

As a side note, OpenBSD uses the ISC license when i can now. Might be worth looking ;).

It doesn't use the normal BSD license like other BSDs?

New code in OpenBSD receives an ISC-like (don't ask) license, which is similar to the BSD license in spirit.

The truth about KDE: http://www.mail-archive.com/misc@openbsd.org/msg88679.html I also remember them coming to misc and inform the community and porters that KDE won't run on openbsd due to the use of a cool linux daemon to manage stuff.

This was said to be true about GNOME3, where it was rumored that one linux daemon systemd was required - but OBSD seems to support GNOME3 in fallback mode. The fallback mode support for GNOME3 seems to be due to the requirement that in GNOME3, the GNOME shell requires 3D accelaration to work, as it requires graphics composition. That brings into focus the fact that most graphics cards don't include open source drivers, and while that's not a roadblock for FBSD, it does seem to be more of one for OBSD. On the FSF side of things, some of the FSF endorsed Linux distros, like Trisquel, had the same issue, and they too defaulted w/ this fallback mode GNOME option.

Was this ever a problem in KDE4? While KDE4 had initial problems due to Qt4 being unready at the time, KDE4.8, as it stands today, is reasonably mature. KDE5 and beyond will support Wayland in addition to X, but OBSD needn't go that route if it doesn't want to. At any rate, does KDE4.8, like GNOME3, require 3D accelaration to get going? I've never heard of KDE having such a requirement.

They don't include Emacs (instead mg is in base, rewritten from scratch with a funny easter egg inside) neither do they include Libre Office. It's just a Makefile and some patches that are distributed. Package are a convenience for the users, and available only if the license is 'free' enough (i.e legally possible). They want to switch to pcc instead of gcc, I've heard that Theo does that.

Okay, why does this page seem to suggest that Emacs and Libre Office are included? Very strange!

OpenBSD's IPv6 stack is one of the most mature stack. I bet its code is already somewhere else (free license => not wasting engineering efforts). You might want to read about Packet Filter if your especially interested in tunning/handling IPv6 traffic.

Apache is actually an old version of apache, before the license sucked, and it underwent a lot of changes. Don't compare it to nginx. You can get it in the ports/package sysem if your not happy with the shipped apache.

I listed my questions about IPv6 support above, under the discussion I renamed 'IPv6 support'.

As a side note, OpenBSD uses the ISC license when i can now. Might be worth looking ;).

It doesn't use the normal BSD license like other BSDs?

How is OBSD's IPv6 support superior to FBSD, which is what your first statement above seems to suggest? I've checked their site - for instance, their Networking FAQ, and there is nothing there that suggests that OBSD has embraced IPv6 and supports it in a big way. There is no mention of any DHCP6 support, even though they have a major section on DHCP support, and in all the examples that they provide, they use only IPv4 examples, implying that equivalent IPv6 support either doesn't exist, or at best, is nowhere near as ready. Except in the section that describes ifconfig, there is nothing that suggests that IPv6 is even supported, if one goes by just this section of the FAQ.

I agree that their improvements would be incremental, but for your claim that it exceeds that of FBSD, I'd need to see that 5.1 supports everything about IPv6 that FBSD9 supports - and more. At least going through their above documentation, nothing seems to suggest that this support is there. Only thing about FBSD - some of its derivatives, like pFsense, which is purely an FBSD firewall and router, does not support IPv6, despite FBSD supporting it. Which is a real disappointment.

Bug busters!

Have you ever looked at the OpenSSL code? It could have the Ark of the Covenant hidden in all that mess somewhere for all we know and we'd never find it.

That's one reason OpenSSH has been moving towards more restricted/careful use of OpenSSL, and I believe in this case it actually makes OpenSSH not vulnerable, because this is (yet another) bug in the ASN.1 parser, and OpenSSH doesn't use the OpenSSL ASN.1 parser anymore. Sometime a few years ago they replaced it with a minimal, special-cased, audited internal version, which can't handle full ASN.1, but can handle the subset used in OpenSSH. See section 3.2 of this paper (pdf) for a bit more.

Putting an @reboot entry in the user's crontab would start anything you want when the machine boots, without the user even logging in.

...and would do so not only on OS X, but on many Linux distributions and FreeBSD and NetBSD and OpenBSD and....

I guess you are confusing the FreeBSD TCP stack optimizations with stateful packet inspection - routing, by default, does not touch firewalling.
But hey, straight from the horse's mouth: http://www.openbsd.org/faq/pf/ru/perf.html . That's why there's a new (NetBSD) project called NPF, that aims the creation of a more sofisticated and scalable packet filter.And, afaik, FreeBSD 9.0 TCP optimizations relate to congestion algorithms, not necessarily firewalling.

I often see these misconception of trying to translate internal/testing/development benchmarks into real-case usage. Just because a piece of software measured 100k connections/s on a controlled environment and selected hardware, it doesn't mean it will perform similarly on your machine. Local network application tests are done with clean, well-formed, unrouted traffic. In internet-facing production servers, you'll get all kinds of garbage. The real amount of hits/s you'll get will depend of a plethora of factors, such as average content size, network latency, I/O latency, design of the application, quality of the hardware, quality of the drivers, etc. The choice of webserver is relevant, but not that much. TCP attacks can drown your machine (by network exaustion) long before you see any real advantage of using Nginx regarding DDOS scenarios. It is also very common to see people switching to nginx and being forced to learn what they are doing, so the idea they have of apache is "all modules loaded" and some random options on a control panel.

I use both webservers, for different applications. Nginx is faster in static content, and seems to handle stress very well. Apache is feature-complete with a plethora of third-party modules (such as mod_security) and behaves very well as a general-purpose server (I actually use a lot mpm_itk, so every vhost has its own uid/gid). Sometimes you can squeeze extra performance by trading Apache for Nginx, sometimes it will break your app (complex mod_rewrite rules, for example). But that's relevant for legitimate users - if your network pipes are clogged by requests, both webservers will appear unavailable.

You don't need to wait for law enforcement to stop spam in its tracks. OpenBSD's Spam Deferrel daemon does an excellent job of combating spam without the overhead involved of filtration. Through a combination of tar pitting and grey listing, I was able to take the family business' spam counts from 1,000 a day to 2 or 3 per week. OpenBSD's tar pitting sets a TCP recieve window of 1 byte per second on known IP addresses that send spam. Additionally, you can create spam trapping addresses and I've done this and placed them in the open on bulletin boards and newsgroups. In fact, I've used spam trapping addresses to harvest IPs of known spammers and add those to a blacklist. There is no performance drop on our end. The most persistent spammer hung in for nearly an hour before giving up the ghost.

I think it's worth mentioning to anybody who enjoyed this article that Michael W. Lucas has a fresh SSH book out called 'SSH Mastery'. Initially an ebook, but becoming available right about now in a paper version too.

Amazon will have it, or if you're shopping for OpenBSD stuff anyway (as you should, OpenSSH which is almost certainly the ssh and sshd on your system, is essentially an in-tree development at OpenBSD), www.openbsd.org/books.html and tentacles of the ordering system will show you where to get it.