87 comments

[ 3.5 ms ] story [ 158 ms ] thread
Completely agree with this. I think the last 2 or 3 FreeBSD installs I did didn't actually use any tools other than the base system.

Then again we're a couple of years off "step 1: install powershell on your Ubuntu box" so the Linux guys don't get the last laugh.

Platform creep is nasty. Trying not to knacker my macOS desktop at the moment by installing brew on it and doing the same.

If you do work in the UNIX world, I’d say it’s pretty hard to use macOS without homebrew/Nix or at least Docker
How would it knacker the macOS desktop? I'm honestly curious, as I view brew as an indispensable tool on pretty much anything I do on a daily basis. I don't see it as replacing anything, but rather as supplementing macOS in so many aspects.
It’s more about keeping the machine clean. All systems “creep” and turn up a mess if you don’t maintain them well. So in this case of brew it brings a lot of stuff in that isn’t vendor supported. Which is backed up with time machine. If it ends up borked (which happened to me a couple of times) it’s a lot to unpick. Thus I prefer to avoid and use native tools to the platform.

All the native tools I need are available from the package manager on a Linux distribution which is far easier to reproduce therefore I prefer to do that there.

Also honestly I rather like the native BSD stuff. It’s very complete.

> Platform creep is nasty.

Why? Why not just consider the kernel, the rest of the OS core, the userland and the GUI completely distinct products?

GNU seems the best userland to the date (because BSD is more antique and Windows had rudimentary until recently). The new Windows userland (PowerShell and .Net Core) are growing awesome. Both are OS-independent, as well as BSD. Why even associate them with a particular OS? How choosing a userland differs from choosing a programming language?

Why? Because portability, standardisation, documentation and quality.

Something GNU manages to screw up pretty well.

Why not standardize and document every layer of the system separately? E.g. I prefer a userland as advanced as possible and a kernel to be lightweight and stable so I can choose GNU userland on BSD and I'm even looking forward to actually switch to PowerShell (on BSD or Linux). You favor long-term standardization and stability so you might prefer BSD userland on a Linux o whatever a kernel (which you can be forced to choose because of hardware or some other requirements).

You probably are ok with competing vendors offering alternative apps solving same tasks on the same OS. You hardly believe everybody should use the same OS-specific programming language. Why should there be the same kernel+userland combination for everyone?

I have used FreeBSD 12 as the main desktop OS for some time. In general, everything works fine (including NVIDIA drivers, Java, full screen video, sound, and KDE5 Plasma desktop). The only problem was that FreeBSD is not officially supported by Jetbrains for their IDEs (so I can’t report bugs), and there are e.g. problems with their Python and Javascript debuggers which I constantly use. So, sadly, I had to switch back to Linux. Other than that, it is an excellent modern OS with e.g. ZFS is fully supported as one of the default installation options (root on ZFS in Ubuntu is still experimental and barely usable).
This is the main reason why I haven't ditched linux as well. Most of my servers are BSD, but I use the Jetbrains IDEs extensively on my development machine and although most of them work okay on the BSDs, CLion is a complete mess on OpenBSD because a lot of the features use their custom Clangd.
I would gladly go back to using FreeBSD as a desktop OS if the software support was better. I'm not particularly skilled with either FreeBSD or Linux, but I never can seem to figure out what the hell is going on when Linux breaks, whereas with FreeBSD and NetBSD I've been able to deduce and even drop down and read the kernel source if I have to.
I recently began running it as the os on my laptop. Did not really follow any tutorial other than the handbook. I did end up installing Bash, probably more because that is what I am used to than anything else. I may go back and give tcsh another try, but I just remember it as there was small things that annoyed me.
FreeBSD is my go-to OS when I need a VM. I have poor sysadmin skills and I find it easier than Linux in general. I still use Xubuntu for my laptop, and Windows for my desktop.

For me, as a low level power user, I just find that searching "how to do something in FreeBSD" feels like always leads me to something easy to follow through and consistent. In Linux many times I find that tutorials don't apply to my version, or this distro has this files somewhere else and a long list of etc. It's fine, I get what's about Linux, It's just that I don't really have the motivation to learn all that quirks + the quirks of the stuff I'm trying to use.

FreeBSD community has always been nice to me too, everytime I needed to ask stuff.

So I just want to thank the FreeBSD devs and community because without them I wouldn't be doing a lot of stuff, or maybe just using Windows VMs.

Have you tried the arch wiki?
Will second this, Arch Linux is by far the most user-friendly distribution. It lacks a lot of the kludges and oddities that are especially common to Debian distributions, and the rolling release more often than not prevents you from needing to install a third party repository just to use the current stable release of a package. The documentation is actually helpful, and if you do have an actual novel problem, the community will be there for you (though, like any healthy community, it has defenses against lazy people who won't read the documentation).
This is so true and my experience completely checks out with it.

I started trying out Linux with the usual Ubuntu / Linux Mint distros, but I got so confused by the lack of structure and understanding of what is the correct way to do things - aka what I wanted to understand with Linux, for personal knowledge.

I moved to arch, and ease of use came free: everything you'll ever need is basically on the wiki, no weird PPA to add, nothing on sketchy tutorial sites - just the wiki. Definitely suggested for beginners (yeah the installation can be a pain but it's minimal compared to the advantages)

The Arch Linux wiki is useful even for other distros
The pacman rosetta is page I use the most.
I use Arch Linux and FreeBSD quite a lot and I agree that the Arch Wiki is great but it's not really comparable to the FreeBSD handbook.

The handbook feels... like a proper handbook. It's got structure and is very comprehensive. The first time I installed a non-Windows OS was FreeBSD as a teenager using only the handbook (I had no internet connection). In hindsight it was an amazing learning experience.

The Arch wiki is more like a compendium of arcane knowledge regarding Arch Linux and a lot of Linux software. It's a lot broader in scope but it can be a bit overwhelming when you don't know exactly what you're looking for.

Compare for instance the entry for OpenSSH in the handbook vs. the Arch wiki:

https://www.freebsd.org/doc/handbook/openssh.html

https://wiki.archlinux.org/index.php/OpenSSH

The FreeBSD page is a lot shorter but it's also more beginner friendly IMO. It ignores the more advanced features and niche use cases to get the user started. If you want to go deeper than that you're supposed to go look for the full documentations elsewhere (man pages, info pages or... the Arch Wiki for instance). It's short and focused. The Arch Wiki page on the other hand tackles many other advanced features of OpenSSH but I fear that a complete beginner might find it a bit overwhelming.

The Arch Wiki is priceless though, it's become my de-facto resource for projects that don't offer good quality first party documentation.

> I use Arch Linux and FreeBSD quite a lot and I agree that the Arch Wiki is great but it's not really comparable to the FreeBSD handbook.

I think it's a depth vs. breadth thing. The Arch Wiki covers significantly more topics, and a vast number of these topics are deep enough to solve your problem or get the job done.

I think the FreeBSD handbook often tries to be "complete" in some sense.

> Arch Linux is by far the most user-friendly distribution

I would put an * next to your statement.

It's more like a user-friendly model airplane kit. It might be overwhelming to a large majority of beginners who would start off better with an RTF model airplane.

As an example, very early in the installation guide you will be choosing EFI vs BIOS boot which you might be able to handle, but not everyone.

To be clear, Arch is my preferred distribution.

Arch is fine, I use it currently on one of my computers, but it can also be a lot of upkeep. Arch's wiki is great, but also different then BSD's documentation. Arch is more choose your adventure, where BSD is more cohesive. I wouldn't choose Arch for a server, in the same way I probably wouldn't choose BSD for a desktop. They both have their place though. I would argue in the past BSD's strong point would have been networking. If you dig far enough though, both Linux and BSD, have positive and negative points in regards to networking. Also even though BSD has jails, Kubernets has supplanted some of what you might of used jails for in the past. Jails are still very useful of course though.
Didn't try arch, Xubuntu is nice for my current laptop and didn't feel the need to dig a lot. It's in VM when I need to mess with stuff when I find it challenging.
For me if I need to start a random cli vm it's debian-minimal stable. Needs very little maintenance besides apt-get upgrade for a non-gui VM, not much special handling compared to other distros, just enough automatism to not need hand holding.

Nowaday my work laptop if also debian + xfce.

There are lots of other distros cooler or with better functionnality, and they're super cool for tinkering, learning and testing, but at the end of the day I want to install something that won't bother me and just let me work without caring (and won't have the cardinal sin of breaking whenever you do a significant update that you need for a software and have broken ripples everywhere), and debian does that: it's not "exciting", it's not "edgy", but it just works, and sometimes that's what you need.

I've heard freebsd can do that too but I admit it feels a bit daunting from a distance with no experience in it, and I have no idea how it fares on laptop (notably power usage and hardware support).

> I want to install something that won't bother me and just let me work without caring

like Mac OS X? :)

These days on my Mac, that's Ubuntu. Xcode and Homebrew upgrades regularly break things for me, and I've never had that issue on Linux. I also don't have to fight with Ubuntu to get it to do what I want like I did with macOS.
Way too opiniated for me
> What also gets lost in the fray is FreeBSD, even with all those Linux-focused tools, is still a compelling and useful operating system

Is FreeBSD compelling and useful at this point beyond as an inferior but more liberally licensed Linux substitute? This is basically what Sony (after their PS2 woes), Nintendo and Netflix (as far as I'm aware; maybe there are technical reasons too) have been using it for. The last clearly competent company I can remember picking FreeBSD for some technical benefits was WhatsApp many many years ago, and as far as I am aware that decision would not make sense today anymore.

Netflix folks repeatedly stated that in their benchmarks Linux simply couldn’t push data fast enough.
Could be, could also be they did not understand how to configure Linux, would like to see something more concrete to back such a claim up. Personally I'm skeptical that it is the case.
Even if that’s true then it remains a failing of the Linux ecosystem that they were unable to understand how to configure it correctly or that the defaults did not work as well as the FreeBSD ones.

But I don’t think it’s the case as they’ve put a lot of work into hiring some of the brightest minds in OS development, including Brendan Gregg

http://www.brendangregg.com/

> Even if that’s true then it remains a failing of the Linux ecosystem that they were unable to understand how to configure it correctly or that the defaults did not work as well as the FreeBSD ones.

Or alternatively they just did not put the time in. No defaults cover all use cases, almost all software I have ever used in high load applications needed some tuning, this includes Solaris, MySQL and MongoDB among others.

> But I don’t think it’s the case as they’ve put a lot of work into hiring some of the brightest minds in OS development, including Brendan Gregg

AFAIK Netflix has used FreeBSD since 2012[1] and Brendan Gregg only started working at FreeBSD in 2014[2]. So not sure this really shows they knew what they were doing when they made the choice to go with FreeBSD. It could be they did but I still would like to something more than just Netflix's choice to back the claim up. Many more companies choose Linux.

[1]: https://lists.freebsd.org/pipermail/freebsd-stable/2012-June...

[2]: https://www.linkedin.com/in/brendangregg/

I think that the engineers at Netflix "could figure it out".

As a long time BSD fan (since 1998) who has had to accept the fact that Linux won out in the end, I can vouch that by far the biggest pain point on Linux is its networking stack. Whenever I have to do anything other than set an IP address I throw up in my mouth a little bit. Linux has/had its benefits (packaging, install base), but IPTables or its routing configuration isn't one of them. High performance is certainly achievable, but it has a lot of quirks.

BSD's networking stack has always been more robust. Anybody who's worked heavily with both will tell you that. It did not surprise me one bit that the primary reason they chose FreeBSD over Linux for their CDN was networking. Juniper came to the same conclusion, on top of licensing reasons.

> I think that the engineers at Netflix "could figure it out".

And I would still like to see some evidence.

> Whenever I have to do anything other than set an IP address I throw up in my mouth a little bit.

Very compelling case you make there.

> And I would still like to see some evidence.

There are plenty of talks, papers, etc from both Juniper, Netflix, etc on why they made their choices, but your response is merely "could also be they did not understand how to configure Linux" without any evidence. We're not going to do your googling for you.

> Very compelling case you make there.

https://www.dictionary.com/browse/hyperbole

> There are plenty of talks, papers, etc from both Juniper, Netflix, etc on why they made their choices, but your response is merely "could also be they did not understand how to configure Linux" without any evidence.

Here are the only sources I could find that gave some reasons for Netflix's choice:

- https://people.freebsd.org/~scottl/Netflix-BSDCan-20130515.p...

- https://youtu.be/KP_bKvXkoC4?t=732

Neither of them suggest FreeBSD was faster than Linux in their tests.

From both of those sources I would say avoiding GPL was the primary consideration.

If there is something to back your claim up, link to it. If you cannot link to it then how the heck do you expect me to find it. I'm not the person claiming it exists.

In the presentation they literally list the TCP stack as a technical advantage. In the video the guy literally says kqueue and sendfile as superior freebsd code for their use case.

Also, I never said it's "faster". Most modern OS's on modern hardware can saturate most networking links. I said robust. There's a difference in how much CPU will be uses as well has how stable and consistent it can be.

I'm also not claiming FreeBSD is a magical solution to everything. I've long switched to Linux for various practical reasons, but there are some areas it still shines.

> In the presentation they literally list the TCP stack as a technical advantage.

At the timestamp I shared up to the next slide no comparison is made between Linux and FreeBSD.

And the thread we were in is about someone claiming the reasons why Netflix chose FreeBSD was performance and not licensing. In fact, here is a direct debunk of that claim:

https://youtu.be/vcyQBup-Gto?t=2739

Jonathan Looney, Engineering Manager at Netflix, claiming their primary reason for choosing FreeBSD was GPL avoidance and that subsequent performance testing (which was not the basis for their choice) is not exactly fair because they did not do the same amount of engineering work for Linux as they did for FreeBSD.

> I said robust.

And I said "And I would still like to see some evidence."

... that is more robust than your anecdotal reports of nausea, which I'm not sure really I can translate meaningfully to a measure of robustness.

To which you suggested I should do your work for you like I'm your slave or something. If you can't back claims you make, don't make them, simple.

(comment deleted)
The telecommunications company I am currently employed for uses FreeBSD for the backhaul applied with CG-NAT. And this is for the simple reason that the Linux stack couldn't keep up with the load.
If FreeBSD performed better out of the box without needing as much or no tuning at all, then it's the better tool for the job, specifically their job.
Maybe, still no evidence to back the speculation up.
They have both Linux and FreeBSD, yet FreeBSD is the one they still use for streaming. A Linux-biased and centric shop like Netflix would ditch FreeBSD the first chance they had if it weren't better at it than Linux.
Both of these things suggest they had many other reasons to chose FreeBSD, and neither suggests FreeBSD was faster than Linux:

- https://people.freebsd.org/~scottl/Netflix-BSDCan-20130515.p...

- https://youtu.be/KP_bKvXkoC4?t=732

Seems GPL was a problem for them.

EDIT: another source suggesting GPL avoidance was the primary reason for choosing FreeBSD over Linux: https://youtu.be/vcyQBup-Gto?t=2731 - and the presenter also says that the performance comparisons they have done between Linux and FreeBSD is not exactly fair because they did not do all the engineering work on Linux that they did on FreeBSD.

https://youtu.be/vcyQBup-Gto?t=2739

Jonathan Looney, Engineering Manager at Netflix, claiming their primary reason for choosing FreeBSD was GPL avoidance and that subsequent performance testing (which was not the basis for their choice) is not exactly fair because they did not do the same amount of engineering work for Linux as they did for FreeBSD.

Then they shouldn't be going through the kernel at all. FreeBSD will still be slower than accessing the NIC directly via DPDK.
I used freebsd for my last project, I can’t deny that support for BSD is spotty on cloud providers; but as far as performance and so forth it’s not far behind if at all.

The compelling argument for FreeBSD has always been: zfs, pf and dtrace.

There’s also kqueues which are a much better interface to high throughput I/O than epoll.

The problem is that every time this kind of question is asked the ecosystem in Linux is different. Right now Linux has bpftrace, ZFS (kinda) and IO_Uring; so the gap has closed considerably.

It's historically been a very similar proposition to Solaris: zfs, dtrace, containers, and higher performance.

For as much as I like both FreeBSD and Solaris, Brendan Gregg (mentioned elsewhere in the comments) has a very convincing argument as to why the scales have tipped in favor of Linux in the last few years:

http://www.brendangregg.com/blog/2017-09-05/solaris-to-linux...

ZFS integration was worse in Solaris 10 than in FreeBSD. In Solaris the page cache and ARC was not properly integrated and when using mmap data would be cached twice in both page cache and arc cache and there was weird issues with these contending with each other. I think this was still the case in Solaris 11 also but hard to say since it is closed source and their marketing material was fraudulent. As for the higher performance, I would like to see evidence that Solaris has better performance than Linux.

The one saving grace of Solaris was that it gave you amazing debugging capabilities but the practical outcome of that was just giving you the ability to gain deep insight to see see exactly how bad Solaris was as an operating system. In all my years of using it (10+) I never experienced it as being more performant than Linux and in most cases it was way slower if you did not tune it significantly.

There were some very good ideas that went into Solaris but they were almost invariably poorly implemented.

Solaris regularly beats Linux in performance on the same hardware, and the subsystems which are "slower" aren't really: they just don't lie and trade safety for performance, like Linux does. Linux is fake performance at the cost of correctness of operation.
I would like to see some evidence to back this claim.
The burden of proof is on you, since you're the one clearly advocating for Linux here.
> The burden of proof is on you, since you're the one clearly advocating for Linux here.

Ehh... if you want proof for a specific claim then ask for it. I am asking you for proof of the specific positive claim you made, which is:

> Solaris regularly beats Linux in performance on the same hardware, and the subsystems which are "slower" aren't really: they just don't lie and trade safety for performance, like Linux does. Linux is fake performance at the cost of correctness of operation.

The claims I did make is that in my experience Solaris had to be tuned to be reasonably performant. One example where tuning was needed by default was malloc. The default malloc from Solaris had horrible multi threaded performance . IIRC ZFS also had quite horrible performance by default if not tuned and I recall there were multiple tuning we had to do on new installations specifically relating to mmap to somewhat mitigate the poor integration of ZFS ARC cache and page cache which are documented here: https://github.com/openzfs/zfs/issues/225 and https://lists.freebsd.org/pipermail/freebsd-hackers/2016-Jul... there was also a whole wiki on ZFS tuning for various applications including MySQL.

The Github issue is for (then) ZFS on Linux, not ZFS on Solaris: whoever can read is at a distinct advantage.

The second link is an opinion from some researcher at Pasteur institute in France.

Both are bogus, but thank you for playing.

(comment deleted)
Solaris hasn't beaten Linux in performance in the past 5 years in anything.

As a matter of fact, you can't point to a single source that proves your point.

"That which is purported without evidence can be disregarded without evidence."

Brendan's "convincing" argument can be summed up as "Linux is better in all areas" and listing some relatively new technologies like BPF but which are horrid to program much less understand, and he lists no technical details. Whatever short-circuit suddenly happened in his head, he can be treated as a hostile witness for all intents and purposes. Him and I had a long one on one discussion and I'm not in the least convinced by his "arguments".
> The compelling argument for FreeBSD has always been: zfs, pf and dtrace.

You forgot to mention the "completeness" of the base system. Where Linux distributions is a "mix and match" of various tools/versions, that may or may not be the same across each of them.

FreeBSD provides a solid base that "just works". There's just one version (per release).

Jails is also another great feature. Linux has cgroups and namespaces, with various tools built on top of it like Docker, LXC and LXD, but (IMO) Jails still beat them in a heartbeat by security and ease of use.

Docker has had more severe vulnerabilities in a single year (2018 IIRC) than Jails has had in it's entire lifetime.

I never saw docker as being built for security, I think it's a common concept that's attributed to them because "contain(ers)" sounds like it contains things, the reality is that they're talking about shipping containers pretty exclusively in the context of docker.

Shipping containers are not secure.

But the content of shipping container #1 does not spill into shipping container #2. If it does, there's a problem.

Similarly with software containers, you don't want data flowing into nearby containers (unless you do want that, in which case you have setup the necessary networking and that should be the only way for the containers in question to share data).

I'm mostly interested in docker et al for the isolation aspect. The "ships the app with all its dependencies" is an interesting byproduct, although all too often it translates it means there's a mess in the amount of dependencies required. And that it's going to be an equal mess come update time -- unless of course the image is never updated in which case there's a chance the image becomes vulnerable (for example, outdated libssl).

> I'm mostly interested in docker et al for the isolation aspect. The "ships the app with all its dependencies" is an interesting byproduct

And that's why i use Jails instead (or LXC if you're on Linux). None of the layers. Any vulnerability is in the "base" image, and easily spotted, and can be hotfixed using normal package tools.

Docker is a mess. Most containers consist of minimum 4 "base images", each of which can contain vulnerabilities. All done to save the "overhead" of installing Python on top of a base Debian image, or whatever your flavor of poison is.

Instead i use Ansible for reproducibility, and scripts for updating/upgrading.

Another advantage to jails is that they're just plain directories in a hosts filesystem, allowing existing vulnerability scanners to scan the entire stack from a single host, instead of using containers that needs to be scanned individually.

> There’s also kqueues which are a much better interface to high throughput I/O than epoll.

Can you clarify why you say this?

One area where kqueue will be more performance is in that it supports multiple updates on interest set in one operation, while epoll does not, which means that doing multiple updates to an interest set will likely be less performant with epoll, however high throughput I/O does not translate to high frequency of updates to an interest set.

I never mentioned performance, I'm suggesting that kqueue is a better 'interface'.

epoll is an interface designed by someone who didn't know what they were doing at the time, that's the only way it can be described.. if you look at alternative implementations (such as IO-Completion ports on Windows) then you can see there's a lot to be desired, one of the things epoll doesn't do, for instance is tell you how many bytes are waiting on a buffer; so you have to read the whole buffer and determine if you're beginning a new unrelated message or not.

There's also the fact that epoll will evict things from the buffer on read; so you can't do a partial read and come back. It's just.. bad. io_uring solves a lot of these issues.

For someone who has good grounding in FreeBSD and the above technologies already, I can see how that decision would make sense (if you know dtrace well, you probably invested several man weeks into it -- why throw that away?). Typically the situation will be the reverse however (almost anyone you can hire at any level will know more Linux than FreeBSD) and the technological benefits you list do not seem like they would make up for that.

ZFS: these days it's developed on and for linux first and foremost, as far as I can tell (FreeBSD moved to ZFS on linux, correct?).

Dtrace: linux finally caught up and basically went one better with perf/ebpf.

kqueues: as you said, io_uring looks like it will take care of that (and probably put linux ahead).

pf: I can see how pf is compelling if what you want is first and foremost some firewall box, and you take whatever OS comes with the firewall (I haven't used pf, but most people seem to agree its significantly nicer than iptables et al).

iptables has been supplanted by nftables; though it's not as highly scalable as pf and uses a lot of iptables terminology.

I begrudge the notion though, that desiring something like pf is because you primarily want a firewall box; the syntax is much cleaner and ultimately the performance is better (without bolt-ons like conntrack).

For example these are basic firewalls with rate limiting

pf: https://git.drk.sc/darkscience/ds-salt/-/blob/master/states/...

iptables: https://git.drk.sc/darkscience/ds-salt/-/blob/master/states/...

here's what we have for nft: https://git.drk.sc/darkscience/playbooks/-/blob/a09507e2a9b6...

I'm not saying you wouldn't desire something like pf when using linux. Of course you would. But in the grand scheme of things, I don't see many people choosing FreeBSD over Linux for pf unless they want a firewall box.
io_uring is a lot more complex than kqueue though.
This is an example where distinguishing Linux from GNU/Linux is useful.

Yes, you can install GNU userland on FreeBSD, then you have GNU/FreeBSD. Maybe people want that instead of Linux (the kernel). There is also Gentoo and Debian on BSD kernels.

I really miss BSD (I'm a Slacker so at least I get to be nostalgic about it, even if Slack and Linux in general is annoyingly "modern").

I would like to use it again, but I'm a afraid I'd miss out on the latest developments that happen only in Linux-land (I'm still pissed that containers are such a Linux-centric piece of tech when they in no way need to be).

I really need to get back to https://github.com/NixOS/nixpkgs/pull/82131 so we can build on Linux or BSD, for Linux or BSD, in all 4 combinations. Eventually I want equivalent, NixOS userland, choose kernel on boot.

Nevermind the merits of Linux vs BSD, what we really need is kernel diversity to fight the stagnation of these multi-million-line tarpits of complexity.

Worth noting here that WSL has some special cursed package installer problems that can often be worked around with nix-based installs.
There are suprisingly few beginner tutorials for FreeBSD (or any BSD). Compare that with the gazillion tutorials for Linux. The official FreeBSD Handbook is rightly praised for it's thoroughness and its detail. But it is also a bit intimidating and dense for beginners who may need a simpler guided tour of the essentials.

Of course, there is a lot of cross-over knowledge between Linux and BSD. Nevertheless, the difference between the number of Linux guides, books, and courses and the number for BSD is striking.

There is just one book on FreeBSD published in 2018 (Absolute FreeBSD). But nothing else recently. What about BSD on Udemy, Pluralsight, LinkedIn Learning (Lynda)? Nothing. Why is there so little for an OS that is well-regarded and widely respected? (Not a criticism of the situation, merely an observation.)

Most computer users of the first world are barely even peripherally aware of the existence of linux. Within FOSS, BSD holds more weight as a software license than as an OS family at this point. Try searching BSD just about anywhere, including here[1]. And the most significant BSD-as-in-OS features are, invariably, whichever ones apple ends up sniping for macOS.

So: hardly anyone knows what BSD is, and nearly all of those who have used a BSD-like have done so in the form of macOS. It takes a certain kind of preening arrogance, mixed with total detachment from reality, to stamp and shout over distro confusion between linux and FreeBSD. It should go without saying that proponents of the latter have good reason to be grateful for any reason that new outsiders might even remember it exists.

I mean, the biggest in-joke the BSDs have is a ritual negging of bad news about BSD market share ("Is *BSD dying?"[2]). This is in line with a general level of sneery, navelgazing nonsense pervading much of the BSDverse that makes it altogether unpleasant to engage.

It's an OS, not Hilbert's Program. I'll use it if it fits my use case. I won't if it doesn't. I don't have the spare lifespan necessary to listen to BSD people whine about linux. Whatever gatekeeping needs to happen to make that stop, have at it.

[1]: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

[2]: https://www.google.com/search?q=bsd+dying

So: hardly anyone knows what BSD is, and nearly all of those who have used a BSD-like have done so in the form of macOS.

A giant saltation from most first world computer users being aware of Linux, to hardly anyone knowing what BSD is.

I recall the original netcraft survey being posted on Slashdot aeons ago; the joke to me always seemed to be a good-hearted chuckle at their own obscurity, much like the late Abe Vigoda spent the last 30 years of his life and career reminding people that he was still alive, even working!

Schade's few paragraphs here come across as equally gentle and humorous-he's not really aggrieved that FreeBSD is treated like a Linux distro; he would like avoid the confusion that might cause to users who end up liking it.

What, exactly, BSD users ever did to you remains a mystery; alas, I haven't the spare lifespan to want to figure that out.

> A giant saltation from most first world computer users being aware of Linux, to hardly anyone knowing what BSD is.

You seem to have misread my first sentence.

> Schade's few paragraphs here come across as equally gentle and humorous-he's not really aggrieved that FreeBSD is treated like a Linux distro; he would like avoid the confusion that might cause to users who end up liking it.

My commentary was in agreement with the blogpost.

Me:

>> It should go without saying that proponents of the latter have good reason to be grateful for any reason that new outsiders might even remember it exists.

But it doesn't go without saying, thus the need for Schade's blogpost. The elitism and intra nix resentment of BSD culture give rise to this problem. My comment aimed to address that.

> What, exactly, BSD users ever did to you remains a mystery;

They did nothing in particular to me. It's just a descriptive consensus that BSD culture has outsized hostility toward all things linux and toward being mistaken for linux. It's narcissism of small differences[1] and nerd blindness in action.

> alas, I haven't the spare lifespan to want to figure that out.

My comment contained a stringent critique of a community's corrosive norms, emphasizing how counterproductive those norms are for getting on with building useful things.

Your comment just aims to repackage the phrasing as a personal attack.

If you have time to work 'saltation' into a sentence, you have time to reply in good faith on HN. Flubbing a quip by trying to spit your interlocutor's words back at them in a sideswipe is not the way to go about that, especially when you've misunderstood the upthrust of the comment to which you're replying.

I'm perfectly willing to explain my position, so you achieve nothing by this odd posturing. [I even made a point to get around to it when I realized I was near the reply expiration time.]

I'll explain my position now:

    1. BSD community hostility toward linux: unreasonable
    2. BSD community hostility toward being mistaken for linux: unreasonable
    3. BSD community illusion of transparency: also unreasonable!
Some basic reasoning about the distribution of computer skills and world knowledge shows that two hostilities I mentioned above, especially the latter — hostility toward being mistaken for linux — are empirically unreasonable.

90% of computer users couldn't find text in a document as of 2011. There haven't been precipitous shifts in digital skills research results since then. Linux dominates server market share, but is only a blip in desktop market share. BSD doesn't even register.

It follows from any realistic assessment of computer users as a demographic that expecting a nontrivial proportion of people to know what the hell BSD is, let alone understand how it differs from linux in anything beyond branding, is indefensible.

Getting huffy about the matter on top of that, rather than opportunistically using that distinction-without-a-difference perception among novices as the submission suggests, requires a reality distortion field of monumental proportions.

Even within *nix, there's this intermittent HN/forum nonsense time and again that always goes the same way:

    [BSD DISCOURSE ENTERS THE AETHER SOMEHOW]
    
    Alice, linux user: What's BSD about? What does it do?
    Bob, BSD user:     It's like linux, but better ;)
    Alice:             Oh? What makes it better?
    Bob:               <list of things that linux does too>
    Alice:             But linux has <equivalents of the BSD things>
    Bob:               Better license?
    Alice:             I don't really care about that
    Bob:               No bloat! Also, it's an OS, not just a kernel.
    Alice:             what
    Bob:               No breaking changes! Your old scripts will still work.
    Alice:             I've never rea...
> Invariably they advise updating the base system and pkgng, then immediately installing bash, nano, htop, lsof, coreutils, proc, and more.

Isn't this what was commonly done on proprietary Unix, even before Linux existed? From what I have read about that era (I started with Linux so I didn't live through these times), the GNU tools were better than what came with these Unix systems. The authors of these guides probably have a similar opinion about the BSD tools.

In my opinion, the BSD userland is much nicer than GNU: the documentation is better, no long name arguments, and simpler. Browsing the source is also good fun, the implementations are straightforward and look like how I imagine K&R would write code. This is in contrast to the GNU userland, which is just so crazy.

It's evident that the GNU people don't really like C and refuse to accept the language's simplicity, instead struggling all the way.

Maybe I'm weird, but I like using systems in which I can feel good about the code, even if I never contribute a patch. And though I use Arch Linux instead of OpenBSD nowadays, I don't feel good about really anything to do with Linux. The ecosystem is gross and has turned into Frankenstein's monster.