> The comment about using a good SERVER mobo like supermicro is on point --- I managed many supermicro fbsd colo ack servers for almost 15 years and those boards worked well with it.

I completely agree.

Supermicro mobo's with server-grade components combined with aggressive cooling fans/heat sinks running FreeBSD in a AAA data center resulted in two prod servers having uptimes of over 3000+ days. This included dozens of app/jails/ports updates (pretty much everything other than the kernel).

Lovely stuff. The industry would be so much better off if the family of BSDs had more attention and use.

I run some EVE Online services for friends. They have manual install steps for those of use not using containers. Took me half a day to get the stack going on FBSD and that was mostly me making typos and mistakes. So pleased I was able to dodge the “docker compose up” trap.

It really is amazing how much success Linux has achieved given its relatively haphazard nature.

FreeBSD always has been, and always will be, my favorite OS.

It is so much more coherent and considered, as the post author points out. It is cohesive; whole.

> As much as I love FreeBSD, the release schedule is a real challenge in production: each point release is only supported for about three months. Since every release includes all ports and packages, you end up having to recertify your main application constantly.

How much support do you plan on getting? The old releases don't really turn into pumpkins. Yes, every two or three major releases, they end up with a minor release that adds something to libc where binary packages from X.2 won't run on X.1 or X.0. But this isn't usually a huge deal for servers if you follow this plan:

Use FreeBSD as your stable base, but build your own binaries for your main service / language runtimes. If you build once and distribute binaries, keep your build machine / build root on the oldest minor revision you have in your fleet. When you install a new system, use an OS version that's in support and install any FreeBSD built binary packages then.

You do have to be prepared to review updates to confirm if they need you to take action (many to most won't if you are careful about what is enabled), backport fixes, build packages yourself, or upgrade in a hurry when necessary, but you don't often actually need to.

I don't think this strategy works for a desktop deployment; there's too many moving pieces. But it works well for a server. Most of my FreeBSD servers for work got installed and never needed an OS upgrade until they were replaced by better hardware. I did have an upgrade process, and I did use it sometimes: there were a couple kernel bugs that needed fixes, and sometimes new kernels would have much better performance so it was foolish to leave things as-is. And a couple bugs in the packages we installed; usually those didn't need an OS upgrade too, but sometimes it was easier to upgrade the handful of old servers rather than fight everything; choosing battles is important.

Or you can go like Netflix and just run as close to -CURRENT as you can.

As someone who was a Linux sysadmin for several years, looking after a large fleet of RedHat boxes, I can say that the "don’t break your application" promise is BS. Their patches broke applications several times resulting in having to hold them back for months for it to be fixed.

The only Linux distro that actually lives up to that promise in my experience is Alpine.

What you measured is just the overlap between minor releases of the same major release. It helps to think of them as service packs if you want a MicroSoft analogy. So each minor release is supported until it has be surplanted for 3 months by a new one on the same major release line or the whole major release line goes end of life.

I can’t speak for whole communities but my interest in FreeBSD has been renewed over the past couple of years. It has been a very solid OS for a long time and the tight integration between the kernel and core userland has meant that it is sometimes more performant than some popular Linux distros. But its UX has not always been amazing. Seems like lately they have really improved that. Plus ZFS and root on ZFS in particular is very nice.

I would actually be interested in running it in some production environments but it seems like that is pitted against the common deploy scenarios that involve Docker and while there is work on bringing runc to FreeBSD it is alpha stage at best currently.

Still, if you just want an ssh server, a file server, a mail server, it is a great OS with sane defaults and a predictable upgrade schedule.

I think it’s a joy of having a system built by a small community for fun and not debates between large corporate interests.

I feel like you may never have used it. Would that be true?

The desire to be different is strong with some people.

Linux is not fucking mainstream

If anything is mainstream, it’s BSD, because OS X is BSD.

I’ve been using it in VMs just fine. Used it on my desktop just fine for a year. Used it on laptops just fine.

You might have just hit a bad hardware setup that’s outside the scope of support. It happens.

Never had any issues but I've only ever tried to run it on supermicro boards

For years and years to come. You’ll never need to update that box, frankly.

There's a weird fetishization of long uptimes. I suspect some of this dates from the bad old days when Windows would outright crash after 50 days of uptime.

In the modern era, a lightly (or at least stably) loaded system lasting for hundreds or even thousands of days without crashing or needing a reboot should be a baseline unremarkable expectation -- but that implies that you don't need security updates, which means the system needs to not be exposed to the internet.

On the other hand, every time you do a software update you put the system in a weird spot that is potentially subtly different from where it would be on a fresh reboot, unless you restart all of userspace (at which point you might as well just reboot).

And of course FreeBSD hasn't implemented kernel live patching -- but then, that isn't a "long uptime" solution anyway, the point of live patching is to keep the system running safely until your next maintenance window.

Regularly (every 3 years or so) had 1000+ days of uptime with FreeBSD rack servers on Supermicro mobos.

I built the servers myself and then shipped to colo half way around the world.

I got over 1400 once and then I needed to add a new disk. They ran for almost 13 years with some disk replacements, CPU upgrades, and memory additions

The E10k reminds me of Bryan Cantrill's story about the motivation for dtrace. Sun engineers were working day and night, trying to debug what seemed to be a Solaris kernel networking bug, on a benchmarking cluster of E10k machines. I won't spoil the end, but it's great:

https://www.youtube.com/watch?v=wTVfAMRj-7E&t=2640s

Speaking of better vendor support, why doesn’t it support Apple Silicon yet? Obviously, Asahi has led the way on this and their m1n1 boot loader can be used out of the box. But OpenBSD has supported Apple Silicon for three years now.

Sigh. Yes. It’s the boring choice and therefore the better choice a lot of the time. Not all of the time, but most of the time.

Impatience and lost skills is why it’s not a mainstream player.

A small thing, but the mechanistic approach to bundling packages into bigger meta state, is (in my personal opinion) better than the somewhat ad-hoc approach to both writing and including things in an apt/dpkg.

If the product is python, thats what it is. there is no python-additonal-headers or python-dev or bundle-which-happens-to-be-python-but-how-would-you-know.

There is python, and there are meta-ports which explicitly 'call' the python port.

The most notable example being X11. Its sub-parts are all very rational. fonts are fonts. libs are libs. drm is drm. drivers are drivers.

(yes, there is the port/pkg confusion. thats a bit annoying.)

ZFS and jails are two things FreeBSD does very well

You don't have to reinstall with every software upgrade. Reliability and long term uptime are the norm.

1990s nostalgia.

> but I believe that success Linux has had is because of copyleft

No, the success Linux has had is because it ran on the machines people had at home, and was very easy to try out.

An instructive example would be my own path into Linux: I started with DJGPP, but got annoyed because it couldn't multi-task (if you started a compilation within an IDE like Emacs, you had to wait until it finished before you could interact with the IDE again). So I wanted a real Unix, or something close enough to it.

The best option I found was Slackware. Back then, it could install directly into the MS-DOS partition (within the C:\LINUX directory, through the magic of the UMSDOS filesystem), and boot directly from MS-DOS (through the LOADLIN bootloader). That is: like DJGPP, it could be treated like a normal MS-DOS program (with the only caveat being that you had to reboot to get back to MS-DOS). No need to dedicate a partition to it. No need to take over the MBR or bootloader. It even worked when the disk used Ontrack Disk Manager (for those too young to have heard of it, older BIOS didn't understand large disks, so newer HDDs came bundled with software like that to workaround the BIOS limitations; Linux transparently understood the special partition scheme used by Ontrack).

It worked with all the hardware I had, and worked better than MS-DOS; after a while, I noticed I was spending all my time booted into Linux, and only then I dedicated a whole partition to it (and later, the whole disk). Of course, since by then I had already gotten used to Linux, I stayed in the Linux world.

What I've read later (somewhere in a couple of HN comments) was that, beyond not having all these cool tricks (UMSDOS, LOADLIN, support for Ontrack partitions), FreeBSD was also picky with its hardware choices. I'm not sure that the hardware I had would have been fully supported, and even if it were, I'd have to dedicate a whole disk (or, at least, a whole partition) to it, and it would also take over the boot process (in a way which probably would be incompatible with Ontrack).

What would FreeBSD as GPL give you? You could fork it and release FreeGPL with that license tomorrow. (Minus ZFS, but that's in contrib)

Some users of FreeBSD prefer more freedoms than GPL offers. The contributors must not be put off by providing more freedoms.

Places I've worked have contributed changes to FreeBSD and Linux, mostly for the same reason ... regardless of any necessity from distributing code under license, it's nicer to keep your fork close to upstream and sending your changes upstream helps keep things close.

>>I believe that success Linux has had is because of copyleft, and *BSD are riding on the coat tails of that.

Apparently many here are unaware of the history and story as to what stalled FreeBSD in a long lawsuit involving ATT. You need to read up on that. Copyleft had nothing to do with it.

I don't understand this thinking. The GPL is more restrictive than the FreeBSD license. You have more freedoms with the FreeBSD license than you do with the GPL(of any version).

> I wish FreeBSD held the position Linux does in the market today. That would be heaven.

Well The BSD's were embattled with a lawsuit from AT&T at the time Linux came around, so it got a late start as it were, even if it's a lot older.

I feel the same, because it seems that the only desktop-ready OS under GPL today is GNU/Linux, and it feels too bloated nowadays (not to mention that Linux is effectively stuck under GPLv2). Something like FreeBSD feels much lighter and better still being desktop‐ready. Looks like that guys from Hyperbola think the same and that’s why they are doing HyperbolaBSD. Btw there’s some progress in GNU Hurd, but they are still far from being desktop-ready.

It’s a nice belief for some but wholly divorced from historical facts and circumstances

GCC vs LLVM. It isn’t the license.

It'll never happen. You can't distribute ZFS under GPL

Linux is OK. It’s a mess compared to BSD, but it’s OK. It’s the lazy man’s solution. It’s mainly for people who only want to “docker compose up” and walk away. The art of the OS has been lost. People think the OS is something to be abstracted away as much as possible and it’s evil and hard to secure. Shame.

freebsd didn't have the hardware support base that linux did and suffered a huge delay in rearchitecture when x86 smp hardware became widely available. (only one cpu could be in the kernel at a time, the "bkl", was a major impediment in the early 00s). freebsd had better resource scheduling at the time and a beloved networking stack, but linux caught up with cgroups etc. i think linux was also just a trendy vanguard of sorts as the world learned of open source software by and of the internet.

Can you please elaborate the str of Freebsd vs Linux?

After you install the base system, install your favorite desktop by doing "pkg install <your_favorite_desktop>" and it's done.

What's so difficult?

That's where Linux fails too IMO. Both GNOME and KDE really suck in my opinion. Or perhaps suck is too strong a word. I find both to be hugely problematic.

That does not mean they do not work, mind you - GNOME succeeds in dumbing things down that even 60 years old grandmas could use it (until they misclick and then are presented with 20 windows all put side to side). And KDE gives a lot of flexibility in tweaking it how you may want it (if we ignore Nate's donation widget). But it just is still waaaaaaay too complicated and convoluted to use. I am better off just describing my system in .yml files and then have ruby autogenerate any configuration value than struggle through annoying widgets to find some semi-random semi-new setting (or none such setting existing such as is the case in GNOME). I'd wish we could liberate these DEs from upstream developers and their dictatorship. I mean, we, can, e. g. patch out the code that shouldn't exist (like Nate's Robin Hood widget), but I mean on a global basis as-is. We as users should be in full control of EVERYTHING - every widget. Everything these widgets do, too. And everything they don't do right now but should do. Like in evince, I hate that I can't have tabs. That annoys me. I am aware that libpapers changes this, but boy ... just try to discuss this with GNOMEy devs. That's just a waste of time. I want to decide on everything here - upstream must not be able to cripple my system or influence it in no way I approve of.

> Yeah ok ... 500 out of 500 supercomputers running Linux ...

So what? Big whoop.