Technical reasons to choose FreeBSD over GNU/Linux | Hacker News Reader

Technical reasons to choose FreeBSD over GNU/Linux

unixsheikh.com

381 pointssigna11361 comments

I find some points... debatable. For example software:

> Normally when you install software on a Unix operating system you find and download the software.

According to the title, this is about choosing FreeBSD over Linux, not over Unix. That means the normal way to install is "<package_manager> install <package_name>". For the end user this is just like ports without having to compile anything. Once you don't have the package or the port available, you end up in the same situation: download the source and compile (which is more likely to work on Linux OOTB simply due to popularity).

> Poudriere is a utility for creating and testing FreeBSD packages. It utilize the FreeBSD jail system to set up isolated compilation environments.

In Debian-like systems you can use pbuilder in the same way. Each package is built in the same clean choot. I suspect RH has something similar?

> bhyve

They don't list anything technically better about bhyve. Why would I use this over xen or kvm?

> FreeBSD has three different firewalls built into the base system: PF, IPFW, and IPFILTER, also known as IPF.

Ok. Linux has iptables and now nftables/bpfilter. It's also got queuing, stateless and stateful features, protocol tracking, etc. CARP can be done in userland, or via other solutions like linux-ha/stonith. What are the reasons to choose FreeBSD here? (also, mentioning 3 firewalls after being excited about well-designed system that just comes together rather than being glued together from third-party software just sounds weird)

> BSD init

They haven't listed what's actually technically better about it than in systemd. (not subjectively)

> Jails

Jails as described in the article, have the same features as lxc. Lxd provides zfs-as-a-backing-store option as well.

> FreeBSD has over five hundred system variables that can be read and set using the sysctl utility.

Ok. On my Fedora system "sysctl -a | wc -l" gives 2093.

> For example, on top of the geom_mirror module an encryption module can be added, such as geom_eli to provide a mirrored and encrypted volume.

So how is it better than lvm with its layers dm-raid and dm-crypt?

I get that people are excited about FreeBSD and I'd love to learn what are the technically better sides of it. But this article really doesn't list that many.

> They haven't listed what's actually technically better about it than in systemd. (not subjectively)

And even to avoid running headlong into this troll pit: Linux distros without systemd exist. It's dishonest to compare FreeBSD to Linux and then only focus on a subset of Linux distros.

I chose systemd since BSD's init has some points over the classic init used in linux previously. But any of the modern choices which actually manage processes (upstart, systemd, whatever you prefer) score a few technical points. Definitely didn't intend to single out systemd as better in this case.

> And even to avoid running headlong into this troll pit: Linux distros without systemd exist. It's dishonest to compare FreeBSD to Linux and then only focus on a subset of Linux distros.

Are any of them mature enough to depend on for serious work? I looked at moving back to Linux a few months ago, but all the non-systemd distributions seemed to be small projects and many of them looked to have schismed, collapsed, or both.

Void is a small project, but absolutely rock solid. It's BSD inspired and systemd free. I like it a lot.

I can also vouch for Void - I've used it on my primary laptop for about 4 years. It's a solid distro, with a great community. Void is very configurable, and it's easy to contribute to the project.

It's also unlike a number of 'systemd free' distros (many of which are essentially "Distro X, except without systemd") because its non-use of systemd is not out of some hate for systemd, but because the developers decided after using systemd (Void adopted systemd for a time really early on) that it conflicted with other goals of the project (like offering a musl libc flavour alongside a glibc flavour).

Here's the thing. I would run: Ubuntu, Debian, Centos or Red Hat on my laptop, desktop and also on any server that I run.

I wouldn't run any small distro in AWS.

Have to agree here. I get a lot of benefits professionally from running Linux personally. I've been a full time desktop linux user over 10 years, and I'm often considered the "linux wizard" because I'm known for SSHing into servers and fixing obscure errors that others have looked at for hours with no success. My secret, is that I've run into most of the common problems (filesystem permission issues, including ACLs, selinux, low memory/OOM, conflicting dependency versions, etc) before and already mostly know how to fix them. The time I did on Arch was particularly helpful here. It was a hard first week or so but I learned more about linux during that two weeks than any other time.

Anyway the reasons I say that: These days I only run distros locally that I would run in production. I get intimately familiar with the intricacies of the distro that way and managing the servers comes natural to me because of that.

Alpine and AntiX, I use them in VMs because they are lightweight, so far no issues.

What kind of apps do you run? A variety of languages/platforms?

Some stuff runs great in Alpine. Other stuff is subtlety but catastrophically broken in Alpine (such as database servers/clients and others that depend highly on locale for determining encoding).

Agreed. I thought Alpine was superb until I ran into an issue mounting NFS shares that seem to be mountable just fine on every other Linux machine I've got lying around. No idea what's wrong with Alpine's NFS.

> What kind of apps do you run? A variety of languages/platforms?

Mainly Python, some issues with Musl, but nothing too bad. Anyway, these days I tend to mainly use AntiX.

Gentoo, maybe?

I know some developers use Gentoo with OpenRC for their daily work machines.

Devuan is a fork of Debian and it's alive and well.

Slackware is still here looking at you guys

Slackware is the one Linux I keep coming back to after trying out something else. As always, it just works (and no dependency checking in its package managers is a blessing compared to dealing with some issues in Ubuntu or Debian; for others there's always pkgsrc, by the grace of NetBSD).

Ah, "serious work". That well-known absolute thing that is the same for everyone.

None of those are beyond hobby level, though.

> According to the title, this is about choosing FreeBSD over Linux, not over Unix.

"Unix" hasn't referred to a specific operating system since the 1980s. FreeBSD and Linux are both Unix OSes: different flavors of it.

That is my point though. Not every Unix system has a package manager. But almost every Linux distribution does.

That's even one of they key attributes that makes differences between distributions: the package manager. Other major ones include the init system, and whether the distro is rolling release or not.

Linux isn’t really a UNIX, though.

Isn't Linux an anagram (no not an anagram but I can't come up with the right word) for Linux Is Not UNix?

https://acronyms.thefreedictionary.com/LINUX

You might be thinking of GNU, which is a recursive acronym that stands for "GNU's Not Unix".

As far as I understand it we got the name Linux because Linus Torvalds was quite bad at naming things. :)

https://en.wikipedia.org/wiki/Linux#Naming

Backronym?

It's a recursive acronym.

No, that’s GNU with the “not UNIX” recursive acronym. Linux was named by the guy who first hosted Linus’ OS and was an amalgamation of “Linus” and “UNIX” (“nix” was a popular suffix for platforms of that type back in those days so “Linux” was a play on the authors name in the style of that naming convention).

If I recall correctly, Linus originally wanted his OS to be called “Freenix” because he thought naming it after himself was a little vein.

For all intensive purposes, it is.

Intents and purposes

I think the expression might be "for all intents and purposes".

I hole-hardedly agree, but allow me to play doubles advocate here for a moment...

goddamnit, well played :)

really?

Well, if you want to be precise … Linux is a kernel.

And the OS is called GNU/Linux.
/me ducks

> That means the normal way to install is "<package_manager> install <package_name>".
This excludes a lot of non-free software, which is included in ports.
> Ok. Linux has iptables and now nftables/bpfilter. It's also got queuing, stateless and stateful features, protocol tracking, etc. CARP can be done in userland, or via other solutions like linux-ha/stonith. What are the reasons to choose FreeBSD here?
Documentation, in my experience.
> They haven't listed what's actually technically better about it than in systemd. (not subjectively)
From experience, documentation and bugs (mostly due to age, but still absolutely relevant). I have about a billion questions about why systemd is built the way it is but I suppose that's a matter of taste and who paid to build it.
> Jails as described in the article, have the same features as lxc.
Documentation as always with the linux/bsd comparison. In addition, LXC—in particular cgroups—is still quite young and unproven. The major benefit here is the docker interface enabling easier deploys and an image specification format, which freebsd still lacks.
Honestly, the documentation alone is enough to move me over to BSD—linux is basically the wild west, and you often discover undocumented behavior (is it a bug? is it intended? ask developer xxx on the mailing list.)

> This excludes a lot of non-free software, which is included in ports.
This depends completely on your choice of a distribution. There's nothing about package managers that makes a difference in this case.
For example Arch, especially with AUR will include all non-free software you want. Ubuntu offers them. Debian/RH have them one config edit away. Recently snap/flatpak also provide those to all distros - whether they're using free-only repos by default or not.
> In addition, LXC—in particular cgroups—is still quite young and unproven.
LXC was introduced over a decade ago. Cgroups even before that. Cgroups themselves are enabled per-session and per-service in pretty much every modern linux deployment for years now. There's less time between jails and cgroups than between cgroups and current day. Cgroups were added to linux in the same year as zfs was added to freebsd. (2007)
I'm not sure what you see as young or unproven about them.

LXC was only introduced in 2007. I wouldn't call ZFS a good comparison as I would also still consider it rather young in terms of basic unix technologies—depending on your needs, you could easily use some other simpler but older (and likely less buggier) software.
With respect to cgroups versus lxc specifically, I don't think the approach is well suited for security reasons—the surface area for bugs and vulnerabilities is much larger than with the jails approach.

> the surface area for bugs and vulnerabilities is much larger than with the jails approach
It would be great if someone wrote an article with technical details about it. I see this repeated very often, but if you actually go looking for details... it's hard to find any justification.

I can’t say I have a decent justification off hand myself—this was the impression I had when digging through a comparison of the two softwares about a year back. Cgroups appears to have a much more detail laden implementation, but this could be explained away with my lack of Linux internals.

The thing that always impressed me with FreeBSD was how it was a complete integrated system, and not a group of miscellaneous parts in loose formation.

>> bhyve
>They don't list anything technically better about bhyve. Why would I use this over xen or kvm?
Isn't it actually worse? There doesn't seem to be AMD support:
>Hosting Linux guests or FreeBSD guests with more than one vCPU requires VMX unrestricted mode support (UG)
Does AMD have UG or does this mean no AMD support for multi-processor guests?
With Meltdown and Spectre, doesn't this mean that VMs on linux AMD systems provide much better performance, and even better performance per dollar?

> does this mean no AMD support for multi-processor guests
I dunno about the details but I've got a Debian VM with 6 vCPUs running on Bhyve, FreeBSD 11.3, on my Threadripper 1920X.

AMD doesn't need unrestricted guest support, it has always had it.

> also, mentioning 3 firewalls after being excited about well-designed system that just comes together rather than being glued together from third-party software just sounds weird
I noticed this too. One of the main *BSD benefits people always tout is that it has "one true way" of doing things - yet having 3 different ways to do firewalling is somehow a great thing when we're talking about FreeBSD?

ipfw would be that one true way on FreeBSD, pf on OpenBSD

Last time I checked, FreeBSD'd pf is quite older than OpenBSD's and also FreeBSD doc says it has diverged from the OpenBSD's pf.

Been a FreeBSD user for very long time besides Linux Slackware distributions since kernel 1.0. Started with Walnut Creek CD distributions. In early years it was much better than Linux with its fast networking stack and filesystem. Also it gives a sense of conceptual integrity as distribution is not just kernel but all the utilities, they work together in unison. But than it also hamper innovation due to design by committee vs the best tool for the job.
Now with time and various flavours of Linux from NixOS, GuixSD, Gentoo, LFS, Slackware, arch, Debian, Ubuntu, CentOS, OracleOS etc., it is in many case a better choice than FreeBSD.
In most benchmarks and hardware support it has surpassed FreeBSD. I still hope FreeBSD continue to grow and innovate, but it’s not a viable choice in many areas of modern computing. Hopefully it can catch up. It still is a very viable choice in building network devices, but there also with modern hardware support Linux is giving it a tough competition.
I still use FreeBSD, but my majority production workload now is Linux with some firewall and networking related stuff in FreeBSD and openBSD.
I did try portable FreeBSD based version like dragonfly and pcbsd. But now I don’t use them that often.

As a counter to this, if you're working on network software that uses a lot of bandwidth and a lot of open connections, BSD is a bit more stable than Linux, so it's generally a better choice for that at least.

This hasn't been a significant issue for a while now, to the point that Linux is used on cache appliances from the FAANG (though Netflix is notable for using FreeBSD in that role).

This is dangerous advice. BSD networking stack may have been superior at some point but that hasn’t been the case for many years now.
You are very likely to run into issues trying to do filtering and/or routing at anything >1Gbps on commodity hardware (ie. e1000 nics).
Pf is pretty but it’s not worth trading stability for.

ipfw is faster

Did Juniper stop using FreeBSD recently? Also, Force10's FTOS has used NetBSD as a base certainly less than "many years now". Force10's L3 switches are at 1GB, 10GB and 40GB speeds IIRC.

The Force10 speeds are most likely not directly due to NetBSD, but from custom or specialized silicon.

Isn't 1Gbps the highest throughput of such hardware?

FreeBSD network stack has always remained rather stable. In terms of performance Linux caught up and even overtook at some point, but lately Netflix did a lot of performance improvements for FreeBSD. So, your information could be outdated.

No citation on such a big claim?

The distinction between /etc and /usr/local/etc is the headline fact here. As a sysadmin, your goal for long term stability is to separate the important bits from the volatile bits to stop them from treading on each other’s toes.
Separation of the core OS from the services it is running is the key to keeping a hygienic separation between components sharing the same file system.
Debian — of which I was a long time fan — solves this by having a culture of pretty neat gardening, keeping each package separate in /var/spool/foo, /etc/foo, /usr/libexec/foo, but not /usr/sbin.
But it’s all so old fashioned now that we live in the utopia of (1) machines that are spun up and then deleted automatically and (2) LXC means I have a fleet of “hosts” providing ns0.domain ns1.domain, mx.domain, www.domain, db01.int.domain all as containers on the sanctity of a relatively unchanging base host, analogous to packages installed on the sanctity of the FreeBSD base operating system, and all edited as config files that can rebuild everything except the /data and /log directories in a matter of minutes.

It only sounds like a partial solution really. You'll still end up with a load of random files in `/usr/local/etc` and unless you maintained a 100% strict policy of only installing using Ports (yeah right) you will eventually get some files of unknown origin.
The proper solution is proper separation of app files, as found on Mac (more or less), NixOS, Android and iOS.
I guess FreeBSD is still stuck in the 90s with Linux (except NixOS).

I always thought that /usr/local in FreeBSD was meant only for ports, not for custom software, and that is supposed to go in /opt.
In any case I agree with the need of proper separation of app files. If we could adapt a bit the base tools of the OS, I think we could get there at least half-way there easily. For example if I could write something like
PATH=$PATH:/opt/*/bin
I wouldn't need to symlink every custom binary that I install (and similarly for man pages, service files etc.)

This
The thing I dislike about this kind of article is that they contain enumerations of relatively small deltas between systems. Things that you can bicker over for hours ("look, FreeBSD has better ZFS support", "but FreeBSD is actually rebasing on ZFS on Linux"). But they do not matter that much in the end. FreeBSD does not provide any meaningful changes compared to Linux that will convince most Linux users; and vice versa. These discussions usually boil down to some form of tribalism.
For me the excitement is in projects that radically change FLOSS systems, addressing their shortcomings. For example:
- Docker, despite its shortcomings, drastically changed how software is deployed in most companies (most FreeBSD folks don't seem to get this, it's not about "we had jails earlier", it's all about the ease of packaging/deployment).
- Nix and Guix completely change package management, by treating packages as values built by pure functions. Allowing using several (isolated) versions of packages in parallel, reproducibility, per-project environments, fully declarative system configuration, atomic upgrades/rollbacks.
- Fedora Silverblue takes Fedora, but changes it to a stacking of OSTree snapshots, providing a largely read-only root filesystem, with atomic upgrades and rollbacks. Applications are installed through Flatpak. Development is done through rootless containers with Podman.
Not all of these projects and ideas may end up being adopted industry-wide, but they explore exiting new directions in packaging, system management, etc. Which to me is far more interesting than bickering over which kernel is slightly better in which use case, or separation between a base system and third-party ports which don't solve the 99 problems in packaging that actually matter (such as: this old project needs an ancient Boost version and in my 'global FHS namespace' package manager having two versions of Boost is conflicting).
I am currently using NixOS and Nix on Mac, but I am also actively tracking Guix and Silverblue because these projects are so damn exciting.

How does Silverblue handle the real world, where does it fail? Nix was the fight concept a decade a go I'm a amazed that it has come so far. Packaging is soo hard atm, the question for me is always how can I get this system to build cleanly with the least amount of work (now and in the future). This is not something docker solved completly, but almost (tracking vulns in base docker images sucks, and using external DBs to track supply lines and what is running on all hosts is not how it should be done)

>unless you maintained a 100% strict policy of only installing using Ports (yeah right)
What do you mean "yeah right"? That's precisely how everyone I know has always managed our BSD fleets. If something isn't in ports (yeah right), you just make a port out of it. It takes 5 minutes unless the software has some crazy messed up build system.

Same on Linux, unless the software has some crazy build system, at which point you probably won't and that's exactly OP's point.

I have no idea what you are trying to convey.

It's quite simple really. On BSDs you tend to use ports to keep your filesystem tidy, but the moment you need something that's not already packaged you either a.) package it yourself b.) the build system is complex and thus you don't package it properly and make a bit of a mess on your filesystem.
So while BSDs might have slightly better FS layout as far as separation of user & system software, in the end you'd probably end up with a bunch of untracked files outside the system's software manager, no matter if you're on Linux or BSD.

Again, you're just ignoring what I said. I've managed tens of thousands of BSD systems for 25 years. I've never had anything installed that wasn't registered in the package database so all its files were uninstalled correctly. Yes, you literally do stick entirely to ports, creating a port when needed. Having a complex build system doesn't mess up your filesystem, it makes it take longer to create the port.

Good for you, but you can do exactly the same on Linux, so there's no advantage for BSDs there.
My myself have seen plenty of cases of people not having the time to create a package for a software they need now, but maybe the domain BSD is used in is less prone to needing software prone to that. Maybe it's just you being lucky.
However again, that's not a technical benefit. You can do exactly the same on Linux.

>Good for you, but you can do exactly the same on Linux,
Nobody suggested otherwise. Read what you reply to.

> If something isn't in ports (yeah right)
Err, yeah yes. Not everything is in Ports. Software doesn't magically appear in Ports as soon as it is written. I would have thought that was blindingly obvious.

99%+ of software people use is in ports. And for the <1% that isn't, it takes 5 minutes to make one. Like I said in the post you replied to without bothering to read.

> Separation of the core OS from the services it is running is the key to keeping a hygienic separation between components sharing the same file system.
I try to achieve this goal on my linux servers with containers, more precisely at the namespaces separation level which gives the ability to mount a set of config files inside the service's container. The other advantage is that versioning a service configuration becomes easy, allowing both clean undo/redo strategies and remote backup. I'm pretty lazy so I'm using docker, but really the gist is around mounting config files for a segregated service process.

> As a sysadmin, your goal for long term stability is to separate the important bits from the volatile bits to stop them from treading on each other’s toes.
> Separation of the core OS from the services it is running is the key to keeping a hygienic separation between components sharing the same file system.
This sounds sensible on the surface, but I'm not convinced. Surely if I run a production system that actually does something, the critical bits I would want separated is not just the core OS, but the core OS plus whatever production software I run on it.
And at that point, why would I want to install any other volatile bits on that system?

This is a good list for differences between FreeBSD and Linux distros, but describing them as advantages FreeBSD has over Linux seems problematic to me. Except for firewalls and core documentation (but what about "community documentation"?) nearly every item is highly debatable whether using FreeBSD has an advantage in the first place, and many I would argue Linux has obviously better options for [1].
To me, lists like this sadly highlights that FreeBSD has extremely few unique selling points left. I accept its superiority for network infrastructure type roles, but that's about it. As a Linux user, there's nothing on this list that makes me consider switching [2].
[1]: Anything to do with package management, containers and VMs and even filesystems Linux system can either do better out of the box or can easily be augmented if you need it. I also think systemd is better than shell script based inits. But there's a reason this is a footnote, this is not the thing I want to argue here.
[2]: Besides it taking effort to switch, FreeBSD has the additional problems that it has poor hardware support for desktop usage (PLEASE get your wifi act together), and software support is also substantially worse - with FreeBSD lagging behind with stuff like Electron, Wayland, desktop virtualization and desktop containerization (Flatpak, Snaps, Appimage even). The point here isn't these details, but FreeBSD winning over Linux people is an increasing uphill struggle.

Even as an occasional Ubuntu user, it's already an effort for even some desktop developers to use GNU/Linux given that Windows and macOS are actually being sane desktops just to get work done. I just can't see any user wanting to use or switch to either Linux or BSD to sanely 'use' their computer for being productive in their daily work other than programming in vim or emacs; because they are still desktops for programmers.
The BSDs now have the same Linux desktop argument of having 'choice' which has made it a blessing for its tinkerers and a curse for commercial desktop app developers as highlighted in [2]. You have 3 ways to package an app, many desktop environment choices like GNOME, KDE, Xfce and the windowing managers like X11, Wayland to test for and you then ask why your favourite software application isn't on X Linux distro or X BSD distro. I won't be looking forward to testing or bug hunting for my GUI app on either system since their desktop stacks aren't integrated well or have a stable 'SDK' unlike with Windows and macOS. GNU/Linux and the BSDs are pretty much still fragmented ecosystems.
The BSDs in particular will always be behind, since the same developers who have always used Linux and were part of the FOSS community are the same ones that still contribute and pushed for it in their companies like Google, Facebook, Microsoft and Amazon, etc. Thus, some will only accept upstream patches for Windows, Mac and Linux. The BSDs will then be left in the sand with atrocious software support and their patches will be rejected as the maintainers will be unwilling to upstream these patches due to this.

> I just can't see any user wanting to use or switch to either Linux or BSD to sanely 'use' their computer for being productive in their daily work other than programming in vim or emacs; because they are still desktops for programmers.
Do you mean for native Windows or macOs dev? Then I agree. However if you are a non tech user I don't agree. I know many people (friends and family), who use Linux on their Notebook or PCs (quite frankly most non-tech users use mobile anyway) and they have no I idea what emacs or vim is (and why should they?).
So Linux being just for dev users is just not true, at least in my experience.

I use Ubuntu as my main os for programming. I run into a few kinks every now and then, and for that I keep around a Windows and a macOS box. I’d say that Ubuntu is a sane desktop to get work done in.

I don't think the parts about ZFS being "better integrated" on FreeBSD are really true any more.
For one thing, ZFS-on-Linux is now the canonical, upstream OpenZFS implementation - https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSOnLinuxN...
For another, Ars Technica recently reviewed FreeBSD 12.1-RELEASE and found poor ZFS integration in the installer and in mount(8):
> Eventually, I realized that FreeBSD's mount command didn't really understand my ZFS root filesystem. -- https://arstechnica.com/gadgets/2020/04/not-actually-linux-d...
Compare that with the relatively streamlined ZFS-on-root install support built into Ubuntu: https://arstechnica.com/information-technology/2019/10/a-det...
(I'm sticking with ext4 until kvdo, bcachefs, or maybe tux3 is mainlined.)

> (I'm sticking with ext4 until kvdo, bcachefs, or maybe tux3 is mainlined.)
I haven't heard of kvdo before - thanks for bringing it up!
I'll add stratis-storage to this mix too. (Although I'm contributing to the bcachefs development and really want it to succeed)

why not use zfs, since it does the things that kvdo, bcachefs, and tux3?

Only one reason of Oracle law suite sword hanging over neck. Even if canonical gives guarantee they will fight with Oracle, if a small company is dragged by oracle in a court room it's hard to fathom the expenses.
So yes there is a need for zfs alternative. So far stayed away from it and using btrfs which works well, except for some RAID limitations.

Fortunately the license Sun applied means any lawsuit would need to attack something much more fundamental, like the very idea of interoperability, as they don't have option to "claw back" any portion of the OpenZFS codebase.

Given that they are currently fighting that an API should be copyrightable, doesn't make me confident that they won't do this.

If they do, GPL is fucked anyway. And not just GPL.

ZFS is not released under GPL, if it is then it won't be a problem. So there is a need for an alternative and BTRFS works well for me, no need of license encumbered ZFS, not sure of others.

My personal reason is that zfs.ko entirely bypasses the kernel page cache, preferring its own internal cache (the ARC). Reimplementing kernel subsystems is a recipe for interoperability nightmare (c.f. the NVIDIA binary driver). For instance, this causes unnecessary memory pressure when you have a mix of ZFS and non-ZFS filesystems (e.g. SMB mounts).
Additionally I curmudgeonly have yet to come to terms with the blatant layering violation of ZFS being a combined block-device-manager and filesystem. But the benefits (file-level RAID behaviour) of that are indeed clear.

> I curmudgeonly have yet to come to terms with the blatant layering violation of ZFS being a combined block-device-manager and filesystem
It has both advantages and disadvantages. It’s a trade-off. ZFS decided it was worth it, and so did btrfs.

Sure they committed these crimes, but those are the reasons why ZFS is better than the alternatives.

> Eventually, I realized that FreeBSD's mount command didn't really understand my ZFS root filesystem.
I couldn't find this direct quote in your link. But I'm using FreeBSD with ZFS on a few machines and I don't understand this comment.
You can absolutely boot with ZFS on root. The installer lets you do it out of the box. Including with geli for encryption.
And you can use mount(8) to mount a ZFS partition, I have done that all the time when booting from recovery media and mounting my root pool. This gets a little confusing at first because most uses of mount(8) require a device name, and mounting ZFS takes a pool name, so you may have to zpool import first, but once you get over that it's fine.

The quote appears in the article, on page 3 after some lazy-loading (do you have Javascript enabled?)

Ah ok, this is about trying to remount read-write. Yes, that requires zfs set readonly=off on FreeBSD. [vs. -o rw with mount(8)].

Actually zfs mount -u / works just fine.

But I think the complaint is that it doesn't happen through mount(8).

The Linux kernel devs hate ZFS and actively sabotage it even backporting changes specifically to break ZFS to LTS branches.
It's fine if you use something like Ubuntu where it's officially shipped with the distro. If not, be prepared to apply kernel patches whenever the kernel team takes a snipe at ZFS.
I'm not trying to be political here, just my day-to-day experience working with several Linux machines running large zpools. It's still worth it compared to the alternatives but if I could use FreeBSD I would.

The Void team does a good job with managing ZFS as well (it's in the official repos). The unofficial ZFS on Arch is generally ok as well (though Arch's management of kernels is weird and a bit tricky).

Do you have an example of a commit where they did this? Just curious as to how (no need to explain why, I get it)

See https://github.com/openzfs/zfs/issues/8259 for details.
While they didn't remove it to sabotage ZFS, they don't seem to care about it ruining ZFS performance on Linux.
Of course they have no obligation to make ZFS on Linux users happy, still a bit of a bummer tho.

It looks like Linux kernel devs just don't care about ZFS, like they don't care about many out-of-tree kernel patches/modules.

There's absolutely no evidence for this. On the other hand, there's some evidence that Sun made ZFS licensing explicitly non-compatible with the GPL, so as to not "sabotage" Solaris.
Linux has other efforts going on in this area, including Btrfs and Bcachefs - there's also ZoL, of course.

Take a look at any of Greg Kroah-Hartman's comments on patches that screw up ZFS.
One of the biggest ones was removing exports of kernel functions that ZFS used for encrypted datasets: https://marc.info/?l=linux-kernel&m=154689892914091
I'm fine with this sort of stuff in general assuming it doesn't affect LTS, but this specific patch was backported to LTS kernels even though it has nothing to do with security or bugfixes. I had several zpools I had to apply custom kernel patches on the machines for no other reason than because somebody is mad at licensing.
Bcachefs isn't even stable enough to use in production. Btrfs is okay, and I've used it before, but it's also a minefield of killing your data depending on what features you use. If you use all the features you need to make it on par with ZFS you may as well dump your data in the trash.
ZFS 'just works' and none of the features are incomplete or have asterisks attached that compromise data integrity. Yeah it has architectural problems, doesn't do stuff the Linux way, and has a license that makes devs angry. It's also never lost a byte for me in production for almost a decade of use.
I know the Linux devs don't owe me anything and I'm not really angry or anything about this. It's just a fact that it's frustrating to have to deal with political problems just to run a server.

You're just ignoring what I said above. Nobody is out to screw ZoL, but the kernel community doesn't care enough to maintain compatibility with it.
Why, as a kernel dev, would you care if there's no possibility of it ever being mainlined because of decisions Sun explicitly made to be hostile towards your project?
It's like trying to cozy up to someone who just punched me, not happening.
Bcachefs isn't yet up to parity for sure, but it is stable enough for everyday use and doesn't corrupt you data like Btrfs sometimes does. A stable foundation that gets expanded upon daily.

> I don't think the parts about ZFS being "better integrated" on FreeBSD are really true any more.
ZoL is not in the mainline Linux kernel, therefore it isn't even "integrated". Linux 5.x introduced some backwards incompatible changes which broke ZoL also triggering a response from Linus.
https://www.phoronix.com/scan.php?page=news_item&px=Linus-Sa...
For these reasons I'm also going to stick with ext4 on Linux. In the meantime we run appliances and servers which run ZFS on FreeBSD without any issues. SmartOS is another choice to run ZFS but I don't have any experience using it. Maybe I'll try it as an alternative to Proxmox.

While I like more FreeBSD than Linux, I say Linux is generally a better choice for servers. Better performance, better hardware support, more refined tools, easier to set up, and the list goes on. This is part due to popularity but mainly because what author hates: software written by companies willing to earn money in contrast to software written solely by passion. If it weren't for corporate money, Linux would be in a much poorer state.
Neither one is ready as a desktop operating system. Linus Torvalds said that himself about Linux. Since FreeBSD lags behind Linux, it's safe to assume that is true for FreeBSD, too.
Fast reading the author's previous articles on FreeBSD VS Linux, it's easy to see that it's dislike for Linux and praise for FreeBSD it's based solely on politics. He hates Windows 10 which he names an "horrible operating system" and now he hates Linux too. And that is just because Linux has big contributions by companies willing to gain money, in contrast to software written solely for passion, which he deems much better.
He even goes as far as state that technical merits matter much less than politics.
That I regard as pretty immature.
Now the author struggles to come up with technical reasons to pick FreeBSD over Linux. If he succeeds on that, that is for any reader to judge.
Rants like the author's previous articles on Linux VS FreeBSD seem to make even Richard Stallman an reasonable man in contrast.
Some developers, some companies are providing software for free, both as in "free beer" and as in "free speech". That means time and money. He thinks that he and other users are entitled to much more than that. He feels like he should say to others in what way should they contribute to free software.

Neither one is ready as a desktop operating system.
This is a particular bugbear of mine. If Linux isn't ready as a desktop system, how is it that I have been using it as such for 15 years? I get that it isn't all things to all people, but it has long fulfilled my needs; I've always been able to find a good quality tool for any task I want to do. Generally speaking, I'm happier with Linux than Windows or Mac OS, though I'm sure familiarity is part of the equation.

It comes down to the hardware you choose.
I'm using a 7th Gen Lenovo X1 Carbon. When I got it everything worked out of the box with Fedora.
Without coming pre-installed, I don't see how it can be readier.
Of course if you buy a machine with exotic hardware (cough Broadcom) then it'll be a pain.

> I'm using a 7th Gen Lenovo X1 Carbon. When I got it everything worked out of the box with Fedora
Even the fingerprint sensor? Using a X1 Yoga here, had trouble with it.

Sorry I only just saw this response. The fingerprint reader worked with the latest firmware, installed automatically via fwupdmgr.
https://fwupd.org/lvfs/devices/com.synaptics.prometheus.firm...

You say "exotic hardware", but Broadcom hardware (e.g. NICs) are very common.

Well, my travel netbook came with Ubuntu pre-installed, then I was left without wlan during 2 months until all bugs fixes on the open source driver that replaced the "bad" working proprietary blob were sorted out.
And to this day, the OpenGL and video hardware decoding capabilities are castrated by the open source version of the AMD driver, that did not considered worthwhile to support Brazos APUs to the same level that fxglr had.
So much for coming pre-installed.

Same here, I ditched Windows, which was becoming increasingly bloated and harder to develop on, in 2004 I think, then I had a few years of FreeBSD (yes, as my main OS and on a laptop at that!), then switched back to Linux (drivers, mostly). Since ~2009, I've been working on Fedora, with a year of (forced) MacOS experience around '17 - I was delighted when the project I needed a Mac for ended, and I could get back to Fedora. Availability of drivers improved tremendously during the 2010s (although NVidia's became... hard to deal with), so much so that I could buy an off the shelf laptop and have Fedora up and running in a matter of minutes. With video codecs, web browsers, messaging apps, office suite - basically all the things you get on other OSes. Even the games I was interested in worked, thanks to Steam (and LD_PRELOAD in one case).
To summarize: Linux was a decent desktop ten years ago, and it didn't get any worse, at the very least, since then.

With Linux, no matter the distribution you pick, you have to be more interested in computers than merely viewing them as an applicane for word processing, video chatting and online shopping.
- Some software defaults to installation as sandboxed packages. Try explaining that to someone who is used to dragging and dropping files from the desktop into their programs to open them.
- Want to watch a movie? Sure, but you won't get vsynced video without opening up a text editor as root to configure your graphics driver.
- Ohh, your laptop has THAT particular Wifi/Bluetooth/PCI bridge/whatever chip? Sorry...
- No, don't open "Christmas Wishlist.doc", that's from last year. The new one is called "Christmas wishlist.doc".
While Microsoft (and to a lesser extent, Apple) has gotten a lot of flak over shoddy updates lately, things are, by and large, much more prone to breaking on Linux. And when they break, even just a little, you need to know your way around a terminal to fix them.
I recently had to downgrade my kernel because of the bugs in i915. To do so, I had to first identify the problem by following the syslog and then do some heavy lifting in GRUB to lock my boot process to an older kernel version. The prerequisite knowledge to be able to perform what we might consider a simple task, has been built up during decades of me being a computer nerd.
For someone without a keen interest in computers, Linux on the desktop isn't all that great. The thing is, I like it that way. I want the freedom of choice. I want the level of control it gives me. When (or if) it becomes ready for the desktop, it's probably ready to be abandoned for something else.

> No, don't open "Christmas Wishlist.doc", that's from last year. The new one is called "Christmas wishlist.doc"
I'm veering a bit OT here, but is anyone aware of the justification for having a case-sensitive file system? It's something that's always annoyed me about Linux and *BSD, but I wonder if there is any real benefit I've just never grasped?

Don’t know if it’s the real reason, but it’s bound to save a few cycles when doing string comparisons. I guess that would’ve made a difference in a multi-user system on a PDP-11.

Linux (and probably also the BSDs) goes beyond "case-sensitive": filenames are a sequence of bytes, giving special meaning only to the NUL byte (as the terminator) and the forward slash byte (as the path separator), and to the "", ".", and ".." filenames. From an implementation point of view, it's much simpler, and makes it easier to have high-performance code.
Case insensitivity adds a whole set of complications. The operating system has to either canonicalize all filenames, or preserve them (case preserving) but have an equivalence class of filenames. Canonicalization can be problematic (like ß -> SS, or perhaps ß -> ẞ? And let's not think of the dotless i), and to make things worse, can change with newer versions of the Unicode standard (as new characters and their case mappings are added); at least NTFS works around that by storing a case mapping table in the filesystem metadata, so a filesystem created by a newer Windows release can have a different case mapping (and you can have different case mappings for each filesystem in the same machine). It can also confuse software: even with a case preserving system, a program can open a file named FOO for writing, and not find it later when listing the directory (because it already existed as lowercase "foo"). This kind of thing has led to security issues in the past.

The very concept of “case” is locale-dependent. To embed locale-dependent code in the file system is bad design.

I've always considered case sensitive file names to be a feature, not a bug. I am personally annoyed by filenames not being case sensitive in Windows. I guess that's just how my brain works. To each their own, I guess.

> With Linux, no matter the distribution you pick, you have to be more interested in computers than merely viewing them as an applicane for word processing, video chatting and online shopping.
I agree concerning word processing and especially video chatting, I much prefer using these applications on MacOS.
I disagree though about online shopping, in my experience running Firefox under Linux or Windows is pretty much exactly the same.

As someone who has used Linux on the desktop for the last few years, I've never had the first three issues. The last one I believe is the same on macOS which I consider to be a fine desktop OS.

macOS has always supported case-sensitive filesystems, but the default has always been case-preserving, but not sensitive. A few years ago they added case-sensitivity as a format option for HFS+, but it was still off by default.

> If Linux isn't ready as a desktop system, how is it that I have been using it as such for 15 years?
Obviously the bar for "ready as a desktop system" is subjective and thus will change wildly from person to person.
For me, it's not ready primarily because it lacks any remote desktop solution comparable to RDP. Yes I've tried VNC, X2Go, NoMachines and some others I can't recall (though not ogon yet).
I find it's also a lot more fiddly than Windows, but I could have lived with that.

I had Slackware on a Dell laptop in 2003, everything worked like a charm - wifi, graphics, everything. (An attempt to switch to Linux ver. 2.6 broke things, but that's another story.)

Using FreeBSD + KDE as my desktop (on a PC, not laptop) since early 2000-s as well.

I disagree about hardware support on server grade machines. It's very rare that FreeBSD lacks there. many vendors of server-grade hardware (network and storage controllers, etc) have FreeBSD teams and either release their drivers or contribute to the in-tree drivers.
With desktop-class hardware (Wi-Fi, input devices, various non-standard USB gadget, setc) the situation is much worse.

FreeBSD marketing:
- FreeBSD is like Linux but <> - It is more <> than Linux - It is less <> than Linux - It has more <> than Linux - It has less <> than Linux - Linux LINUX Linux LINUX LINUX
OpenBSD marketing:
Look, cute fish.

> OpenBSD marketing:
OPENBSD IS SECURE. ARE YOU SECURE? ARE YOU WORTHY? OPENBSD: SO SECURE WE DO NOT NEED YOU!

FreeBSD and Linux have pretty cute mascots too.
Puffy is exclusive to OpenBSD. Tux and Beastie are more generic.
Also:
"Early versions of OpenBSD (2.3 and 2.4) used a BSD Daemon with a halo, and briefly used a daemon police officer for version 2.5. Then, however, OpenBSD switched to Puffy, a blowfish, as a mascot." [0]
[0] https://en.wikipedia.org/wiki/BSD_Daemon
Edit:
You're absolutely right that there seems to be some kind of power fantasy among the FreeBSD crowd about crushing Linux.
Just do an image search for "BSD Daemon" and see the g(l)orious fan-art.

I started using FreeBSD a few months ago for a Tor relay, trying to promote OS diversity. I had read these types of articles about how FreeBSD is so much cleaner and well documented than Linux, and I wanted to try it out.
Honestly, I found it seriously lacking. It always seemed to me like most of those article writers had poor understanding of Linux, and now it seems to me like they have poor understanding of FreeBSD too.
For example, this article, like many, touts the high quality of FreeBSD documentation. I found it to be similar to Linux documentation: a few excellent pages, mostly good pages, some mediocre pages, and lots of undocumented stuff. People (including me) often complain about the quality of Linux networking documentation, which is unquestionably terrible, but I found that FreeBSD isn't really that much better overall. Better in some places, worse in others, often you have to give up and go find the source code.
Another thing often touted is the centralized development of FreeBSD making it more organized. This article betrays itself here by explaining that FreeBSD has three different firewalls, one originating locally, one forked from OpenBSD, and one forked from some dude. Now, to be fair, Linux is far from clean here: between ipchains, iptables, nftables, and bpfilter, Linux has gone through a lot of change. At least with Linux though there are at most two practical options at any given time, and there is a clear forward progression. With FreeBSD, I spent several hours trying to figure out the differences between each, which wasn't helped by the documentation problems: manual pages being fragmented and incomplete and the handbook being woefully out of date on this subject.
It also seems like a lot of the hyped FreeBSD features are actually far behind Linux features. As other commenters have mentioned, Linux has device-mapper, which is similar to GEOM, and is used for LVM and modern RAID setups. Jails came before containers, but Linux namespaces are now far more powerful than jails, which aren't that much more than chroots. bhyve is nice, but lags behind QEMU/KVM. Poudriere is fine but most Linux distros have chroot builders too now.
In conclusion, I don't find FreeBSD particularly attractive for any of the reasons that I hear often touted.

Any Linux or BSD distro could achieve best-in-class documentation for new users by simply adding example usages for most commands to the top of their man pages. Man pages tend to read more encyclopedias than practical guidance, and FreeBSD was no exception last I looked.
Command xyz
Common usage: xyz -s source_ip -d dest_ip:port

The Arch Wiki is pretty damn good in my opinion. I don't see how FreeBSD's documentation is better, if "better" = more useful and up to date.

Slightly off-topic here, but you might like the tdlr project[1]! It's community-maintained, example-focused documentation for common command-line tools. Currently, there are over 1700 pages, and it's very easy to contribute new pages or improve existing ones, because it's all in simple markdown on github. (For example, [2] is the source for the tar page.)
[1] https://tldr.sh/
[2] https://raw.githubusercontent.com/tldr-pages/tldr/master/pag...

It's sad to see that FreeBSD rehashes the same arguments they used at least since 2005 (I actually couldn't believe that the article is written in 2020) and completely ignore all the innovation that Linux has undergone since then. My favourite:
KMS (Kernel Mode Setting) makes graphical UI a first-class citizen and Linux a solid desktop foundation. Did FreeBSD finally catch up here?
Cgroups and namespaces together with a COW filesystem makes Linux a solid foundation for containers. I used jails back in 2009 and, honestly, its vision was incomplete. For n jails you needed n copies of the userspace. You couldn't use lo0 property, etc etc. Jails felt both too restricted and insufficiently isolated from one another. Has anything changed since then?
I really wished FreeBSD stopped glorifying its past and was realistically looking at its current position in the OS landscape. Until that changes, FreeBSD will be both a lacking desktop OS and a lacking server OS for my daily work.

Licensing should also be considered a technical reason.
-
Shameless plug: a few years ago, I fought the decision of my former employer's licensing counsel. He had ties with FSF Europe, and asked me to relicense my code from BSD to LGPL before publishing it (was private). I vehemently objected and asked to keep my code private instead – on the grounds of permissiveness and technicalities. They conceded. Two years passed, and I got in touch with the company and had the software released using BSD. I share a few details of my reasoning here: https://medium.com/@henvic/opensource-and-go-what-license-f6...

Licensing should absolutely be considered. In fact copyleft is one of the main reasons I'd go with Linux over BSD anytime.
If I am going to invest my precious free time into software development, I want to guarantee to my users that my software will always remain free, (as in freedom).
There's also a community aspect to the BSDs that I strongly don't align with, which is the sort of 'practical, above the fray' mentality that seems to disregard all political/real-world happenings around privacy, encryption, patents, censorship etc. and instead focus purely on the code. To the point of praising any piece of closed-source that has a bit of BSD in it.
While this is perfectly valid short-term, I do think that a movement that goes beyond code and has some ideological foundations is needed.

"Licensing should absolutely be considered", I agree but for all the opposite reasons. I release all my code under MIT/BSD as I do not want anyone, at all, for any reason, to not be able to use my code, for good or for bad as defined by me. I also prefer the BSD community as it lacks the hubris of "a greater mission" that the GPL fosters leading to this notion of good and bad.
Plurality of thought, use and outcomes are a good thing.

Just wanted to point out that the GPL isn't really about 'good'/'bad' morality choices, in fact one of the pillars of copyleft is that it does not make such subjective choices.
If that wasn't the case, companies like IBM wouldn't be able to use GPL'd software, as they famously weren't able with Crockford's "don't do evil" license.
The GPL is really about guarantees.
You rely on guarantees every day to be able to go about your day. People like me just wish to extend certain guarantees, (not warranty), to the software we write.

Even with lets say BSD-licensed code, the code you publish and maintain stays free. There is only the possiblitly that some entity maintains their private fork of your code and distributes that. But that doesn't change the state of the freedom of the code you publish. Also, it is extremely unlikely, that a company does significant changes to a well-maintained code and doesn't push them back upstream, as this reduces their maintenance effort.
Yet, if you want to completely rule out the possiblity of that "propriatary fork", one could amend the license so that the distributor has to include the sources. This is a legitimate request. If one says: "but that is what the GPL does", that is not correct. The blog posted by the parent poster clearly lists a lot of problems with the variations of the GPL license. The LGPL license too much assumes you are using C, and the GPL of course requires you to relicense your own code just to be able to use a GPL-ed library.

GPL does exactly that, prevents the distribution of proprietary forks.
And yes, the GPL does require you to release all your code if you want to use a GPL'd library. It's not "just" a library. The library is presumably needed for your program to function. If yes, there's noting wrong with the author of that library requiring you pass on the same guarantees with your software that you were given by them when you decided to use their library, which they spent their precious time building.

If you had read my post carefully, I was explicitly stating that the GPL does that. But it doesn't exactly that. As I wrote, it imposes a lot of unrelated restrictions to the code usage. And yes, for myself I consider it an unacceptable demand, that I change the license of code unrelated to the library I am using, just because that library wants to impose that. My code might even be more free than the GPL code I would be using, but that doesn't matter to the GPL.
And for that, in the literal sense, in most use cases, GPL is unacceptable for me and consequentely I keep a wide distance to GPL coded libraries.

We're free to make our own licensing choices of course. This is all in an interest of a discussion.
As I said, this is a choice between not passing on any less freedom you yourself received vs the absolute freedom to do whatever.
As far as the GPL is concerned, your code cannot be more free, because it's precisely the limits the GPL imposes that make it valuable.
I'd say the BSD is more "developer-friendly", whereas the GPL is more "user-friendly", in a broader sense.
The BSD licenses are more 'absolutely free' in a libertarian sense, whereas the GPL offers certain guarantees and if your definition of freedom fails within, they're a lot stronger than what BSD offers, but it's not for everybody.

You cannot separate the user from the programmer, because without a programmer there isn't a software for the user to use. And to require to make the source available for any GPL software used in a project is a very valid request. To relicense other parts of the project isn't.

That's just a question of where one software ends and another begins. Essentially, for lawyers to decide.
But that's also why LGPL exists.

The question is clearly determined by copyright law. If I call a function, this doesn't make the calling function a derived work.
LGPL is the GPL variant which is usually reasonable to use, as it doesn't require any other parts of the program to be put under (L)GPL. However, there are some technical details with the license which make problems. It basically assumes that the code put under LGPL is delivered as a shared library. But that doesn't work with many languages. Especially the requirement, that the user needs to be able to modify and relink the code under LGPL is a big headache, if not a deal breaker in many situations.

> The question is clearly determined by copyright law. If I call a function, this doesn't make the calling function a derived work.
It does make the called function a part of your program, however. Because if that function is not available on the target system (in a shared library or whatever), your program will simply blow up.

Well, sure, a missing function will cause the program to fail to function. But what has this to do with the discussion?
The copyright of the program is clearly mine. The copyright of the functions linked into my program is that of the functions copyright holder. The license regulates my right to link the functions in my program. But unfortunately, the license tries to affect my copyrights to my program parts.

It just regulates the conditions under which the (hopefully) dynamic library is distributed.
If the question comes to court (IIUC, this particular case has never been tested), you are just as likely to be ordered to pay for copyright infringement damages, rather than release your software under a GPL-compatible license. You'd have to rewrite it somehow as well, of course.

I honestly cannot fathom the idea of using my time maintaining or developing something that would be used commercially while the user has absolutely no copyleft obligations! well, guess you have to develop your libs then!

BSD and LGPL/GPL type licenses are good for different purposes and intentions and different type of code.
BSD is good when you consider you code as a snapshot that should be maximally available.
GPL is good when you think the code as a long term valuable investment and process that must be protected.
GPL is also really good choise for small to medium businesses with dual licensing. If you want so sell develop a software product and not just a service. If you own full copyright, you can always change the licensee later, so going with GPL first usually the safest choice.

We must have differing definitions of freedom, because I regard the GPL as a severe curtailing of options and equate it with being forced to adopt a narrow, ideological worldview. If anything, this leads to fewer freedoms on use by directly creating more obligations for the user, and if my code is to be of utility for anyone, freedom of use is paramount.
What’s more, and most ironically, copyleft perpetuates the fundamental atrocity of intellectual property law, by hacking it, and therefore intrinsically depending on it; in contrast, the BSD and MIT licenses are mostly a liability waiver under an assertion of attribution, ultimately creations more of necessity than ideology.
I struggle to accept the separate and somewhat animistic notion of code itself being free, having never successfully anthropomorphised a program.

We probably do have different definitions of freedom. My definition is along the lines of yours ends where mine starts, whereas yours sounds more like 'absolute freedom'.
You're right to an extent, the GPL does place certain obligations on the users, in particular to maintain (at least) the level of freedom they themselves were given, which naturally limits what one can do to an extent.
P.S. Yes, it all depends on copyright law, BSD does too, otherwise public domain would suffice.

Funny that GPL does violate your definition of freedom. Because it doesn't end where my freedom starts. It tries to impose a new license of my software linked to the GPL software. And it imposes obligations to the user beyond what the user was given.

You do not have the freedom to just take "my" code and do whatever. The moment you include my GPL'd code, you're stepping onto my ground and thus need to abide by some rules I set out for those that do.
You're still free to not use my code, but not to do as you wish if you do, because at that moment you're stepping onto my own freedom.

I haven't claimed that I am free to do what I wish to do, nor do I ask for that. The point is, that the GPL contradicts what you stated before "yours ends where mine starts". GPL tries to exactly cross that line.

The "your end where mine starts" means precisely that your ability to do whatever ends when you decide to use my code, because that is where my freedom to impose certain requirements on your usage of my code starts.
There's nothing the GPL tries to cross, that's exactly what that quote means in general society as well.
For example, you're free to wear the same shoes you do outside in your own house, but if you're coming into my own house, I have the freedom to require you not to do that.

Yes you have. Telling me to wear different shoes once I visited your house is something different. So if you think that is a reasonable request, then I have to tell you that I will refrain from visiting your house. And advise others to be very considerate about visiting your house.

What makes telling you to wear different shoes any different? I am just asking you to abide by my rules if you're going to make use of my resources.
The GPL does the same.
And yes, you're free to refrain from visiting my house if you disagree with what I am asking of you, same as you're free to not use GPL code and therefore not abide by its requirements.
The only thing you are not free to do is come to my house and ignore my rules, likewise use GPL code and ignore the GPL. That's it.

I don't mind abiding to your rules when I come to your house and while I stay in your house. I find it bizarre that you think that you can impose rules onto me after I left your house and even ask me to impose the rules onto others.

How do you feel about NDAs or official secrets?

What about them? I have no fundamental problem with them. The only reason I would sign an NDA is, when I am doing paid work.

But aren't these examples of having to follow someone else's rules after you've left their house?

So what? It is part of the deal, and as I wrote, I would sign an NDA only for a good reason, that is usually a paid job. Also, the NDA concerns only the specific task and not other things I am doing at that time or later.

If you're using my GPL code, you never 'left my house'. In fact, you're still inside.

> What makes telling you to wear different shoes any different? I am just > asking you to abide by my rules if you're going to make use of my resources. > > The GPL does the same.
Couldn't agree with you more, but Microsoft and other proprietary software makers have the same right (to dictate what people can do with their software). For some reason, GNU believes (as RMS has stated in various talks) that not sharing software is immoral.
Now, is not sharing software immoral because (1) it can be copied at no cost, or (2) because you can't morally tell people what to do with the bits once they have a copy of it ?
(1) is nonsense because creating the software has a cost, and anyway, just because something was free to you doesn't mean you can't charge others for it.
(2) is contradicted by the GPL if it tells you what you can do with the bits after you have them.
You can make the argument that free software results in higher quality software, but it's wrong to make a case for it morally as GNU does.

GPL never says you can't charge for software.
As for immorality, you can read the justifications here starting from item 4 (Voices from the Revolution): https://www.drdobbs.com/the-ethics-of-free-software/18441458...

Thanks for the link - that's an interesting read which I'll have to work through more thoroughly later.
> GPL never says you can't charge for software.
My point is not that the GPL is contradicting itself, but that the GNU philosophy contradicts the GPL.
There is a quote in item 4 at that link you shared, which says:
> I think that to try to own knowledge, to try to > control whether people are allowed to use it, or > to try to stop other people from sharing it, is > sabotage.
Putting a paywall up is a method of control. I think I represented GNU's position fairly.

And where's the contradiction? GPL software is always open, the knowledge is out there, and people can use and share it.
The only thing you're not allowed to do is do a change and "close" it.
It's like you're begrudging freedom fighters their actions because they are violating the feudal rights of their historical oppressors.

you're free to do anything with gpl software that you would be free to do in the absence of the gpl. consequently it in no way limits any freedom; the freedom has been limited by applicable law.
if this is a problem you need to take it up with the relevant legislators in your area. complaining that the fsf or another publisher only returns most of your freedom isn't exactly fair. they have returned most of your freedom but retained the amount that would allow you to restrict someone else's freedom. you only want off them the freedom to restrict someone else's freedom, so it's hypocritical; if there is some benefit to this freedom, then they have fairly exercised it and you lost out.
(i find the fsf's argument that dynamic linking is illegal in the absence of a licence a long bow to draw tho.)

GPL gives freedom to the end user of the software, while (for example) MIT gives freedom to the programmer.
People who think GPL is less free than MIT missed the point of freedom GPL is about.

Without the programmer crafting a program using e.g. a library, there is no software and no end user. You cannot separate the end user from the programmer. And to repeat myself: requiring to make the source available for any GPL software in a project is absolutely a reasonable request. Requiring to relicense other parts of the software, isn't.

>You cannot separate the end user from the programmer.
Bullshit.
The only thing GPL requires you to do is to extend the same freedoms granted to you to the user.
>Requiring to relicense other parts of the software, isn't.
You can absolutely use GPL software without relicensing everything else - split the part that requires use of GPL and extend the freedoms to your users.

Obviously, if the GPL software is a complete application, then that works. See Emacs, see GCC, see Linux.
But not in the space of libraries, where I can't use anything GPLed without relicensing my software.

Why not relicense your software then?

Because the license was chosen with a clear reason. And if that license was not GPL (otherwise the discussion would be moot), this is not an option.

There are many domains where the GPL is not applicable, gaming for one, requires the source to be secret, or else you'll allow anyone to build and release the game easily and thus not recuperating costs of production. This is why most lua libraries are MIT, as something that is heavily used in games, using anything other than is not applicable. It is also the reason rms created the lgpl, as a copyleft library that wont relicense software that depends on it.

> gaming for one, requires the source to be secret, or else you'll allow anyone to build and release the game easily and thus not recuperating costs of production.
The engine is not the game, it's missing all the assets (3D models, textures, audio, scripts, etc). The assets don't need to be GPL-licensed.
Most games use one of the few popular game engines: Unreal Engine, Source or Unity, which while not being open-source, are available to anyone and make it possible for anyone to build and release games with them. That doesn't stop them from making money.

The code and logic of games can be open source (look at Dwarf Fortress or ports of Doom) while the assets are still closed source. The bigger fear I always see is that someone will steal the code and run it without paying. In reality, this almost never happens. People don't care enough to run their own version of the game, or any other software.

Thats wrong. You can put all your work under any permissible license and use any GPL library. The same is true for anyone who get the work from you. No need to re-license anything.
Large programs often use multiple different software licenses without having to relicensing everything to be the same. They just have to be compatible.

You keep saying that requiring other parts of the software to be relicensed isn't reasonable.
It's obviously a matter of opinion, but if your program depends on my code, my code is obviously a part of your program, thus it does not seem unreasonable that you pass the same freedoms to your own users as I gave to you when you were starting and my library saved you time and perhaps made sure that your program was on time and budget.

What is reasonable is indeed a matter of opinion, where not conflicting with laws. You have to accept then though, that what you consider a reasonable demand, might be unreasonable to others, if not offensive.
And please, stop abusing the term "freedom". If the FSF would be honest, they would pitch the GPL without misleading terms. It is amusing, that Linux is one of the most prominent GPL software used, but the FSF managed to antagonize its maintainer.

Freedom isn't that well defined of a concept. Fo example I may say I have the freedom to not be blasted by your loud music, whereas you might say you have the freedom to play it.
Both can be true to a certain extent and both are freedoms. It's just that the context and amount matters.
If a judge decides that you're indeed infringing on my freedoms by blasting the music this loud, your own freedom will be restricted.
The GPL does restrict the freedom to restrict the guarantees it provides.

Right, but it tries to restrict the freedom of software authors to select the license they wish. It does try to restrict the freedom of the programmer to license the part of the software the programmer created.

That's not true.
When you are the sole author of the program, you clearly can choose whatever license you wish.
As long as you don't mooch off the efforts of others.

Freedom is well defined, the freedom you speak of, requires a ruling body to exhert force. By implementing laws freedom itself is modified. Given that the FSF is not the ruling body of software, they should not have a say on what freedom entails. (which is why when speaking of licenses its best to refer as copyfree copyleft and so on.) IMO As a language that is used by all, its best to refer to freedom as copyfree. because that is the most loose definition and the least based on coercion.

>And please, stop abusing the term "freedom".
GPL uses freedom correctly, it's just not freedom to the programmer, but to the end user. No dishonesty, no misleading and no abuse.

No it abuses the concept, because while it claims to assert freedoms, at the same time it tries to takes away others. And the representation of this by the FSF is deceptive. They managed to antagonize Linus Torwalds entirely this way. A person, who should be their strongest supporter.

Every freedom takes away another's freedom to abuse it.

I have this dream where Linus Torvalds would just release his work under MIT/BSD/ISC/public domain...

Even if he did, I don't think the BSDs would change to linux. Plus I imagine many of the contributors contribute because of the license, which would anger them.

And then, suddenly, Linux stops receving the myriad device driver contributions that it does now.

The question of freedom comes when a user then comes to your software and then wants to:
- Use the program for any purpose, - Freely examine the source code, - Make improvements and distribute them to others (in the spirit of being a good neighbor).
These things sound very sensible, don't they? Do you disagree that they should be called "freedoms"?
And those are the freedoms GPL helps protect.

Perhaps you'd like to read Against Intellectual Property by the attorney Stephan Kinsella.
https://mises.org/library/against-intellectual-property-0

Thanks, interesting read. Not a writer with whose principles I necessarily agree with 100% but certainly reaching towards a similar view.

> We must have differing definitions of freedom, because I regard the GPL as a severe curtailing of options and equate it with being forced to adopt a narrow, ideological worldview. If anything, this leads to fewer freedoms on use by directly creating more obligations for the user, and if my code is to be of utility for anyone, freedom of use is paramount.
Please, if you extend my work, let me know what you change, so that I can grow as a developer, aswell as giving the benefits of your work back to my userbase. Obviously you are free to maintain your project on your own and use another licensing for different modules. In fact I believe that these licensing models have strenghten the unix community, but this is a highly personal assumption.
Nonetheless, you are always free to choose your own licensing for your project. Related GPL work, unchanged though, just needs to be ackowledged, right? So you dont have to license your code at all and just throw it at your users - The benefits of possible improvements via GPL unused.
As a user I highly appreciate the GPL, because it promises (not forcing anyone, free licensing, right?) me to inspect the source code shipped with a binary (if any).
To support the minority (original author) against the majority (everyone else) there are implications to them, but desribing it as a narrow ideological worldview forced upon the userbase sounds unreasonably harsh

I will likely be downvoted for saying this, but fuck it.
This "copyleft is free (as in freedom)" claim bothers me. Copyleft is not free (as in freedom). Its more like free (but this gun pointed at your temple will shoot if you do not agree with The One True Philosophy). That doesn't sound like freedom to me; more like thinly veiled tyranny. (I suppose this is mostly the fault of the redefinition of a derivative work, but that's a separate issue).
My definition of freedom means that every individual has the right to their own One True Philosophy, whatever that may be. Wanna write your software in the nude (as in publicly)? Be my guest. Wanna write code for Dept. of Defense missiles (which probably should never, ever be public)? Go nuts, IDGAF. Etc, etc.
The GPL is a mistake for software development. I don't mean that just because of what I said above. It's a mistake because of its infectious nature. Whether or not you or I agree (or any reason, it doesn't matter), you must comply. Like a Borg drone, with no freedom. With a non-copyleft licence, any library will still be useful no matter the licence of the software it's linked to (well, except the aforementioned GPL-ed code). See libstdc++ for an example: if it really were vanilla GPL, nobody would use the STL (or at least, not GCC's STL)!
(Written on my Kubuntu workstation).

As I said elsewhere, I do understand where you're coming from. My definition of freedom is akin to your freedom ends where mine starts, there's also a sort of 'absolute freedom', in the right-leaning libertarian kind of sense i.e. as long as one has the manpower to do it, they can do it. This just sounds like actual tyranny, if you ask me.
The BSD is probably a lot closer to that 'absolute freedom', (not entirely, still requires you to preserve certain copyright texts for example public domain is probably closest).
The GPL simply limits your ability to pass on less guarantees with the software you're distributing than you yourself have received.

>My definition of freedom is akin to your freedom ends where mine starts
That's everyone else's definition too. The disagreement comes from you having the underlying assumption that producing non-GPL software is causing harm, while other people do not share that assumption.
Everyone agrees that your freedom to swing your fist ends where my nose begins, because everyone agrees that punching me is causing harm. But a lot of people do not consider writing software to be causing harm, so they do not see a valid reason to prohibit people from writing software.

GPL is about not passing less freedom to your users than you yourself received. That's it.
You're free not to use GPL'd software, but the moment you do, it's authors are free to impose certain requirements on you, such that you preserve the freedom they gave you for your downstream users.

You're simply ignoring what I said and talking past it.

> (Written on my Kubuntu workstation)
Exactly.
Don't be a bee protesting against honey.

Copyleft is NOT free as in freedom. Period.

> I want to guarantee to my users that my software will always remain free [...]
I always found this argument for GPL a little uncomfortable because of what it implies... let's be more precise: the existing code you publish whether using GPL or BSD will always remain free (it is irrevocably free); copyleft makes a distinction for freedom of derivatives i.e GPL forces people to make all future code free as well, this is about enforcing future investment not remaining free.
To be clear I'm not dogmatic about either, I think both copyleft and permissive licenses have their place - it's simply subjective - some software feels more suited to GPL and others more suited to BSD.

That might be the primary distinction between the two.

What usage this article is talking about? For a server? For a desktop environment?
For servers, me and my colleagues use Linux, and not being able to use Docker is a tough call, our workflow is very Docker-centered. I know that Jails exist, but it's not just about containment, it's about packaging, building and deploying too, and having ready-made tools (and a lot of existing Dockerfiles) for that.
For desktop, I use macOS, and I'm not willing to change if it worsens the experience, which I suspect it will do.
I wonder what would be the killer use for FreeBSD today? I'd be eager to try, since I'm eager to try all kinds of stuff, but I fail to find any place I could easily stray from my current OS combination.

I've been a FreeBSD user since 2.05 (1995) and a strong supporter - FreeBSD still excels as an ultra-stable 'old-school' UNIX server OS (which to be honest meets a lot of use-cases more simply than a lot of modern alternatives). That being said this sort of post isn't helpful as advocacy - as others have notes it is pretty shallow and to be honest most people are probably better off running Linux if this is what they are used to.

+1! Thank you!
Been using FreeBSD for 20 years. If one's reason for using FreeBSD is that they dislike GNU/Linux, then something's very wrong from the start.

"those who hate windows use linux, those who love unix use BSD."

As a longtime user of both FreeBSD and various Linux distros, I agree with a lot of points regarding the coherence and ergonomics of FreeBSD’s design. However, I don’t generally run FreeBSD anymore, despite enjoying using it more, simply for the reason of security. I don’t feel (and maybe this is just a feeling) that security is a first class citizen on FreeBSD the way it is in Linux distros like Fedora or Ubuntu. Things can be slow to be patched and the defaults aren’t always particularly secure. I really miss ZFS though. Btrfs just isn’t as nice to work with.

Really? Here I thought FreeBSD puts security before everything. This comment is surprising to me.

Yeah I don’t think one or the other is inherently better but Linux definitely gets more users and is more “tested” so things like drivers and software will have better support.

Why not use ZFS on Linux?

It will never be in-tree, short of an act by Larry Ellison.
Depending on an out-of-tree module can get pretty crappy on Linux. The upstream kernel will break you a lot. If your distro is on top of keeping your out-of-tree feature working then great. It gets messy whenever that is not the case and/or suddenly you want a driver or feature only available in a newer kernel.

Filesystem and Distro/OS are part of one choice imo.

Larry Ellison can't relicense ZoL - they'd have to start from scratch porting the code from Solaris

I think people typically mean that Larry Ellison could come out and say there are no issues with incorporating CDDL code into a GPLv2 code base. Ideally in a document signed by him and lawyers at Oracle given to the Linux Foundation. If that happened I don't think people would have an issue adding ZoL to the kernel.

There are no issues on the side of CDDL anyway.
Larry can't change the fact that GPL is the source of incompatibility - the general interpretation is that GPLv2 forbids code that has stricter licensing terms than GPLv2, and CDDL happens to have that - in form of patent grant.
It's also why GPLv3 code has a license issue with Linux kernel, which is GPLv2.

They can relicense Oracle-owned code under GPL. As just one example.
There are probably other options, too.

Yes, and it would require starting the port from zero, as I have said.

Nah, it's the same code. There would be no need to create a new derivative work.
It's a pipe dream anyway, of course.

It's not the same code - OpenZFS has substantially diverged from ZFS v28 which was last common version between OpenZFS and Solaris, that's one thing.
Another is that all the porting work in ZoL that isn't already GPLv2 is CDDL - and Oracle is not the copyright owner. In fact, the copyright owners would not want to change the license to GPLv2, unless maybe it was done as dual license.

I was being a bit flippant rather than literal with the Ellison comment. I think I read a similar joke on an LKML thread or similar once.

Opinions and dogma about licensing is one reason as well as a sense that ZFS isn't actually better than ETX4. I'm not saying I agree with that, only that it's why ZFS and Linux don't mix from what I can tell.

It would appear canonical disagrees.

ZFS and EXT4 have different use cases.

ZFS and EXT4 on LVM have a lot of overlap. A decade or so ago I made a comparison between ZFS, BtrFS, and EXT4 on LVM [0] that may be of interest.
[0] https://rkeene.org/projects/info/wiki/BtrFS

The checksumming/error-correction of ZFS is big difference, and the main reason I moved some of my file systems to ZFS (even with versioned backups, on EXT4, I suffered data loss due to corruption/bitrot).
On the other hand, for a simple set-up on a lower resource system, EXT4 has lots of advantages.

A good, controversial read is available at [0]. I don't agree with his conclusions entirely, but the data he presents is interesting. And also paired with [1] to give space overhead and MTBF figures for various RAID configurations (where RAID-Z ~= RAID5, RAID-Z2 ~= RAID6)
[0] https://www.jodybruchon.com/2017/03/07/zfs-wont-save-you-fan...
[1] https://rkeene.org/projects/info/wiki/221

From experience, as I said, I had bitrot on EXT4, with carefully versioned backups, but it didn't help, since the bitrot was just faithfully propagated through all the backups (I didn't have 5+ year backups - who knows when the bitrot occurred).
And I haven't experienced file corruption in the 5+ years I've used ZFS. Of course, ZFS isn't a magic bullet that solves all ills, but I've been very happy with it. I still, of course, have multiple backups of important data, but now I'm more confident about the integrity of those backups.

I wasn't aware that anyone thinks ZFS is no better than ext4. Surely the interest in developing Btrfs and Bcachefs, with features obviously meant to compete with ZFS, would suggest that mostly people think it is? And you also have Canonical adopting ZFS outright, and Red Hat working on improving XFS as an alternative file system.

I prefer BSD because I find managing kernel modules and system startup much more straightforward.
I also like that the placement of different kinds of files is much more standardized, which makes them easier to find and it also makes it a lot easier to manager a cluster of developer machines where each dev has different needs, because you can still be reasonably sure that all of their customizations will be in /usr/local.
The other thing I'll throw out here is that Netflix chose BSD for their base system on OpenConnect because they were unable to get Linux to match the networking performance of BSD when delivering large files.

It's a little weird to not put some of these headliner features at the top of the list. Like ZFS (in-tree, on the default installer, without licensing issues or hostile team dynamics).
On the other hand there are things in this list which are just the FreeBSD equivalent of something Linux has in some form. The ports tree is good, and I like that you can customize options etc., and now pkg is pretty good, but are you really going to miss that if you have apt or similar?

Aren’t Linux and freebsd using the same zfs fork at this point though?

I am not following closely enough to know when that makes it into a stable FreeBSD release, but yes it will be.
Except for one point: the zfs on Linux work is not in the mainline kernel, and won't be. A strict interpretation of your comment would actually be "no" - can it really be said that "Linux is using it" in that case? You need out-of-tree kernel support which is very difficult to maintain.

Whatevery floats your boat. I use linux, docker and kubernetes all in the cloud. I'm getting more distant from underlying OS everyday.
BSD is a fine operating system. There is nothing wrong with it. Linux is a good operating system and gets the job done. Whatever works.
I think what is more concerning is that we really haven't had a big leap in hardware, OS, and system design for sometime. When are we going to have the guts to make the next step?

I’d argue NixOS is a huge step that a lot of people still have to catch on to (to be fair: that includes more contributors to improve documentation and ergonomics, but it is already valuable and workable as it is)

What can we do beyond posix?

Working on this!
Check out the NixOS for existing sysadmins workshop over at https://github.com/ghuntley/workshops/tree/master/nixos-work...
If you want a TL;DR overview of NixOS then start here https://github.com/ghuntley/workshops/tree/master/nixos-work...

Something I wonder about after reading your overview - software from outwith the package manager.
It's quite often that the package manager in the Linux distro I'm using has an old version of Nginx, PHP, or whatever, and so I have to build my own, or at least use an alternative package source.
How is this kind of thing handled with NixOS config? (if it is)

Pinning and override layers
https://github.com/digital-asset/daml/blob/master/nix/nixpkg...

I'm kinda confused.
The author berates Debian for patching many upstream software packages to conform to "the Debian way", and then says:
> The kernel and base system is completely separated from the third party applications and base system configuration goes into /etc while all third party configuration goes into /usr/local/etc.
Doesn't that mean that FreeBSD has to patch all third-party software to look for its configuration in /usr/local/etc, creating a "FreeBSD way" that is just as much at risk as breaking upstream software, making its documentation not apply etc. as the Debian software?
Or is there a real, technical difference that makes one kind of modification less intrusive than the other?

Most software can be compiled with --prefix=/usr/local, and then it will store stuff in /usr/local/share, /usr/local/etc, and so forth.
In fact, /usr/local is actually the default for a lot of programs; you manually have to specifically --prefix=/usr if you want to use that.
I used to maintain a bunch of FreeBSD ports, and whenever this wasn't supported I'd send a patch upstream, which was pretty much always accepted. In a few cases: yeah, you'll have to patch the paths, which is not ideal, but it's a lot less patching than what Debian does, which often has more changes and backports security fixes etc.

When you build a package from source with ./configure, it generally defaults to /usr/local/etc. Oddly, the Linux way of putting all third party configs in /etc is actually what's weird.

Considering most unix software is written on linux for linux these days, and has been for many years, its extremely unlikely what you say is true.

Take a look here: https://www.gnu.org/prep/standards/html_node/Directory-Varia...
"The default value of prefix should be /usr/local"
On traditional Unix systems, /usr was reserved for the operating system. /usr/local is 3rd party software. This is how Solaris behaves. This is how the BSD's behave. The Linux approach is the exception, not the rule.

the fact that 99(.99?)% of modern unix systems are linux systems makes it the rule, not the exception.

What you say is true. I can see it both ways. There's also the issue that Linux is "only" the kernel, so all software is third party software. There is no differentiation between "core OS" and "third party" like you have on other platforms.

In a perfect world I'd probably use FreeBSD in all the places I currently use Linux. I however don't live in a perfect world so I haven't used FreeBSD for anything significant in over a decade.
My number one problem with FreeBSD (and OpenBSD) has been hardware support. I got an HPE Microserver to use as a compact centralized storage. No matter what I could not get FreeBSD even booting on the machine. It's got an AMD APU and apparently FreeBSD has zero support for it. With Ubuntu I had zero installation issues and still got to use ZFS for storage.
Similarly I have a SFF AMD box to use as a router. While FreeBSD would boot on it, every few weeks it would kernel panic and need to be power cycled because FreeBSD shit the bed with the Ethernet cards in it. Ubuntu with the same exact usage patterns has given me absolutely no trouble.
I've never been able to get FreeBSD fully working on a laptop. Something is always broken (usually WiFi) and power management sucks. It's also entirely inconvenient to have to power down the laptop because it won't wake up when opening the lid.
My second major problem has been a lot of seemingly advanced features in FreeBSD are very experimental or simply difficult to use properly. While FreeBSD's Jails are very sophisticated they are a pain in the ass to manage and there's multiple management tools available with wildly different levels of functionality.
I want FreeBSD to exist and keep pushing forward but I've given up on using it. None of its technical features can make up for the fact it won't run or run well on hardware I actually own. Advanced features don't mean much to me if I can't use them effectively.
I'm not developing FreeBSD (or Linux), my interest in them extends about as far as launching other pieces of software I want to use or that I'm writing. I'm not typically pushing the limits of the systems so interesting optimizations around edge cases don't mean much to me. I don't get paid to support myself or my personal projects so I'm just going to go with the system offering the least hassle. That hasn't been FreeBSD since the 4.x days (compared to contemporary Linux distros).

>It's got an AMD APU and apparently FreeBSD has zero support for it.
When's the last time you tried. I don't remember if I've run FreeBSD on it, but I have a cheap board with an AMD APU that's run NetBSD within the last year.
> I've never been able to get FreeBSD fully working on a laptop. Something is always broken (usually WiFi)
Yeah WiFi support is super shaky seemingly across all BSDs. I had to make a small patch to an existing kernel driver to get it to work with one of my Realtek cards in FreeBSD. To my knowledge the same card will cause panics in NetBSD when the driver is attached and I have an Intel WiFi card broken in DragobflyBSD.

> When's the last time you tried. I don't remember if I've run FreeBSD on it, but I have a cheap board with an AMD APU that's run NetBSD within the last year.
It's been two or three years since I last bothered. While FreeBSD's support for the board might be better there's no real upside for me to even try installing it. The router box has been happily running in a closet for years. Best case scenario is it does exactly what it does now with minimal effort on my part. It's not worth the effort.
This is my common refrain whenever I think about using FreeBSD for a project. I'll most likely end up with some set of things I need to fix or debug. Each problem then saps my time, motivation, and patience. It's an order of magnitude easier to just use Linux and save my energy for interesting parts of a project.

It's been said a million times- FreeBSD is an operating system, Linux is a kernel. ("GNU/Linux" is a strange beast- kernel+libc or what?). It's a tough direct comparison to make especially when you consider things like documentation (which FreeBSD is often cited as being exceptional)

> ("GNU/Linux" is a strange beast- kernel+libc or what?)
Kernel plus userspace: the standard command-line tools, compilers and some additional stuff. Such as GNOME, for instance (it's considered a part of the GNU project).

>The kernel and base system is completely separated from the third party applications and base system configuration goes into /etc while all third party configuration goes into /usr/local/etc. Everything you can configure and everything you can tune or setup is very well documented in the man pages.
One thing I find ironic about BSDs is that their top billing feature is being a "complete integrated (base) operating system" rather than a collection of software maintained by different projects, but at the same time, they're almost always discussed as server/poweruser operating systems rather than desktop operating systems. This seems completely backwards to me.
If I'm a sysadmin running a server, I probably know what I'm doing and feel confident replacing parts of it. I likely studied this and relative to a typical person I'm much more likely to find the way it works to be interesting. By contrast if I'm a desktop user there's a very good chance I don't know what I'm doing and don't really want to. It seems like the second situation is the one where you benefit more from having a wall up that separates the system from the userlibs.
There have been fleeting attempts to make desktop-forward BSD distributions over the years, including PC-BSD and a few short-lived initiatives by the NetBSD project, but it never gets off the ground. Is this a missed opportunity?

I've been a long time OpenBSD, FreeBSD and Linux user (I use Windows for mainly for work though). I've given up with the BSDs tbh. While I like that I can understand these systems. Linux is just easier to get things working on. There is just more information now out there for Linux as it is the defacto *nix out there. So it may well be that BSD has many technical merits, they tend not to be all that useful when you are trying to get stuff done.

I have dabbled in BSDs (mainly OpenBSD) but can't stick with any of them because Docker doesn't work without virtualizing Linux. If I have to have a separate setup for "real work" versus hobby work, then it's a non-starter for me; I don't have enough time or brain capacity.
I like the idea of BSDs as this self-contained system (like the polish of Apple's walled garden but without the tyranny), but it is too far behind the cutting edge.

Slackware lines up more with the original philosophy this article talks about. I like taking Slackware in either stable or -current and running it in this article instead of Debian ... If you wanna run Linux with a distro that hasnt changed its overall philosophy, structure, or hell even core software you should be looking at Slackware again. 15 will likely be out this year.

If Linux were a railroad, FreeBSD would be a model railroad club. Nice stuff, in a way, and very similar to the real thing, but lacking a certain industrial usefulness.

Not at all. FreeBSD is without doubt on equal footing with Linux in terms of industrial usefulness, assuming the features you seek are available. Large companies use FreeBSD in production for mission critical apps but are generally less vocal about it.

Wow it really sounds like FreeBSD is the-right-thing to choose. Except I can't tell anyone I know to install it because it does not come with a simple installer or a working desktop. I got interested in Windows because I grew up with it, and only later I got curious of how it worked behind the scenes. When I first installed Linux I had no idea on how to use the terminal, what a package manager was, compile programs or even what a DE was. I learned it because I was able to install it on my machine in less that an hour. It doesn't matter how good your train engine is, if it ain't got no seats, people won't come aboard. https://en.m.wikipedia.org/wiki/Worse_is_better

FreeBSD used to be a Swiss watch of an OS - I used 4.8 (IIRC) to run a VPS for a few years and couldn't be happier; nowadays, looks like FreeBSD is on par or even lagging behind Linux in all respects.

How do e.g. the sections about bhyve and Bastille describe Technical reasons to choose FreeBSD over GNU/Linux? The describe features, but they tell me nothing about why those might be better than counterparts in the Linux world.

Excerpt:
"With jail it is possible to create various virtual machines, each having its own set of utilities installed and its own configuration.
This makes it a safe way to try out software.
For example, it is possible to run different versions or try different configurations of a web server package in different jails. And since the jail is limited to a narrow scope, the effects of a misconfiguration or mistake (even if done by the in-jail superuser) does not jeopardize the rest of the system's integrity. Since nothing has actually been modified outside of the jail, "changes" can be discarded by deleting the jail's copy of the directory tree."

Wow I see no mention of no systemd in FreeBSD here.
I love how unified the freebsd maintenance and just general system utilities are. The documentation doesn’t lie. I’ve never had a bsd box stop booting because of a wonky system change either.

> Wow I see no mention of no systemd in FreeBSD here.
The author wrote about it in the "part 1" article linked in the introduction.

"...there isn't such as thing as "the Arch way". The Arch Linux distribution want third party software to be as upstream has made them, so they do not change anything unless absolutely necessary"
Gosh! This is exactly how I feel about Arch. And FreeBSD seems consistent until you step outside of the base, and then, it's just a pain in the pass, because so many software nowadays is build on the assumption of running Linux/bash/gnu textutils, etc.

I run Ubuntu as my daily driver primarily for its broad 3rd party application support. As such I tend to run Ubuntu on servers as well, so I'm usually in familiar territory. I have a smart friend who extols the benefits of FreeBSD, but I haven't ever given it a serious go. Is there a canonical/non-hacky way to run debian packages on FreeBSD? Like can I run Slack and Zoom? Steam?

Most of these points are debated in Brendan Gregg's "Solaris to Linux Migration" blog post from 2017: http://www.brendangregg.com/blog/2017-09-05/solaris-to-linux...
The only point of Brendan's that I don't agree with is ZFS as it really doesn't have a strong competitor (yet). Thankfully, it also doesn't need to be on every machine - my desktops/laptops/deployed servers are treated like cattle not pets.
I love FreeBSD/OpenBSD's simplicity and principled design, but I've sadly relegated them to specific purpose servers at work and at home because I kept hitting enough speedbumps that IMO preclude them from being used in a more general sense.

My frustration with BSD is in the desktop arena when wanting to use a laptop. Want to use modern laptop hardware? Good luck. I get that this use isn't the core that BSD focuses on, but seriously, it's a huge potential market for people that want a secure/stable system. Right now you either need to use extremely old hardware (Thinkpad T60 era) or face many obstacles. Which is a pity.

This is a lie: no you don't need to use old hardware. I use a Thinkpad X1 Carbon (5th gen) and everything sans-fingerprint-reader works perfectly with FreeBSD 12.1, entirely built from source and ports. The trackpad even works buttery smooth, with inertial scrolling using the Synaptics X driver.

Long time "intermittent" FreeBSD user here.
I always liked the naming (e.g. NICs) and location of things in FreeBSD, felt more natural to me. It may not be a (good) technical reason, but it makes live so much easier when you know that if I install something it's in '/usr/local'. That said, not sure if it's fair to compare FreeBSD (1 distro) with Linux (many distros).

I am running both at the moment but I must say that I am warming more to FreeBSD, reminds me of the early Linux days, before the systemd wars.

Only thing that is holding me back from using FreeBSD (and other BSD) is hardware compatibility. Linux supports far more hardware devices, such as SATA controller/HBA and network cards, it seems. I've used FreeBSD (and other BSD) and it was really pleasant to see a well laid out and well thought out OS, unlike Linux which felt like a collection of after thoughts.

Ultimately, when we are being honest, there are no technical reasons to prefer FreeBSD. Or Linux. Both work. You can probably build whatever you need to on either one (with a few exceptions, e.g. AMD) and both will work about as well. There are differences, but the importance of each difference is a matter of preference, environment, and history.

This seems more so like a list of differences, without any details as to what makes them different, let alone which is better...

In 2000, I was working on a large Solaris x86 system. It was a daily struggle to get and keep anything at all working. I needed a VNC server to hold state across laptop crashes, sleeps, wifi glitches, etc. I chose FreeBSD because I just needed one thing in my work life that actually worked. I loved it then, and I'd choose it again today.

If you really like Windows and/or MacOS, you will probably be disappointed in the desktops available on Linux and FreeBSD.
But the opposite is also true. After years running Xfce and GNOME in Linux, I went back to Windows 10.
First I had to replicate my workflow, which meant using a lot of programs that could be run on any system.
Then, aside from the Microsoft updates and all the problems they cause, the total lack of package management for applications makes even more work.
I had WSL, and that is great, but running a terminal in Linux (or MacOS, even) is just easier when everything can be accessed by any program in or out of the console.
Eventually I realized I was fighting Windows with little upside. I got an M.2 SSD, installed Debian Stable (after 2 years of Windows, I REALLY didn't want a lot of updates), and everything is running great.
If you depend on Microsoft Office and/or Adobe Creative Suite apps, that's a reason to prefer Windows or MacOS. Otherwise, you can do very well — and maybe even better — with the Linux desktop of your choice.
My current laptop is three years old. GNOME 3 runs great. It's extremely responsive, and I like the way it works with the "hot corner," super key and desktop search. I use a few GNOME Shell Extensions, but not too many.
I really don't understand why developers are so enamored with Apple. Unless you are developing for Mac or iPhone, a good Linux distro, or even Windows 10, seems to be a better if not equal choice.
I managed to get my hands on an iMac, and I set it up to see how I'd like MacOS. Getting it "right" was harder than Windows, and I was really surprised at how super slow Homebrew could be. It really made me appreciate Debian's apt — and even Fedora's dnf.
Mac's Finder doesn't compare well to Windows' File Explorer (is that what they call it?) or Nautilus/Files in GNOME.
One thing Windows 10 and MacOS do well is support HD and UHD screens without fiddling. Linux desktop developers need to finally realize that HD (1920x1080) is now the baseline, and 4K-ish resolutions are common and should be completely supported out of the box.
My comfort level with Linux is high, and when I spend most of my time in the same web browsers, in addition to the file manager and text editors, it made sense for me to switch back. Windows is too much work with too little upside.

I don't disagree, but are there business reasons to do it? As far as I can tell there aren't, but there are good reasons not to, such as hiring and support. Are there any people here who could make a business case as well as a technical case? I'd be fascinated to hear it.

I know people who insist on using FreeBSD, or worse OpenBSD, and they often have issues with their work systems.
This is unacceptable to me. My work system must work.
So I don't care about your theoretical list because I know for a fact that Linux is better for me in practice.

I keep fixing my colleagues Linux issues. In practice, I have spent less time fixing my own BSD systems.
I usually end up stuck with Linux systems at work because of proprietary code which doesn't run on BSD.

And in UNIX tradition, zero reasons for anyone that cares about graphics and multimedia.

Is the ports system similar to Gentoo's portage/ebuild system? I can get sources, configure the build, or get binaries (for some things) pretty easy through it.
The QA with the build farm would be nice though.

technical merits, can be plenty. however how does freeBSD integrate with the rest of the I wanna get things done ecosystem of people n software. Can I easily install it on a laptop such as a thinkpad and have a plug and play experience. Can I easily update and find packages | software I need. if Open source software approached things from the usability view, we wouldn't be beholden to corporate interests. I personally, use KDE on a thinkpad

It has been a couple of months since I messed with it, but I don't remember there being a way to do source based, weighted, or blackhole routes on freebsd.

I'm seriously unconvinced there are any aside from personal preference and I've been using BSD since 4.1 on a vax. I still think 32v was near perfect.

Funny coincidence. Last night before I went to sleep I was looking up the differences between BSD and Linus.

The moment I stopped caring about these arguments is the moment I got a little more happiness in my life.

In the context of PF:
> Logs may be monitored using standard utilities such as tcpdump.
This sounds unusual and not entirely practical?

Technical reasons to choose gnu/Linux over freebsd: I can choose among one of the top distros, boot the installer on my laptop and most (if not all) the hardware will be detected and will work properly.

Who care about OSes, when you have container, and VM ?

Use the best tool for the job I say. If it’s BSD for you or your project then so be it. If it’s Linux then use that.

And use this article to figure out whether BSD is better than Linux for you or your project, right?

Ok, that's funny.

I was just trying to get ahead of the inevitable flame war that will ensue regarding this topic.
I didn’t know about some features in BSD though so I did find the article useful.

id rather see this on openbsd

Linux is a Boeing (a 737 Max, if you ask certain people), OpenBSD is a Cessna.
If you do a direct comparison, OpenBSD would lose in terms of benchmarks, hardware support, software support, features, etc.
But OpenBSD is more a philosophy, a particular way to approach computing that works for some people. OpenBSD is basically a continuation of Unix from the 80s, where the admin/user (no distinction in reality) is expected to do some work from the command line. Thus it's a great user experience. The config files tend to have the same syntax, and it's human-friendly syntax, not some XML or YAML crap designed for a tool. Things are kept simple so human brains can understand them.
But the trade-off is basically features, performance, hardware and software support. It's a bitter pill but, again, it works for some people.
I use OpenBSD full time on my router, but I tend to switch back and forth on laptop and servers (with Debian).

When Linux is a Boeing 737Max, then FreeBSD is a Airbus A380 and OpenBSD is a A-10 Warthog. xD

What I dislike about these sorts of articles is that they try to pretend as if *BSDs weren't heavily dependent on the wider FLOSS community, which is mostly Linux-based.
They instead focus on minuscule differences, which you could maybe argue are a bit better from a design perspective, (the default file system layout for example), but in practical terms matter little.
On the other hand, they don't mention the fact that the reason OpenBSD is so "secure", is because their marketing focuses on the default install, which has almost nothing.
So the moment you install the minimum amount of packages to get your work done, the "only two remote holes" thing no longer holds.
When you point out the practically abyssal modern laptop support in FreeBSD, they just shrug because "macOS's also BSD".
Then there's the whole smugness towards Linux as if they weren't dependent on GCC for years, as if GNOME/KDE etc. wasn't a primarily Linux effort and as if ZFS was somehow their invention.
They'll sing about BSD Jails and how Docker is strictly inferior, (also ignoring LXC), while not having any even remotely equivalent frontend for BSD Jails.
They'd laugh at the systemd debates, while talking openly about maybe them doing something similar.
Now Linux also heavily depends on some parts of BSD, but you'd see hardly anybody thrashing OpenSSH, just because it's BSD.
It's just not a community I want to be a part of, that's before I get into the whole BSD vs GPL debate, but I do understand that the appeal is there for some and that's perfectly fine.

For what it’s worth, we see this level of “smugness” from GPL proponents everywhere. Especially the self-superiority. It’s what puts me (not that that has a massive impact on what anyone thinks!), and I’m sure others, off being part of the Linux community. In truth, what we are both seeing is a minority of loud voices that force their opinions, often as fact (this article being an excellent example), onto the world at large and taint it for all concerned. Freedom, especially of speech should never be expressed as a right. It’s a privilege that is all to often abused.

> On the other hand, they don't mention the fact that the reason OpenBSD is so "secure", is because their marketing focuses on the default install, which has almost nothing.
Which in my opinion rather shows that to be (rather) secure, the system has to be kept as minimal as possible. This is (in my opinion) a lesson that the GNU/Linux advocates should learn and embrace (just to mention one emotive word: systemd).
> as if ZFS was somehow their invention.
ZFS was an invention of Sun/Solaris, not the Linux ecosystem.

There are various kinds of Linux distributions, some super minimalist, others not so much. The point of having various distributions is exactly that, you have a choice.
> systemd
It indeed tends to be an emotive word, but just saying 'systemd' as if that's automatically saying something isn't helping either.
There's things one could criticize about systemd, a lot systemd has going for it and many would argue that having a predictable, well-defined, declarative service definition syntax, that's consistent no matter the package or system, vs various sets of init shell scripts that probably wary quite widely in quality and are just slightly different across the *BSDs to possibly surprise you, is what makes systemd in fact better.
As for ZFS not being invented in the Linux ecosystem, I haven't claimed that, just that it wasn't FreeBSD either.

Better ZFS support would be a good technical reason to use one system over another, so it makes sense to mention it. I did not get the vibe of ZFS being FreeBSD thing either.
PS: I use both Linux (CentOS) and FreeBSD (home server with ZFS).

Regarding OpenBSD and security it is far easier to have secure system when starting with everything disabled and only enabling what is needed. When things are enabled by default often disabling them breaks something, and to not waste time creating extra problems most people leave them enabled.
OBSD also has a lot of changes that increase security overall. They prioritise security over performance. It's not just the minimal installation.
Regarding Docker vs BSD Jails (or more correct comparison is LXC vs BSD Jails) is that containers in Linux is combination of namespaces + cgroups. That design gives much more flexibility, but is far far harder to make them secure. There was a submission not long ago taking about it.

> When you point out the practically abyssal modern laptop support in FreeBSD, they just shrug because "macOS's also BSD".
You're wrong. No you don't need to use old hardware. I use a Thinkpad X1 Carbon (5th gen) and everything sans-fingerprint-reader works perfectly with FreeBSD 12.1, entirely built from source and ports. The trackpad even works buttery smooth, with inertial scrolling using the Synaptics X driver.

> They instead focus on minuscule differences, which you could maybe argue are a bit better from a design perspective, (the default file system layout for example), but in practical terms matter little.
Why do you even bring this up? This article is pretty technical and in depth. Why would you bring up something that annoys you about comparisons of "these sorts" while this comparison does no such thing?
> What I dislike about these sorts of articles is that they try to pretend as if *BSDs weren't heavily dependent on the wider FLOSS community, which is mostly Linux-based.
What does that even mean? There was FLOSS before Linux. There would also be FLOSS without the BSD's. There would also be FLOSS without Linux.
> They'll sing about BSD Jails and how Docker is strictly inferior, (also ignoring LXC), while not having any even remotely equivalent frontend for BSD Jails.
Ironically I remember all to well that ease of use via a UI was the argument Microsoft primarily made against Linux in the 90s and 00s when the mantra was definitely NOT "nobody ever got fired for using Linux" .
> On the other hand, they don't mention the fact that the reason OpenBSD is so "secure", is because their marketing focuses on the default install, which has almost nothing.
OpenBSD's focus on security has nothing to do with the "only 2 holes in the default install" slogan. When having to choose OpenBSD will not compromise on security. For example OpenBSD had already figured out SMT (Hyper threading) could never be made secure (and disabled it) before spectre and meltdown came along.
> They'd laugh at the systemd debates, while talking openly about maybe them doing something similar.
Your confusing implementation with concept here. Not many people deny that a system layer type of thing is needed. But there is a big difference between what for example Solaris SMF or Apple's Launchd (system layer implementations) considers to be "in the scope" of such a system vs what systemd thinks should be in scope.

And IIRC ZFS used by FreeBSD now is based on the ZFSonLinux project.

> What I dislike about these sorts of articles is that they try to pretend as if BSDs weren't heavily dependent on the wider FLOSS community, which is mostly Linux-based.
Yeah, let's talk about chickens and eggs:
* https://en.wikipedia.org/wiki/History_of_the_Berkeley_Softwa...
* https://en.wikipedia.org/wiki/Berkeley_sockets
* https://en.wikipedia.org/wiki/BIND#History
* https://en.wikipedia.org/wiki/Vi
* https://en.wikipedia.org/wiki/Berkeley_printing_system
* https://en.wikipedia.org/wiki/Sendmail

You do realize none of these originated with any of the current BSDs, right?
The lineage is there, sure, but it's not FreeBSD/OpenBSD/NetBSD nor DragonFly where any of what you linked originated.
That's not to say there's no useful software that originated from today's BSDs - there is, just not the above.

>> What I dislike about these sorts of articles is that they try to pretend as if BSDs weren't heavily dependent on the wider FLOSS community, which is mostly Linux-based.
> You do realize none of these originated with any of the current BSDs, right?
You do realize that that there was a wider FLOSS community before Linux came around, right?
We're all "building on the shoulders of giants" as they say, and Linux is no different here than BSD.

The point was about who contributes the wast majority of the work nowdays.
Also, before GNU there indeed wasn't much of a FLOSS community in the modern sense, it was much closer to colleagues sharing program tapes with their modifications as a courtesy.
So sure, there were programmers sharing code between each other, but that was kind of informal sharing, more because nobody placed much value on software alone at the time and university labs didn't always wanted to start from scratch.
In fact the reason RMS started GNU in the first place was precisely because he felt that kind of sharing culture was being eroded.

> as if BSDs weren't heavily dependent on the wider FLOSS community, which is mostly Linux-based
They existed before Linux, and an awful lot of network and systems infrastructure is running BSD derivatives.
Tech is a rich ecosystem not a pissing contest, nor is it a dependency hierarchy, and even if it were I can tell you that Linux is not the fundamental substrate.
This slandering of a community is a baseless and poorly informed rant, and particularly misrepresents the original article through a narrow and dogmatic lens.

I would be totally on board with using FreeBSD as my primary server OS .. if it had a container engine. There was a port of Docker to FreeBSD, but it's ancient and unmaintained (before Docker did their big modular refactor).
In theory, you could implement a lot of the Docker Engine API for FreeBSD and on the backend use jails instead of namespaces/cgroups and ZFS if you wanted implement the same layering. Some of the security and cgroup limits may not be implementable on FreeBSD, but with the Linux binary emulation layer, you should still be able to run a lot of containers without modification (unless they need certain filecaps or privileges).
I had OpenBSD on a laptop once, but without 802.11ac support, you'll either have to downgrade the Wi-Fi card in newer laptops or use a USB adapter.

huh, watchutalkinbout?
https://en.m.wikipedia.org/wiki/Bhyve

That's a hypervisor. It's not the same thing as Docker. Docker is more like jails.

The fact that the Docker port was allowed to die is a pretty good indicator of how little interest there is in using FreeBSD in the industry, particularly in cloud environments.

"jails" are the native solution for FreeBSD. You wouldn't set up a FreeBSD server to run docker.

Most companies would rather use Docker than jails and that alone is a reason to avoid BSD.

That's fine. I've been running various Linux distros since 1993 and FreeBSD since 1996. Each has its strengths and weaknesses.

And how can I run OCI-compliant image straight to the jail? Docker isn't just a namespaced runtime.

It's simple: You shouldn't run Docker images on FreeBSD.

Wrong answer. This means you can't run modern cloud-native apps on BSD.

Tell that to companies like Netflix: https://www.phoronix.com/scan.php?page=news_item&px=Netflix-...
Not all applications require Docker.

Last I checked, FreeBSD is only used in their CDN appliances and Netflix is deploying their services in containers on Linux.

As I said, Linux and FreeBSD have their strengths and weaknesses. I use both, and definitely wouldn't deploy certain types of applications under FreeBSD.

You are probably still right but MIT license means that you just won't see what industry uses. Industry has used free BSDs and not contributed in code or money nearly to the extent that it has for some Linux flavors.

The license has nothing to do with that. GPL2 doesn't require industry to contribute back either. I decline to speculate on why industry adopts Linux.

A bit of it had to do with the SCO lawsuits, it had a freezing effect on BSD and it's adoption numbers dropped way behind Linux after that and never really recovered.

That wasn't SCO. It was an earlier set of lawsuits by AT&T because 4.4 BSD had evolved from AT&T unix.

Your right, It's been a while and I got the two mixed up. Funny how time can play tricks on memory. It was the AT&T lawsuit. SCO was Linux. Sorry for the misinformation. IIRC Linux had come out a few years before the BSD lawsuit, but I do recall a time when they where neck and neck and BSD started dealing with the legal issues and it just seemed like Linux keep on gaining traction after that.

The SCO lawsuit targeted Linux vendors:
https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes
Earlier a USL (Unix System Lab) lawsuit went after some BSD stuff:
https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....

From what I understand, this was a question and was answered on other forums.
FreeBSD jails are supported by HashiCorp's Nomad [1], and their Consul + Vault are in FreeBSD ports
The tool mentioned in the article, Bastille, would be used to install popular software into jails.
Also ansible works well for pushing software into FreeBSD. There is even an ansible role for nginx that works with FreeBSD that's maintained by nginx team.
FreeBSD jails do not insist to have 'one service per jail', shell access is fine too. A jail is pretty well functioning 'compartment' within an OS.
Jails work very well with ZFS, one elegant feature, is that one can create a 'base jail', create a zfs snapshot with it, and then copy it over (using zfs) to any new jail created. Sort of like a base template. [2] This makes spawning new jails with base software install rather quick.
I do not know if FreeBSD has some interesting Linux features like io uring.
On the other hand, Netflix is achieving an impressive 200 Gb/s serving video traffic [3] using FreeBSD
- - - Just wanted to mention, that OpenBSD is different than FreeBSD, different kernel, many different user space programs, different team, different primary goals, different hypervisors that they have built-in, etc.
Same statement for Dragonfly BSD, same for NetBSD.
With regards to issue with OpenBSD 'on a laptop once'
I am using 5G wifi running OpenBSD 6.6 on a laptop, not using USB adapter. The driver I am using is iwn0. Works great. Perhaps we have different laptops...
[1] https://nomadproject.io/docs/drivers/external/jail-task-driv...
[2] https://www.cyberciti.biz/faq/how-to-configure-a-freebsd-jai...
[3] https://people.freebsd.org/~gallatin/talks/euro2019.pdf

I wonder if FreeBSD Jails never really caught on that much because of the name.

I'm not sure about that. Outside of tech, nobody cares what the technology is called. Inside... we've been happily freezing process groups, killing frozen children, and reaping the dead ones. Objecting to jails would be silly at this point.

What’s your laptop?

hp EliteBook 2560p. 12gb ram, 120 gb ssd.

The FreeBSD answer to Docker is to not use it. Just go back to the old way of running services on bare metal or VMs. It's not a bad idea, but other people who worship refinement and perfection will get mad at you for it.

Given as jails started with FreeBSD, no, I would say that running services on the bare metal is not the FreeBSD answer.

If you use the built in tools, FreeBSD leans towards telling you to just install ports/pkgs and then start them jailless. Your machine becomes a pet experiment in short order.
I also find it weird that each jail has its own copy of all of userland. It's a lot easier to use macOS sandboxing, certainly it saves more disk space. And I feel like I'll forget to update them.

Yep. I’m not sure I agree about user land but jailing everything is definitely not the default. It’s there if you want it and know what you’re doing, though.

"I would be totally on board with using FreeBSD as my primary server OS .. if it had a container engine."
FreeBSD is the original container engine - although, for the sake of completeness, we should count Solaris "zones" and call it a tie ...
I think there is a cultural and temporal connotation of Docker - and the use-cases that it typically enabled - that makes it seem very different than 'jail' but make no mistake: jail did all of those things and more, many years earlier.
The VPS, as we currently think of it, was built first[1] on top of FreeBSD and jail.
[1] JohnCompanies announced beta availability of "server instances" on 303 and cDc mailing lists in mid 2001. Someone else coined the term "VPS" a bit later ...

Being first doesn’t matter. Docker became the industry standard and jails did not.

According to Wikipedia, FreeBSD jails were available in a release version in 2000. Linux had Virtuozzo in 2001, explicitly for the use case we would call VPS today. Solaris didn't have zones until 2005.

It's mainly that the Docker interface is easier to use, in fact I don't know of any Jails frontend that comes close.
Also, at this point it would need to support the same image format and be very obviously better to see wide adoption.

Linux VServers came out around the same time (2001) [0], so the claim about "many years earlier" is spurious without being more specific about which things it did earlier.
[0] http://linux-vserver.org/Frequently_Asked_Questions#Is_this_...

Docker in 2020 is, for 95% of the use cases [1], nothing but a better packaging format than .tar.gz.
I'm sure you could throw away the isolation bits and it would still be as popular.
[1] Totally scientific figure, of course.

You might want to have a look at Bastille, a “system for automating deployment and management of containerized applications on FreeBSD”.
https://bastillebsd.org/

That's probably not what you are looking for, but FreeBSD has some container infrastructure around it. E.g., https://www.bsdstore.ru/en/about.html

These are hardly "reasons", more like "the list of comparable freebsd analogues of some common tech solutions implemented in gnu/linux".

Practical reasons to choose linux over freebsd
1. People use linux more than freebsd
Nothing's more important than this.

Sounds straight from a 90's Microsoft marketing department, I'm glad not everyone listened back then.
More users is definitely a feature though.

tbh microsoft was the best choice in the 90s.
the only reason linux became useful is because it became popular.

only for very particular, and peculiar, senses of 'best'

For some domains, But certainly not all, Windows was arguably a better choice, but even then it was more Windows NT vs Novell than Unix.
I don’t recall Microsoft ever getting much traction in the racks of ISPs or in “big iron” installations, not until the late 90s... and even then it was tenuous.
Microsoft was a terrible choice for IP networking, for example. Changing the IP address of a server would require a reboot.
The majority of the work I did in the 90s was on HPUX and DGUX, but also a bunch of others. There was a lot more OS diversity back in the day.

Might as well at not choose to do anything then. Just use whatever everyone else does.
We need people trying out better ideas even if they aren't as popular or easy.

Reply on news.ycombinator.com