Tutorial sites treating FreeBSD like a Linux distro
rubenerd.com
rubenerd.com
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.
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 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 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.
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.
When i'm troubleshooting something weird/infrequently used, and the explanation given in the handbook is inadequate, i usually turn to the Arch Wiki.
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).
like Mac OS X? :)
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.
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.
Though you could install powershell on Ubuntu if you wanted: https://docs.microsoft.com/en-us/powershell/scripting/instal...
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.
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?
Something GNU manages to screw up pretty well.
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?
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.)
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.
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).
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.
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.
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.
They hired Brendan Gregg [0] so I think they know what's going on.
[1]: https://lists.freebsd.org/pipermail/freebsd-stable/2012-June... [2]: https://www.linkedin.com/in/brendangregg/
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
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...
https://people.freebsd.org/~scottl/Netflix-BSDCan-20130515.p...
Seems GPL already ruled Linux 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.
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.
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.
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.
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.
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.
- 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.
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.
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.
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...
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.
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 second link is an opinion from some researcher at Pasteur institute in France.
Both are bogus, but thank you for playing.
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."
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.
Shipping containers are not secure.
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).
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.
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.
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.
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).
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...
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...
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.
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!
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 really noticed problems with that.
Bob: Look, ever heard of macOS?
Alice: yup, can't stand it
Bob: ...
1. Few people have strong working knowledge of BSD and linux kernel development. Kernel and distro development circles are fairly distinct, so even fewer will be able to speak to holistic comparisons from top-down and bottom-up views.
2. BSD development is regimented and conservative, resulting in relative predictability and lack of change over time. These things are commonly cited motivations for BSD adoption. We can assume people who desire this in their OS aren't doing a ton of gratuitous exploration on the side. So lack of knowledge about the state of the art in linux world on the part of BSD fans is probably to be expected.
3. Long-satisfied BSD users have exited the conversation. There are no grand, holy war-level stakes for BSD vs. other OSes anymore, so there's not a lot to stick around for.
4. BSD proponents tacitly reject worse-is-better in their arguments, but fail to explicate this or present compelling counter-narratives. This might seem like a small point, but it's tantamount to something like "I reject the tech equivalent of Whig history of the past 20+ years. Anyway, here's why you should switch to a new system. It actively works against advantages gained by your system under the assumptions of that historiographic model I've rejected."
5. BSD proponents spend countless hours overdeveloping criticisms of the most-disliked aspects of linux, like systemd. This is useless in any conversation with most prospective linux-to-bsd converts — preaching to the choir.
Example of 2 in action: "Technical reasons to choose FreeBSD over GNU/Linux"[2] is currently the best single-page case for FreeBSD easily found from obvious search queries. If you didn't know much about the last decade or so of linux development, it would be far more convincing. But as it stands, it's just met with a lot of confusion[3] on HN.
[1]: https://en.wikipedia.org/wiki/Narcissism_of_small_difference...
[2]: https://unixsheikh.com/articles/technical-reasons-to-choose-...