Apple’s Operating System Guru Goes Back to His Roots (Wired)

There's also peripherals to consider - printer, webcam, external disk, etc. Mac is in my experience worse than Linux on those, but its fans don't seem to mind.

It doesn't disallow them though, which I think was the point of the question ;) .

Well, you're sort of right. In FreeBSD committers just commit, no questions asked. But the convention is that those who recently got their "commit bits" should clear their patches with their "mentors" first. All commits get mailed to a list (svn-all). Usually the ideas of a fundamental change will be discussed on the lists, but there is rarely discussion of a specific patch unless someone disagrees very strongly and demands the commit be reverted -- in which case the discussion can be lively. In extreme cases people have had their commit bits revoked for perceived abuse of this privilege (cf. Matt Dillon, who wrote most of the VM subsystem for FreeBSD 4, trod on too many toes when working on FreeBSD 5 with whose SMP vision he disagreed, and then went off and started Dragonfly BSD).

> *BSDs are as fragmented as Linux, even more so. Try to write software to work on OpenBSD, NetBSD and FreeBSD.

This is true, but the original article was referring to FreeBSD specifically.

> As for libc/kernel interface - Linux is surprisingly stable and reliable here. It's possible to intermix various versions of glibc and kernel without much problems. We have some userspaces (don't ask) from 2002 running with recent kernels.

Exactly. And don't get me wrong, I'm continuously impressed by the vigor Linux upstream (and Linus, I suppose, in particular) takes in enforcing the "we do not break userspace" rule. It's wonderful.

But a given *BSD, be it OpenBSD, FreeBSD or MyBedroomBSD avoids the problem altogether, always shipping the userspace with the kernel in a single blob.

Sure it's an ill comparison, and one should really compare a specific *BSD, be it OpenBSD, FreeBSD, NetBSD, Dragonfly, to a single version of a single Linux _distribution_ instead of Linux as a whole, but I have a gut feeling there are a lot more relevant Linux distributions than there are relevant *BSDs.

But there's some merit to the "with FreeBSD you know what you get" argument.

That would be nice to see.

I work in the enterprise space. The solaris toolset has a lot of maturity to support the shipment of binary can't-change enterprisey junk that you have to troubleshoot without changing anything. libumem, dtrace, a high quality pstack that can peek into python.. the list goes on and on. I'm not a big fan of their debuggers but w/e.

However I haven't had a customer problem relating to Solaris since around 2009. They dried right up.

There's some business-development type contact that's using illumos/joyent stuff, but it's some kind of hosting arm of illumos themselves.

I'm just not seeing any adoption at all. It's kind of depressing.

---

FreeBSD has a sort of similar story. During our start-up days, our largest deal hinged on FreeBSD. We hated it. The posix threads implementation was *terrible*, but all our money relied on getting it to work, so we hacked around all the problems.

The kernel was pretty much fine but it sucked for us.

But all those problems were fixed by around 2008. I mean we had customers running ancient versions of FreeBSD and that was annoying, but the versions that the FreeBSD project was shipping didn't have problems by then. However, the customer base was drying up. By 2009 the number of customers was way below 1% (with linux at around 50% and growing), and the only customer I worked with post 2010 was a small university who clearly had made their tech choices in the ancient past with those who had made them long-gone.

Of course FreeBSD support for my type of problem space is actually quite bleak. There's no working pstack (that I can find) for posix threads programs, it seems there was one once but it went broken. The native gdb build seems to somehow send a variety of signals to all the threads while attaching (disturbing the program immensely). These are solvable problems but it's hard to grasp why they're not already solved. There are FreeBSD mailing list threads about these holes but no one seems to care to do anything about them.

I mean obviously my customers and my company should be motivated, but the use usage level is so tiny it would make more sense for us to contribute to AIX or HP-UX first.

It's fun browsing through the Solaris/Illumos kernel code. It's very different than what one sees in Linux.

Sorry but he clearly stating in his post why FreeBSD failed to meet his needs.

I have to say after using Linux for 9 years and trying out *BSD recently, that I am in strong agreement with him in terms of software quantity and the appalling attitudes of the *BSD community and also by the fact that they chose to stick with an extremely proprietary friendly license.