It seems like most of the discussion on HN is meta-discussion about FreeBSD in general, rather than this particular cheatsheet. I like FreeBSD, but I wouldn't really recommend this particular cheatsheet. Why? Some examples from the top (and if the top of the cheatsheet is problematic, it's not a useful quick reference IMO):
1. mount_msdosfs: The 'ad' name is largely historical; you'll see 'ada' and 'da' these days (the latter for USB drives)[1].
2. ISO9660 is also basically historical at this point; UDF is more likely. And it's useful to split out mdconfig (memory disk config) as its own command -- it's useful in a lot of contexts, and separating it might make that more obvious to someone reading.
3. Linux procfs and Linux procfs? This is confusing and doesn't help users looking to run Linux programs (a lot more work is needed; see [2]). Creating /proc because it doesn't exist is odd; the directory should exist in FreeBSD installations and images, regardless of whether procfs is mounted[3].
Get what you will from the document; if it helps you, great.
People will use the best resources available, regardless of their faults. If you don't want people to use this resource, it's best to provide an alternative.
FreeBSD has bHyve which when using bHyve in production is a bit of a chunky cog; however when it's turning, it turns.
One of my servers just scored over 400 days uptime, hosting: Windows with a mixed various other *nix distributions adding failing RAM to the mix, I am astonished that I've had no issues.
If you use the latest release it's no-longer experimental to having a jail with it's own network adapter. In theory this allows you to then host multiple bHyve instances; in that if a user somehow breaks out of their Virtual Machine they are stuck to the jail rather then the Host-OS.
With such of a feature you can then lock clients in separate jails of their own, alone from any other client.
Hope FBSD makes a comeback in mainstream computing. Used FreeBSD 4 for a mail server with sendmail until early 2000s with vinum RAID and afs distributed FS. Such an orderly, unconfused O/S.
Well the Sony Playstation 4 based it's OS upon FreeBSD9 and they still update that today (3 days ago last checked). Unsure upon what the PS5 runs for certain, but can be sure that FBSD will live on and amazing how much from that codebase that people use.
So whilst Linux for many put BSD's to distant past memories, the amount of code from it that is used in other projects/products down the line is larger than many realise and can imagine that more people run lines of code with FreeBSD origins today than early 2000's.
There are still some companies using FreeBSD. At Netflix, we serve a large percentage of the internet's traffic using our Open Connect CDN, which runs FreeBSD-current.
WRT to the C10K problem mentioned below... We find FreeBSD scales quite well to at least several hundred thousand connections. Our largest experimental machines can serve nearly 400Gb/s of real customer traffic across hundreds of thousands of TCP conns from a single-socket AMD Rome. This is all with a "traditional" kernel-based workflow, serving media files with sendfile, and doing encryption of HTTPS traffic via kTLS (with NIC-based hardware TLS offload in this case). There is no DPDK or other userspace networking or storage.
They've used some code originating from BSD, but as far as I've read their actual operating systems have had a proprietary "embedded RTOS"-ish architecture rather than being based on (or even loosely resembling) any Unix lineage.
I doubt we'll even know for sure, but there is a FreeBSD kernel license in the Switch's copyright notices[1] though Wikipedia does paint a very different picture[2]
According to the primary author of the Atmosphère custom firmware (which now contains an open-source clone of the Switch kernel), the "FreeBSD Kernel" copyright notice is only there because Nintendo used FreeBSD's sys/tree.h, with the actual kernel bearing no resemblance to FreeBSD [1].
Probably. A few long standing FreeBSD developers hinted at helping out when Sony ran into problems e.g. their own file system failed and they required help tuning FFS to make the most out of their blazing fast SSD.
I'd like that as well, but my suspicion is that Linux is now "good enough" via things like io_uring that a highly visible comeback for *BSD is less likely.
The draw for BSD is the BSD license - it is not a "copyleft" license, you do not have to redistribute source to those whom you provide with binaries. Same reason Intel chose MINIX over Linux for the Intel Management Engine.
As such, Linux will never fully substitute for the use-cases that BSD provides.
More or less - BSD focuses on developer freedoms while GPL focuses on end-user freedoms. GPL does not provide you the ability to redistribute binaries without source, while BSD does, so BSD is desirable where obscurity is an element of depth in defense (eg Sony's playstation OSs, Intel ME, etc), or where you simply don't want to redistribute your derivative code (MacOS X, etc). GPL also does not allow you to link GPL-incompatible code (either proprietary or non-compatible open-source licenses) that you don't own and can't relicense to GPL compatible, as that inherently locks off a significant amount of code that you might potentially need (what if you are licensing an audio decoder from a well-known German standards institute?). It simply is much easier for developers to work with with BSD license, as it does not attempt to be "viral" like copyleft code. Here is the code, don't sue the authors, end of story.
Frankly it's somewhat impressive that GPL has done as well as it has, the necessity to only link with GPL-compatible code has become a pain point but the kernel project has enough clout to get people to license patches however the project wants (see: ZFS and the kernel devs trolling by relicensing files out from under them). GPL is actually an enormous pain from a licensing and corporate IP perspective and BSD avoids that.
For me, the draw of FreeBSD has always been that's it's one operating system. Linux, while small, is also fragmented. There is no "this is how to do X on Linux", as distributions are all different. So while there are strengths to having lots of distros, but there are also major downsides.
To be honest, Linux is also not highly visible, sure for the HN-Community it is. But for normal Customers? They know Android, Windows, MacOS..that's it.
Well... tell somebody you run a Unix operating system instead of Windows or Mac and keep notes on how many people say “Oh, you mean Linux?” Keep a smaller piece of paper for all the combined responses of “Oh, you mean [Open|Free|Net|Dragon Fly]BSD?” I’d be surprised if you need that second piece of paper at all.
Yes and no. The XNU kernel is, to oversimplify greatly, BSD glued into Mach. At least historically, it had BSD kernel code in it. And it continues to implement many BSD APIs.
macOS and FreeBSD user-land have some similarities (because some of macOS user-land is based on FreeBSD) such as ifconfig(8), route(8), and netstat(1) (only 1 of these 3 is mentioned). Knowing one makes using the other one (or *BSD in general) easier.
The BSD parts of the macOS userland are directly copied from an old version of FreeBSD (more or less). So it's less that they're similar, and more that they are direct copies (at a point in time — they've since diverged somewhat).
I've always found the FreeBSD docs and environment to be more coherent than most Linux distros. The manual is really good at covering things you want to do. With Linux, I feel like I'm looking at a random blog post more often.
That has not been my experience beyond fundamental aspects.
Even if a distro had fantastic documentation, the issue of fragmentation would still remain. You can't just find people who "know linux", but you need people who know this distro.
Then there's the issue of third party apps that may be packaged and tested for some distros and not others. The fragmentation is an issue in itself.
I'm switching to FreeBSD for my current project and most likely future ones. Been setting things up and migrating the last few days. In fact, I'll probably convert my Linux dev box to FreeBSD and run Linux in a VM.
Why the swtich? I'm really hoping that FreeBSD brings me some stability. I'm frustrated of learning how Ubuntu does things with every new named release. In a commercial environment, I'm aware and comfortable with the vast amount of infrastructure that's deployed to make our applications operable. One of my goals for FreeBSD is to come back to fundamentals and build my applications in an environment that I can understand and maintain without fully staffed teams.
Couple things I noticed. As a Linux user for many years, I am working my way through the FreeBSD Handbook docs. Most of the material I'm familiar with so it's a fast read but have on numerous occasions learned new information. Especially useful since I'm learning how FreeBSD does things. It's no diferent than learning a new programming language in a paradigm that one would considers themselves an expert in.
As a primarily app developer, rc(8) is just the right amount of abstraction and it makes sense. I get it intuitively. I really find it joyful when I encounter such designs.
I love how FreeBSD is organized. This must be attributed to it being designed by a cohesive team. Great job, I noticed and very quickly.
One downside so far, Google seems to answer _every_ linux / ubuntu question I throw at it or at least guides me close enough that I can sort my way through a problem. This hasn't been my experience with the FreeBSD system. Though I've tackled all my issues, it took more time. I should provide an update to this in the future since it could very well be because it's a new system.
I'll also miss cgroups. FreeBSD has rctl(8) and it looks like jails have resources parameters as well. cgroups are very well deigned for the problem that they're solving for me. It gives the right control over the right resources in a cohesive manner.
I'll end this with things that I'm excited for. I find learning new things does this to me so I'll share just for fun. I'm excited to learn jails and hope that I find it an improvement over Docker. I'm excited to deploy my erlang application and host my postgres database. I'm excited for root zfs. I'm excited to UPGRADE when the next version of FreeBSD comes out. This should work right? I _never_ upgrade my Ubuntu dev box. I'm excited that Wireguard is getting native kernel support in BSDs [https://www.phoronix.com/scan.php?page=news_item&px=WireGuar...]
Sometimes the Handbook is dangerously outdated with bad info too. It can be hit or miss. Manual pages are often updated, but do check the modification date for a clue — last updated in 1996? Maybe double check other sources.
One thing to watch out for is that FreeBSD ports/pkg is a "rolling release", where most 3rd party applications & libraries are updated frequently, as opposed to every 2 years for Ubuntu. The upshot is that you'll want to just update firefox, and it will want to remove and re-install 57 packages.
I personally run the quarterly packages to avoid the churn as much as I can. This is somewhat similar to Ubuntu, except "major" updates happen every 3 months.
To further clarify: "upgrade" downloads the new release, and you need two or three "install" commands after that (separated by reboots) to actually perform the upgrade.
1. mount_msdosfs: The 'ad' name is largely historical; you'll see 'ada' and 'da' these days (the latter for USB drives)[1].
2. ISO9660 is also basically historical at this point; UDF is more likely. And it's useful to split out mdconfig (memory disk config) as its own command -- it's useful in a lot of contexts, and separating it might make that more obvious to someone reading.
3. Linux procfs and Linux procfs? This is confusing and doesn't help users looking to run Linux programs (a lot more work is needed; see [2]). Creating /proc because it doesn't exist is odd; the directory should exist in FreeBSD installations and images, regardless of whether procfs is mounted[3].
Get what you will from the document; if it helps you, great.
[1]: https://lists.freebsd.org/pipermail/freebsd-questions/2016-S...
[2]: https://wiki.freebsd.org/LinuxJails , previously: https://news.ycombinator.com/item?id=24971456
[3]: https://github.com/freebsd/freebsd/blob/master/etc/mtree/BSD...