> > FreeBSD is an operating system made by developers who are also system administrators. > Definitely not true (or at least, in no respect different than the developers of the broader Linux ecosystem).

Maybe not so true today, but back when Linux first started, one of the main differences between Linux and FreeBSD was that BSD was written mostly by coders who worked as professional sysadmins, and Linux was written by coders who were mostly software engineers.

That's why Linux had all the new features, and BSD had all the stability. Because sysadmins cared about stability more than features.

It's sort of why their respective philosophies diverged.

I know because I spent a lot of time in the late 90s with the core committers who had been working on BSD since the 70s and 80s at Berkeley. They were all sysadmins.

As a FreeBSD developer, perhaps you know what tunables are being talked about for specific use cases?

Unrelated, I find it surprising that any major operating system these days need rebooting because "every third day or so otherwise the performance degraded a lot". Or maybe they just didn't increase the sysctl var kern.full_performance_days high enough ;)

I've been running Fedora for ~10 years (switching away from {Net,Free}BSD, I was fed-up to re-invent the wheel and the general poor design of the OS / high inertia of the community), and never rebooted once for "performance reason". My average uptime is in the couple of month, always for hardware / maintenance reason. Even my Windows 10 machines is never rebooted because of performance issue.

I don't think I've had much system failure / panics either.

I wouldn't worry too much about that claim. It seems like a poorly remembered claim about about a very old version. I'm sure somebody has the battlescars and could tell you what it was exactly.

My guesses would be a memory leak somewhere, some yucky disk controller bug I didn't run into, or possibly the TCP LAST_ACK state accumulation https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=25986

This has since been fixed, although it did take an annoyingly long time; but before it was fixed, you could address it by tuning socket buffers to be smaller --- it seemed to be less likely for clients to disappear with unacked data, but also, when they did, it wasn't as noticeable.

Most things are tuned pretty well by autotuning these days though. If your work is more I/O limited than CPU limited though, tuning is more likely to be useful.

> As a FreeBSD developer, perhaps you know what tunables are being talked about for specific use cases?

There are tons of knobs and I don't set or know anything about any of them in particular, sorry.

> Unrelated, I find it surprising that any major operating system these days need rebooting because "every third day or so otherwise the performance degraded a lot".

Me too. I assumed the author was talking about some (awful) historic bug rather than an ongoing issue they're having. Kinda sounds like a kernel memory leak, but it could be anything.

I didn't try to say FreeBSD doesn't have detracting politics (I don't think I said that) — you're absolutely right; it does.

My understanding, and let me know if I'm totally wrong, is that most glibc developers are not Linux kernel developers, and that most kernel developers are not glibc developers.

In FreeBSD, I think there's more crossover of developers working on both userspace and kernel components. The monorepo design helps foster that (again, subjective, IMO).

The monorepo is actually a downside as it weaken any form of backward compatibility one could legitimately expect. The general answer in these case "rebuild", but it completely ignores binary-only software which exists in the real world and which is to a large extend completely ignored by commiters. At some point, you want to spend CPU cycle on something else than "rebuilding world".

Also, there is de-facto no competition, short of a hard fork, in the software shipped. You can't just "switch to uclibc" if an embedded platform has memory constraint.

I don't know if you're familiar with FreeBSD's approach to backwards compatibility in general, or just making a general statement about monorepos. It doesn't seem like you're familiar with FreeBSD in practice; apologies if I guessed wrong.

FreeBSD has strong backwards compatibility at the shared library level, across all versions. Support for BSD 4.3 (as in, 1986, pre-FreeBSD) compatibility is slowly being phased out in 2019. Grep around for COMPAT_FREEBSD, for example. This compatibility (for existing stable releases) is by and large maintained in the development branch.

FreeBSD's also got a Linux syscall emulation layer, which implements (some of) the Linux kernel's (stable) ABI.

> The general answer in these case "rebuild", but it completely ignores binary-only software which exists in the real world and which is to a large extend completely ignored by commiters. At some point, you want to spend CPU cycle on something else than "rebuilding world".

That really isn't true. The point of the stable/ branches is the kernel KBI is stable for the lifetime of the branch.

> Also, there is de-facto no competition, short of a hard fork, in the software shipped.

Sure. But you can implement a patch and advocate for it against the existing implementation? Also, there is a lot of support for installing alternatives from ports. Doesn't seem that major of a gap.

> I don't know if you're familiar with FreeBSD's approach to backwards compatibility in general, or just making a general statement about monorepos.

I'm a former NetBSD developer, I left when I got fed up to re-invent the wheel. I spent many years after that supporting a commercial special purpose FreeBSD-basde distribution, and I got a fair share of conflicts on mailing list again "the old guard" (Warner & co) over various subsystem, and had to go as far as calling off an incompetent kernel committer working for Intel at the time. All my grief from ~10 years ago is publicly available in the mailing-list archives.

> FreeBSD's also got a Linux syscall emulation layer, which implements (some of) the Linux kernel's (stable) ABI.

IIRC, it is mostly vestigial, unless it has been going though a major updates in the past 10 years.

> That really isn't true. The point of the stable/ branches is the kernel KBI is stable for the lifetime of the branch.

Branch lifetime is irrelevant. Linux makes backward compatibility an utmost paradigm. I'm sure a 2.4 era binary will still work on 5.4, nearly 15 years later.

> Sure. But you can implement a patch and advocate for it against the existing implementation?

Unless you are a committer, the chance of getting ANY significant patch in is pretty much nil. As I mentioned previously, mailing list are NOT for discussing any significant changes, this is done behind the scene in private by a de-facto pseudo-"committee". The development process is closed to a few elites, generally small group of committers ruling over code sections. By the time any patch is ready, its author drops a +5000,-5000 lines turd^Wdiff that is utterly impossible to review. For lack of a better word, BSD are not remotely close to being open to outsiders. I know this by experience.

>Linux makes backward compatibility an utmost paradigm. I'm sure a 2.4 era binary will still work on 5.4, nearly 15 years later.

Why then is it that i'm locked to the kernel versions required by the binary blobs from proprietary vendors in the embedded space? Be it smartphones, home/SOHO routers, and so on.

Are they doing it wrong? Am I?

My ISP provided CPE runs Kernel 2.6.32.61 right now. Not to mention the crap uncounted Android devices (not mine, in the world out there) are running.

Linus mentions how they don't break userland binary compatibility all the time.

He also explicitly states that there has never and will never be a guarantee of kernel module binary compatibility.