I even run this on an old Amgia, 20 years old. Amazing stuff, netbsd that is. I wonder how they manage to support all these different hardware. Cool.

I wonder how they manage to support all these different hardware.

One way is automated cross-compiling to ensure that the source at least builds for as many architectures as possible. Think of it as a large scale continuous integration environment.

The Darwin kernel (which is called XNU) is a bit weird - I spent some time looking into it when it was still a relatively new thing (2003-4 kind of era). XNU is Mach + FreeBSD + DeviceKit/Apple-y bits, all sharing the same protection domain. The latter point is interesting, since despite the fact Mach is considered a microkernel they've actually shoved all of the other kernel-level services in with it, rather than separating them into different processes. This makes the whole kernel basically monolithic (i.e. like the modern Windows and Linux kernels), which is kind of unexpected!

The Apple-y bits in the kernel that I mentioned definitely includes DeviceKit, their driver interface. Maybe some other stuff as well. The drivers are not normal FreeBSD-like device drivers - I think they're even C++, unlike FreeBSD itself.

I found it all a bit unexpected really, things didn't fit together as I'd imagined.

There's probably more in here; I'm not sure if it's the original one I read through!
https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/KernelProgramming/About/About.html [apple.com]

Indeed. NetBSD is exceedingly stable and more people need to take advantage of it. I'm very surprised Google didn't choose to use *BSD instead of Linux, because as servers go, nothing beats BSD. I once administered several BSD server and never once had a failure. Ever. Once they are up and running and configured correctly, they are there to stay short of hardware failure.

NetBSD makes a great embedded OS and I'm surprised there are not smartphones running BSD. Maybe soon...

you might well be a NetBSD user and not know it. might be in your printer, network router or switch, internet security or web cam, cell phone.....it's an extremely stable, well engineered and high quality operating system

It's far easier to get random drivers and niche optimizations into Linux mainline. That's why BSDs tend to be more stable---less code churn. (Other times, it means persistent problems that go unaddressed for years.) Code churn means more bugs. It's inevitable. And it's why it's so easy to root a Linux machine, even though on-the-whole the code quality is really good. Also, Google started using Linux 15 years ago, before NetBSD was actually tolerable.

In real world terms I guess the difference is small, but what mattered in the end is that corporations flocked to Linux. End of story.

NetBSD is the "runs on any/everything" variant. It's absurdly portable. If you've heard stories / jokes about "BSD on a toaster", it was probably NetBSD.

It's not necessarily a great desktop system; "runs on everything" doesn't mean all internal or peripheral software support is going to be great (desktop-oriented BSD distros are usually FreeBSD based). However, it's a great choice if you have a very old or obscure computer that you want to run it on. I know a guy who runs NetBSD on one of the later-model VAXes.

> Evidence? This is Slashdot. OTOH, code churn is quantifiable, and I'd put money down to show that Linux changes faster, especially wrt to drivers, but I'm not about to waste my time doing that. People can take my assertion for what it's worth.

One man's "code churn" is another man's development. If you improve code, it churns. BSDs certainly don't have any claim to be perfect and not requiring any improvement. They are behind Linux in almost any objective metric you can come up with, which is why they resort to "it's ugly, not cohesive, churns too much" nebulous type of arguments.

> Ease of drivers is not always a good thing. On the BSDs the driver writers tend to be the subsystem maintainers.

Well that simply does not scale. Linux might have dozens of drivers for a given subsystem. Someone who is familiar with hardware and its specs, who uses it and tests with it, is in a better position to learn the subsystem's APIs than the subsystem maintainers are to learn, use, and test dozens of drivers with hundreds or thousands of permutations of hardware.

> On Linux they tend to be vendor engineers who drop piles of shit from 10,000 feet. They never follow the rules, which means you get crap code that's hard to change, and more importantly they make it harder to re-engineer the subsystems.

This is untrue. This is what subsystem maintainers are for, to enforce rules for driver writers and ensure crap code does not get in.

> Linux used to be like the BSDs. I forgot his name, but in the 1990s there was like one dude who wrote most of the ethernet NIC drivers. If you bought a card you made sure to buy one compatible with his drivers, because all the others were crap.

When you support out of the box more CPUs ISAs, more hardware platforms and more devices than any other OS on the planet, that model just does not work. Delegating responsibility in fact works, but you have to do it right. If your experience with BSDs is that vendors can just "drop crap from 10,000 feet", then its clear that the development and maintainership model does not work.

> And niche optimizations may be a misnomer. But how many different schedulers have been in the Linux kernel in the past 10 years?

3 major versions, as opposed to the 2 that FreeBSD has. How many different schedulers have existed in the Linux kernel concurrently? 1, as opposed to the 2 that FreeBSD has, which is a vastly bigger problem.

What's wrong with the Linux schedulers? The second one was required for the CPU and process counts that Linux was scaling to, and it did its job well (4096 CPUs in a single system image, and millions of threads), it had hyper-threading awareness and multicore, and NUMA scheduling awareness well before Windows, and many years before any BSDs. The latest scheduler version was required to do workload/resource management, with Linux being used in most cloud type environments like google cluster.

> You have intense competition by companies to improve their own workload, and they fight to get their work into the kernel. Fortunately, performance regression are not tolerable. But the point is, there's lots of churn. You end up with lots of awesome code, but even awesome code has bugs. And the more sophisticated a piece of code, the fewer people able to comprehend it.

All code has bugs of course.

> Remember the maxim, if you write code to the best of your ability, you're incapable of debugging it. Take the system time infrastructure. On the BSDs time is stepped using an algorithm from a doctoral thesis paper. It's clean and elegant, and it allows different time sources to just plug right in with little fuss. The entire thing fits in a single source file and notwithstanding the math it's easy to read even for the uninitiated.

> On Linux, the core of the system time code was dumped from IBM. It does basically the same thing, but it's implemented inside-out. It's at least 5x as much code, including all the optimizations. Using RTDSC and similar tricks, it vastly