Where do you get your Unix-like OS? Plus speeding up Debian and a look into the minds of Debian and Ubuntu

Google "linux vs. bsd," and this comes up. Written by BSD user Matthew D. Fuller, there's a lot of information to absorb.

Here he is on "Chaos vs. Order":

One common generality is that the Linux methodology is the living incarnation of chaos, whereas the BSD methodology is far more about control. To a large extent, it's true. Linux grew out of a spare-time hacking background, while BSD grew out of a controlled engineering background. Of course, there's plenty of weekend tinkers writing BSD code, and plenty of full-time professional programmers sloughing away at various parts of Linux. But the feel of the systems still does reflect that sort of schism.

We've already discussed the construction methodology; BSD builds up a core system which is uniform, whereas Linux distributions takes pre-existing pieces and pretty much puts them together helter-skelter. Naturally, the BSD method is far more amenable to keeping things ordered, while the Linux method practically necessitates utter chaos. That's not to say that chaos is inherently bad, or order inherently good. They're just different environments.

Linux will also generally chase new versions of other programs much more closely, adopting particularly more major changes like Apache 2 much sooner than BSD will move that way. Now, the stricter separation of "base" vs "ports" in BSD, as well as the structure of the ports tree itself, make it easier to have multiple parallel versions of packages in BSD. Sometimes, it's even possible and easy to have multiple versions installed at the same time. Linux, by not having that sort of separation, makes it very difficult to have parallel versions, and instead almost requires a single "blessed" one.

And the primacy of source-compiling in packages also makes it easier to handle multiple versions. For instance, PHP must be compiled differently depending on whether you're using Apache 1.3 or Apache 2. With from-source packages like ports, I can define an environmental variable when I compile and install PHP to tell it whether to use Apache 1.3 or Apache 2. With binary packages, you'd have to have 2 separate packages available, which will lead to confusion sooner or later.

Followed by "Right vs. Wrong":

The difference can also be seen in the way core code is integrated. BSD tends to always shy away from hackish solutions when there's even a hint of a proper solution in the wings. The theory is that it's far easier to wait for the clean answer, than to integrate the dirty answer now, for several reasons. For one thing, if you integrate the dirty answer, that reduces the incentive to implement a better one. For another, once you dirty up the architecture to integrate something it'll never get cleaned up again. You know it as well as I do. Oh, sure, you'll say it's temporary. But you know there's nothing quite as permanent as a temporary stop-gap. And things grow. The only way to avoid giving a mile is to refuse to give the first inch. It's just like taxes; when was the last time you saw a temporary tax that ever went away?

You also see it in what is there. Traditionally (though not universally), Linux integrates support for a piece of hardware before BSD does. But when BSD integrates it, it works. It's solid. It's stable. Linux drivers tend to have a lot more variance, because they'll be brought in earlier. In many ways, this mirrors the add-on case above, but in reverse. BSD has a very tightly controlled base system, and can be very free with setting up add-on software, since it's all added on by the user independently. Linux has a very loose and fluid coupling between the kernel and the userland, but the userland as a whole, due to not having a base/addon separation, requires a lot more work to keep consistent, which places a much higher requirement for a central "blessing" of various versions of packages. The extensive use of binary, rather than source distribution just makes it that much more so.

There are plenty of other "BSD vs. Linux" items out there, but this is the most detailed and well-reasoned of those that I've seen.

My process goes something like this: If you're starting with the hardware, test everything and see what runs best, what you like best and what fits the task the best. It might be Debian GNU/Linux, Ubuntu, Slackware, even Damn Small Linux or Puppy Linux. It could also be FreeBSD, OpenBSD or NetBSD.

I'm reluctant to give up on the Linux distributions I've come to know over the past year and then some, but in the BSD projects I see an opportunity to learn something new and do things a little differently. And since that's the spirit in which I began use of open-source operating systems and software, it's just part of the continuum of what I'm doing, the path I'm on, if you would be so kind as to indulge such thoughts.

That there's more than one or two -- or more than a hundred -- ways to skin the proverbial cat is a very good thing.

Debian tip: Here's a way to speed up booting of Debian when you're not connected to a network:

If you ever wondered, why exim4 needs so long to start when you have no net access, though you were sure that configured as satellite for a smarthost it should have nothing to lookup as the smarthost in in /etc/hosts, you might just have forgotten to put a

disable_ipv6 = true

in your exim4.conf. (I'm not sure, but that might also help
to actually deliver mail to hosts which also have ipv6 addresses
on servers with outgoing smtp when you forgot to blacklist the
ipv6 module).

Thanks, Bernhard R. Link, who works on Debian, for the tip. And read all of the Debian developer/bloggers at Planet Debian. Ubuntu does the same thing here.

Ubuntu 6.06 LTS will be upgradeable to 8.04 LTS: I've made no secret of my admiration for the 6.06 LTS version of Ubuntu, even though it's over a year and a half old. I like the way it runs, I've never had a problem with it ... and I like the fact that it will have support for three years of life on the desktop, even more on the server (until June 2009 on the desktop, June 2011 on the server).

But now that a new LTS is about to be released -- April's Ubuntu 8.04 LTS (if you haven't yet figured it out, the 8 is for 2008, the 04 for FebruaryApril) -- it's a good time to give it a try. If it works well on one box or another, Ubuntu 8.04 might be a good OS to install and stick with for a year, two or three. Now I've learned that there will be an upgrade path from 6.06 to 8.04.

I recommend a separate /home partition so a full reinstall can be done easily (but don't do it without a backup of /home), and I will probably do a full install instead of an upgrade, but it's nice to know that 6.06-8.04 can be done without a full reinstall.