Vim is great and I have 25 years of muscle memory for it. But I'm also interested in trying Kakoune (https://kakoune.org/why-kakoune/why-kakoune.html) -- which I understand also has a VSCode plugin called Dance (https://github.com/71/dance) -- as I've seen somewhat convincing arguments that it is a more powerful model for modal editing.
Instead of "verb object" (eg. delete word or "dw"), it is "object verb" (eg. word delete, or "wd").
In particular, it seems to obsolete "visual mode" from vim (which I use often), because you're essentially always in visual mode. You always get to see a selection before you perform an action. Or at least that's what I understand, I haven't tried it yet.
I've been using kakoune for the past 2-3 years and it has been great. My main reason for switching from vim was the adherence to the Unix philosophy, but the editing model has been great. Seeing your selections change after each command + the clippy help text when entering a different "mode"^1 has made learning different editing patterns very easy. The only thing I really miss from vim is the number increment/decrement shortcut. There is a plugin for it, but I haven't tried it out yet (incrementing each selection by a different amount hasn't come up often enough for me).
I assume this is for hashing. I've seen several hashing algorithms turn to hardware AES instructions before, but I haven't seen any evidence that this technique outperforms state-of-the-art hashes like RapidHash (https://github.com/Nicoshev/rapidhash) in either quality or speed.
I often wonder what the current status is of the BSDs (FreeBSD, OpenBSD, NetBSD). Who uses them, who works on them, what is their motivation for doing so? How do they compare to Linux these days, in terms of size, feature set, security hardening, etc? Is their usage/development happening at a relatively constant level, or is it growing/shrinking?
I do think all the BSD, despite how niche it may seems are doing well and in an ongoing development stream. And at least they seem larger than Solaris / Illumos, despite some of the cool tech solaris branch has.
All your Netflix video streaming from Open Connect CDN Edge are served by FreeBSD. [1] Serving at 800Gbps per Server.[2] This was 4 years ago, drewg123 also hangs around on HN so I hope he read this and there are some 1.6Tbps update soon :).
NetBSD runs on everything. So it's part and sometimes NetBSD itself is running only vanity of embedded systems. A lot of these information are pre 2020. But given how slowly the embedded industry moves I wouldn't be surprised if it is still largely the same. I do wonder if it was grown though. It is also the only Rump kernel implementation that I know of.
OpenBSD ends up a lot on HN, many part of our every day internet usage are done with components maintained by them. There are a lot of network appliance and server usage using OpenBSD.
I think BSD deserves more credit, but for its license and philosophy I guess is it mostly working as intended.
I’m using OpenBSD as a daily desktop. The main motivation is that it’s a complete system instead of several projects. So you got simpler userland tools as the kernel interfaces can be easily adjusted.
Also the subsystems are way simpler (packet filtering, sound, network management). Linux is full choke of abstraction which aim to serve a huge range of devices. And I truly believe that there should have been a bifurcation somewhere.
Most software are easy to port around, but there are some that relies on linuxisms (udev) and some on glibc-isms, which can require some patching. Some of the pains I encountered are about device files (usb) and the fact that openbsd relies on root a bit more (mounting with fuse).
You can read the “Absolute OpenBSD, 2ed” book, published 13 years ago and almost everything still holds. You can even read the “Design and Implementation of the 4.4BSD” and still have a good understanding of the OpenBSD design. Linux is chaotic land compared to that.
One of NetBSD’s strengths and emphases is portability. They have a motto- “of course it runs NetBSD.” IIRC NetBSD was ported to Apple Silicon slightly before Asahi Linux succeeded.
Another cool corollary to this ethos is the portability of their portage, pkgsrc. I’ve personally used it as the basis of my user space packaging system on a Linux From Scratch distribution I made during the pandemic and the results were awesome. I could be wrong but it is the only package ecosystem I’m aware of that currently supports MacOS, Linux and the BSDS.
As far as the health of the ecosystem pkgsrc uses a rolling quarterly release process, has built in mechanisms for identifying vulnerable packages and a dedicated (volunteer?) security team and packages are about as up-to-date in many cases as, say, arch or gentoo.
Additionally pkgsrc can run rootless and my understanding is it finds itself used in a lot of high performance scientific computation settings as a result.
Ported to apple silicon before Asahi is definitely a stretch, single cpu core, storage "barely" working with several hacks, graphics simialrly.
Iirc they still required the Asahi folk to do a lot of the heavy lifting for device tree bindings, meaningfully functional bootloading, etc.
Even now the situation there is still rather dire even by bsd standards.
They for that reason also were very very early in the Xen game both host and guest. Back when it was essentially a research project, why before hardware virtualization was even on the roadmap for Intel.
I use obsd as a desktop system, I would not necessarily recommend this to anyone, you give up a lot, but obsd is my ultimate comfort system, it is small but full featured. I feel I understand the system far more than I ever did linux, which is one of the good guys. Compare to windows where despite using it my whole life I always feel I understand barely at all. But openbsd is so well put together I love using it, So I put up with the downsides and am quite happy with it as a desktop system.
Naturally I also use obsd as my firewall, a role I would recommend it in. at least if you don't mind a bit of old-school unix administration.
I have a freebsd fileserver and never got around to trying netbsd, But between fbsd and obsd I found I prefer obsd as the desktop system, it is a subtle thing hard to describe, but it feels better focused for desktop use than freebsd, not as performant and the filesystem sucks in comparison(thus the fileserver) but somehow feels better. I don't know.
For a firewall/router I use Ubuntu - it's what I use for everything else, so it's comfy.
I do believe OpenBSD is very very good software, but I do wonder if just given it's small install base if there are vulnerabilities simply nobody knows about. I guess may it doesn't matter since Linux is so much more widely deployed, perhaps that's just a better platform for hackers to spend their time.
OpenBSD exploits (defined as bugs in both OS and typically-deployed applications on top of it) are (or used to be) low-value but scarce and hence prestigious.
Linux exploits can be extremely valuable in monetary terms, but the attack surface is so absurdly vast these days, that they are seen as banal.
Absolutely. My daily driver on all my machines. My homelab started with FreeBSD on all machines with liberal use of jails. Now it is fully OpenBSD and only the file server is running FreeBSD now. All laptops are also OpenBSD, even the M2 Macbook Air
On desktop,I use a NFS home dir to a freebsd(zfs) fileserver. But I have to admit, that is not so much concern about the filesystem quality as I want a good(backed up, raid) storage system, and rather than trying to build good storage on all my system I just did it once (the fileserver) and use that as a home dir for almost everything. For instance. I have a laptop that only syncs intermittently to the main file server, but i have never had it fail due to unexpected shutdown.
As for actual usage, it largely depends on how hard the filesystem is used at the time of the sudden unexpected outage, A router will fsck, find a few superficial problems(mostly log file) and be done. A desktop with 50 tabs and applications open has a scary amount of fsck problems found(most of them in the web cache). Not saying it does not happen but I personally have not had a sudden unexpected power outage kill a filesystem.
And this is incidental(because it was removed) but obsd used to have a facility for it's filesystem called soft dependencies, which was supposed to work sort of like a reverse journal, where a journal writes twice(write what you intend to do, the journal, than make the changes to the filesystem, softdeps delayed writes until the changes could be written in order with every intermediate stage valid. It sounds like a good idea, but my understanding is, it was a very complicated system spanning several logical layers making it harder(scary) to work on filesystem code, too easy to mess something up far from where you are working. So it was removed. Also: softdep had some nasty fail states with a full busy filesystem.
I am working on my desktop or laptop, I get a power cut or the laptop battery run out, when I reboot the filesystem is unrecoverable and I loose 4 hours rebuilding the system and recovering from backup.
So it is not really about loosing recent files but the potential time lost (usually at the worst/busiest moment).
I suppose it's possible, but I have had dozens of power cuts and never been unable to recover or lost any important data. Perhaps I have lost some temporary files in a browser cache or something like that and just never noticed. Everything I really care about is backed up anyway, as it should be because robust file systems aside, physical failure of storage media is also a possibility on any system.
The fsck can be a bit annoying compared to rebooting with a journaled file system, but it has never failed to recover for me.
The "softdep" (soft updates) mount option was eliminated in release 7.4 and I cannot say whether that has made the file system more or less reliable but the stated reason it was removed was because it was poorly understood and complex code. "It is too clever for us to continue maintaining as it is."
Nowadays, the journalized filesystems of Linux, and also NTFS of Windows are quite mature and many of their early bugs have been fixed.
Many years ago that was not true.
In the early years after 2000, I have witnessed a great number of computer crashes caused by power failures.
All the HDDs using journalized filesystems were corrupted sooner or later, including NTFS, ext3, reiserfs, XFS.
The only filesystem that was completely unaffected by any power failure was UFS, on FreeBSD (obviously with "soft updates" enabled).
UFS with "soft updates", does not use a journal, but it carefully orders the data writes to the HDD/SSD, to ensure that any power failure will not cause corruption.
Unfortunately, it is said that modern programmers have difficulty to understand the old "soft updates" code, so it seems that it might have not been maintained well, so I do not know whether today it continues to work as well as 2 decades ago (though I have seen during the last year a few power failures that did not have any effect upon a FreeBSD-running computer using UFS with soft updates).
Moreover, even the best journaling filesystems or UFS with "soft updates" can be fooled by dishonest SSD/HDD firmware, which does not write the data when it reports it as written, so the only complete guarantee against power failures is to use a good UPS.
OpenBSD has removed the "soft updates" code from their UFS implementation a couple of years ago, apparently for the same maintenance problems caused by it being difficult to understand. Therefore OpenBSD should be used with an UPS (or on a laptop).
No filesystem, regardless of what kind of journaling is used, can guarantee anything else except that after a power failure you will get the same filesystem as it was a few minutes before the power failure.
If there was anything written to the HDD/SSD during those minutes, it would be lost.
For better guarantees than this you need special hardware, e.g. SSDs with big capacitors that can maintain the local power supply for a fraction of a second, during which the SSD controller can flush to non-volatile storage all buffered data.
> In the early years after 2000, I have witnessed a great number of computer crashes caused by power failures.
Don't enable write cache without a power backup, or on an unstable machine.
> Therefore OpenBSD should be used with an UPS (or on a laptop).
NVMe with PLP is suffice.
The same helps me on my NAS as well, with ZFS and Linux. No need for OpenBSD.
Soft updates was very cool when I first used it, like 25 years ago. Linux didn't have Ext3FS yet, or just about got it. ZFS also worked very early on FreeBSD, but nowadays the standard is OpenZFS.
There's a couple of cool things coming from OpenBSD camp, most notably OpenSSH and PF.
I've never lost data on OpenBSD+UFS, unlike Linux and ext4 or btrfs. I would rejoice if zfs or hammer2 or some other modern fs was ported, but it's no big deal to run on my laptop.
A long time since I've looked into LFS on NetBSD. At the time reading up on it, out of curiosity, wanting to try it out, I got the impression that it is very experimental, and nobody was really using it in production/as a daily driver. Something about the cleaner-demon crashing over and over again. So I noped out.
Has that changed meanwhile, or is that just one of the things that are still advertised as somehow supported, while in reality that happened in a galaxy a long time sideways, in some Jedi hideout?
> I often wonder what the current status is of the BSDs (FreeBSD, OpenBSD, NetBSD).
DragonFly BSD ([1], [2]): "Am I a joke to you? :-("
;-)
By the way: If you look for a BSD-based desktop OS, have a look at GhostBSD ([3], [4]) (based on FreeBSD) and/or MidnightBSD ([5], [6]) (forked from FreeBSD). Both are under active development.
- the most recent release was from March 16, 2008; 18 years ago
- the most recent preview was from January 17, 2016; 10 years ago
So, despite the fact that the MirOS website [2] has some small News updates from 2026, I would see the evidence on the side that MirBSD is dead, but I would love to be proven wrong on this point.
The old fallacies of WWW site changes equals software changes, and unchanged code equals non-existence, and Wikipedia being gospel for computing topics, rear their ugly heads again.
I follow the FediVerse robot that announces MirBSD CVS updates, which is quite active. The last major change, apart from some doco, was a fix to rdate at the end of May 2026, just 2 months ago. And even if MirOS BSD were unchanged for longer than that, it would very much still be around.
OpenBSD is the most security hardened OS out there, and the project maintains many pieces of software people take for granted, like pf, openssh, and libressl. FreeBSD is definitely the most robust, and is a very good server OS. NetBSDs niche is how many platforms can run it. If it's supported by GCC, theres a decent chance NetBSD will run on it
OpenBSD is the most security hardened OS out there,
I think this requires a lot of additional qualifications. For instance, AOSP and Android are much more hardened when it comes to isolation between GUI applications.
Among those qualifiers would also be 'free open source'. I'd think there are hardened operating systems which are not much, if at all, talked about in public. Perhaps, in the age of LLMs finding most security vulnerabilities, those are actually demonstrably more secure now than the well reviewed public ones.
... then there's Qubes OS, which beats the pants off AOSP isolation using Xen. Feels like the labelled desktop of the Trusted Solaris days! If one wanted to utilize SELinux in TemplateVMs for further hardening, that is always an option.
I use NetBSD on several systems as a small server platform. I find it easier to understand and customize, and it keeps a lot of this stuff out of the landfill.
A bit more niche but Slackware (both the 15.0 released version and 'current' development version) have x86 support (i686). Void Linux and antiX Linux also provide i686 isos.
I've mainly heard of successes of the networking stack in FreeBSD at Netflix and Whatsapp - but largely, I don't know anywhere else that uses it in production.
> Who uses them, who works on them, what is their motivation for doing so?
FreeBSD (and all the BSDs really) do not use systemd.
> How do they compare to Linux these days
They don't use systemd.
> How do they compare to Linux these days, in terms of size, feature set, security hardening, etc?
Security harderning? They don't have systemd. So there's no backdoor in SSH because somehow sshd is linked to some compression library because a Microsoft employee decided Linux should use compressed logs.
I recently switched my router from pfsense to OpenBSD. I wanted a “vanilla” OS as opposed to a specific router OS like Opnsense.
The setup on openbsd was very straightforward. I had to read up a bit and claude helped getting ipv6 and vlans up. Had I ignored ipv6 it would have been ready in half an hour from just reading man pages and official docs. The only reason ipv6 took longer is because I had no idea how it works.
I researched the equivalent setup on linux and it was much less straightforward. In openbsd I only used software in the base install. For linux there were a lot more choices to make, which for me just made setting it up more difficult. I don’t want to pick a firewall, I just want to configure the simplest possible one.
The only issue I had was the system hanging when no monitor was connected to the hdmi port. I use an old apollo lake mitac pd10ai itx board. Displayport worked fine during install but black screened before I got a shell and crashed. Tried setting some kernel options to disable some display driver without success. Opted to get a dummy hdmi plug instead for reboots without a monitor.
Running my firewall on nixos these days and honestly I havent felt the need to have to make many decisions. You dont have to pick a firewall on linux, nftables is standard pretty much everywhere. Most the software outside of that is the same you'd be using there, but dare I argue often far more optimized on the linux side of things. Drivers especially so.
Far easier to have declaratively configured and services all meaningfully isolated. Miss me with dozens of root scripts integrated in some web ui or updates that can break the system the moment you step outside their basic expected workflows.
I use stock OpenBSD with nothing else for a web server. Very easy to maintain and configure, very good manuals and very good vulnerability track record. OpenBSD 7.9 was released 1-2 months ago.
I know some people use OPNsense or pfSense for their router and firewall needs, which are both based on FreeBSD.
I've been using OpenBSD on my router/firewall boxes (in various forms, mostly i386/amd64 - Soekris or PC enginers but also mips/octeon - Ubiquiti boxes) for the past 20+ years. Mostly because in that area I do not want any compromises (literally and figuratively) on security. I like the Packet Firewall philosophy and functionality. The fact it is rock solid I take for granted. Another reason is that the system is cleanly designed and simple. Quite easy to reason about with source code in hand.
I meant more in the sense that it's less of a blocker if you wanted to use a different OS altogether. Many people are on Linux because it's the most well supported, but if you happen to be on BSD and you're missing something from Linux then you can theoretically just have AI port the thing.
I have been using in parallel both Linux and FreeBSD on my computers for around 3 decades, because each has advantages over the other in certain circumstances.
Until around 2004, I looked at Linux more like a toy in comparison with FreeBSD, because the latter had much better reliability and performance.
However, in the early years after 2000 Linux has evolved and it gained more and more advantages over FreeBSD, mainly caused by a much greater number of programmers that contributed to Linux.
The first that affected me personally was that gradually Linux added support for a much greater number of peripheral devices.
Unfortunately, after the launch of Windows 95 all vendors of PC peripheral devices have stopped providing technical documentation for their products, replacing that with Windows drivers (or in rare cases, e.g. for network interfaces, they might provide drivers for a few other operating systems).
This means that for non-Windows OSes someone has to reverse engineer the device drivers. In the better cases, there are some standardized peripheral interfaces, like USB, ATA, SCSI etc., but that is not good enough for using a given peripheral device, because most of these have always been full of undocumented bugs and they work on Windows only because the Windows device drivers contain workarounds for the undocumented bugs.
This means that the Linux kernel includes a huge database of quirks with the bugs of various peripheral devices that exist on the market.
Eventually the BSDs were also forced to include such bug databases, but theirs were and still are much smaller than those of Linux, because they have less users, so less people who might encounter the buggy devices, investigate the cause and report it.
For example, I had some Athlon CPUs that I used with motherboards bought in 2001, which had VIA chipsets. In 2000/2001, the VIA chipsets had a horrible bug that caused data corruption on hard disks. There was a workaround to serialize some of the ATA commands, to avoid their concurrent execution that resulted in data corruption. Of course, VIA kept secret the existence of the bug, so who knows how many people have lost precious data because of this.
When I first bought a motherboard with a variant of the buggy chipset, for a Pentium III CPU, by chance I discovered very early the data corruption on Windows, and I returned the MB. I bought another MB with the same chipset from another MB vendor (Soltek), and I blacklisted the first MB vendor (Soyo), after not seeing data corruption on the new MB.
I was very wrong because the MB vendor had no responsibility in this, only VIA was guilty. The bug disappeared on the second MB because meanwhile VIA had updated its Windows driver. So they caused lost sales to the first MB vendor, by their secrecy.
Sometime later, I decided for a MB with Athlon to be my first desktop PC that was not configured for dual-booting with Windows, so I wanted to install on it only a *BSD or Linux.
However, neither FreeBSD nor NetBSD nor OpenBSD worked on it, all had the data corruption problem. But Linux worked fine, so I installed Linux and since then I used only Linux for PCs, restricting FreeBSD for certain kinds of servers.
Only later I discovered the reason why Linux worked, unlike the BSDs, which was because it was aware of the bug existing in the VIA chips and it included the same workaround as the Windows drivers.
I believe that my experience was typical of the positive feedback loop that enhanced the market share of Linux, more users resulted in good support for more hardware devices, which enabled the adoption of Linux by more users, and so on.
Then the major blow that hit the BSDs was the launch of Pentium 4 with SMT in 2003, followed by the dual-core AMD CPUs in 2005.
On a single-thread CPU, FreeBSD 4.x had a much better performance than the contemporaneous Linux, for networking and storage operations.
But the design of the *BSD kernels was incompatible with multiple threads and the rewriting of the *BSD kernels to work with multi-core and/or multi-threaded CPUs took several years, while Linux had already been ported to SMP architectures and it took immediately advantage of the new fast CPUs.
During the first decade of this century Linux took a great leap in performance beyond the BSDs, and they never caught up completely with it after that.
Beyond the fact that it worked well with many threads, Linux introduced during those years many improvements over the traditional UNIX-derived features.
The most original was the use for synchronization of compare-and-wait-for-mutation, a.k.a. futex (2002), which was the correct solution for a problem discussed by Dijkstra 40 years earlier, but for which Dijkstra had proposed a wrong solution, i.e. semaphores, a solution that caused inefficient implementations of IPC for decades (Dijkstra had criticized the use of event flags for synchronization, because of a possible race condition, which was avoided by the commutativity of the increment/decrement operations on semaphores, but compare-and-wait avoids the race, without using superfluous auxiliary variables, like semaphores, but using only a variable that is already needed when implementing things like a message queue, a ticket lock, a CLH lock etc.).
Other Linux improvements of that time were epoll (2003) as a poor man's equivalent of FreeBSD's kqueue/kevent (2000), libaio for asynchronous storage I/O (FreeBSD had used since 2000 an extended version of the POSIX AIO, adding "aio_waitcomplete"; libaio is better than the standard POSIX AIO), timerfd (2008) for waitable timers (FreeBSD had EVFILT_TIMER since 2000) and various means for doing zero-copy I/O, like O_DIRECT (2001) from IRIX, sendfile64 (2001), splice (2006) and related syscalls.
Of the BSDs, FreeBSD has the largest installed base, so it also has more developers and for the architectures that it supports (which are less than those supported by NetBSD and OpenBSD) it normally has the best performance among BSDs, as more optimization effort has been directed to it.
Before 2019, I would have said that for a server environment there was approximate feature parity between FreeBSD and Linux. But then Linux was greatly improved by the addition of io_uring, which finally provides the right way to do asynchronous I/O on Linux, where before this every available method was inferior in some respects to methods available on other operating systems 50 or even 60 years ago.
Now io_uring allows the implementation of high-performance I/O on Linux with much lower overhead than on any other UNIX-derived OS. Like previously with "futex" => "WaitOnAddress", the Microsoft developers remained able to recognize a good thing when they see it, so now Windows has also added functions like CreateIoRing (ioringapi.h).
While since io_uring I would always choose Linux for developing a server application where maximum performance is essential, I continue to use FreeBSD on some servers, where maximum reliability and maximum simplicity in management are more important.
I have FreeBSD servers that have been used 24/7 for more than 20 years, with reboots normally spaced at no less than a year, which were needed only for hardware upgrades or kernel upgrades. In the default configuration, or only with very minimal changes that can be done in a single configuration file, the BSDs are much more security-hardened than the default configurations of most Linux distributions. If you take your time to carefully audit and adjust all configuration options, you can reach equivalent security regardless of the operating system.
I have used occasionally NetBSD and OpenBSD, but not on general-purpose servers or PCs, which are better supported by Linux or FreeBSD. Especially NetBSD is easy to port to various embedded computers (which is of course an explicit goal for it).
I think I could probably live on them. I am actually seeking a more restricted computer system these days... I really don't need DRM or slop apps or games.
I will focus on the things that people rarely point out. Btw. to be clear, I largely use Linux personally and professionally. So no evangelism here.
First of all: The BSDs are ALL general purpose operating systems, not distributions. I just mention this because there is that general "OpenBSD is for routers" and "NetBSD is for old hardware" nonsense. To give you an example. Various things including 3D graphics acceleration for various devices has been available in OpenBSD and DragonFly a lot earlier than in eg. FreeBSD even though FreeBSD for example has proprietary NVIDIA drivers available unlike the rest. People use all of them on server, as desktops and even on gaming devices. It's even kind of a myth in BSD communities that "this BSD is for X".
Something that people who aren't in the BSD users already and especially ones that do use Linux sometimes misunderstand is that the BSDs are independent of one another. Eg. OpenBSD and FreeBSD are as different as eg. FreeBSD and macOS, which is also a BSD and has A LOT of kernel and user space level code shared with FreeBSD. That's why grep -v says FreeBSD that's why docker uses (or used) xhyve which is FreeBSDs bhyve for macOS, which is why you got kqueue and dtrace, etc.
So in that respect "the BSDs" doesn't really work that well and is "dangerously" oversimplifying things.
All of them have a pretty good security track with strengths and weaknesses compared to each other and Linux. I would say it's overall even. But depending whom you ask the difference may very, because even in the Linux world there are different approaches to security. And as anyone having anything serious to do with security it's not that easy to measure security in first place. OpenBSD has a strong focus and achieves a lot on the C side and people who don't use any BSD at all actually and basically don't know it have critical C code compile on OpenBSD to spot issues affecting their actual target platform.
As for development. All of the BSDs increase in terms of development (only happen to know it cause someone once pointed me at an obviously wrong graph). I got a bit interested in that comparison because something that people like to underestimate is that single individuals are still the ones doing huge chunks of big projects. It's insane. Linux kernel might be one of the very few exceptions because a huge amount of people make hardware essentially for it for a living (SBCs and so on). Even if you look at other "big" projects like Postgres and so on which huge companies absolutely rely on it's a couple of people doing insane amounts of work. You have that in all BSDs.
FreeBSD sees a lot of usage as a base for commercial OSs (video game consoles, Netflix cache servers, etc.). However to be fair while some parts come back to the OS they also have companies that shamelessly take code without giving pretty much anything back (looking at you, Apple). Nobody is angry at that cause that's the terms and people in the BSDs often contribute out of the drive to make a great OS.
Something in my opinion greatly overlooked is that FreeBSD has one of the best package bases of all open source operating systems including all the Linux distributions. This is somehow rarely advertised but you have a huge official, very stable, very up to date, highly configurable "repository". I think this is pretty much unmatched elsewhere. It's like having Arch AUR, but without the security nightmare nor instability. In fact getting a commit bit is on the harder side compared to many Linux distributions. Many official package maintainers cannot commit on their own. This means that the "many eyes" does a lot of work there.
You get binary packages with one of the best binary package managers out there (classic case of being late to the game, but taking all the leanings and doing a great implementation).
You get close to 35k of these "ports" both binary or compiled if you want. If you compile yourself you get a huge amount of flexibility. My go to example for this is pick and choose a Postgres and PostGIS version combination, but there are many other examples from disabling adding docs, to optimizations to a stunning amount of third party nginx patches giving you better than commercial version experience. That coupled with a great flexible automatic build tool called poudriere, which you can use to create repositories of all or parts of these 35k ports and your chosen options for different versions of FreeBSD.
I am not completely sure but the sheer amounted of vetted(!) packages is unseen anywhere else. There is a security database, there is deprecation warnings and since the base OS and package separation (maybe the common differentiator of BSDs compared to Linux) you can match stability with the latest packages (or older version, eg. in Postgres), which is something I really miss in the Linux world even though there is nothing that is because of the OS/kernel it runs. It's simply nobody in the Linux world did put the effort in so far.
While FreeBSD has had a couple of not so great defaults - I think maybe to do with how many long term FreeBSD users any ways have their custom configs and trying to be compatible with upgrades - I think it got better. On the other hand they have and had a lot of projects on that front. jails predated pretty much everything else in the open source world, there was the TrustedBSD project, now there is CherBSD which puts a capabilities system in to hardware, etc.
OpenBSD also has a strength that is overlooked in that for a lot of "set and forget" style applications the base OS is enough. You get a highly secure (custom) HTTP server, a custom acme client, a custom load balancer (relayd), one of the best firewall implementations, etc. out of the box. I love to use it for simple I need something so that one can upload files via SFTP to a HTTP server setups. Just run syspatch and every half year sysupgrade and you are good. OpenSMTPD is also an absolute breeze and also having a Go application running with pledge and unveil (basically a way simpler easy to use seccomp) is great. Also for some reason there is a serious gaming community on OpenBSD making things work without wine (doesn't even work on the OS) in a way that is hard to believe.
Another thing is that a lot of "everyone uses them" tools come out of OpenBSD circles. Eg. tmux, OpenSSH, sudo (even though doas replaces it), OpenNTPD, OpenBGPD femail, etc. Also LibreSSL and sndio which always pop up on Linux in the least expected places (like games) for some reason. They all of that heavy focus on simplicity, but done in a non-academical but very real world scenario. They also do a lot of work in the compiler scene on the security side.
NetBSD and DragonFly also have their often very unexpected strength. Eg. DragonFly supports multiple ways of full file system encryption, including truecrypt compatible one. NetBSD while working on a Dreamcast also has very interesting and it runs in unexpected places like the ISS and somehow there have always been DARPA contributions, while in all BSDs at least subjectively the most to NetBSD. Mostly because there I've also seen quite a few pkgsrc (their non-base-OS packages) contributions. pkgsrc probably is one of NetBSDs biggest impacts being using by lots of other OSs from Minix to illumos. And on that topic, Android has (had?) quite a few NetBSD parts (in place of GNU userspace software) and Microsoft took the network stack from the BSDs and Internix (which was the predocessor to the Linux subsystem from when they wanted to be compatible with Unix datacenters, etc.) was largely a modified OpenBSD system.
Again, not a BSD users, and BSD people being very practical and less of a cult they'll usually tell you to keep using Linux if it works for you. But I think there also are a lot of misinterpretations when you used Linux all your life.
In fact the hardest thing on just trying it will probably be it NOT being Linux and also when switching between BSDs. They are simply other approaches to making an operating system. So if you take away one thing from this it's they are general purpose operating systems in their own respect and while they share code so does macOS, which as mentioned is also a BSD.
Use Linux if it works for you, but just for people trying it out: If you wanna actually be able to compare it you really have to use it and get it else you will just be annoyed with it not being Linux. Kind of like when you try a different editor, programming language, etc. Just don't make the mistake thinking BSDs are like distributions. That's a bit like thinking AIX and macOS are just Unix distributions. Even Solaris I think in very old versions was BSD based. ;)
are you asking these questions sincerely or is this just your passive-aggressive way of saying that netbsd is dead and nobody uses it? and why does everything have to be compared to linux? isn't the whole reason we developed free and open-source operating systems is to have lots of different choices and not just one universal corporate-controlled OS that everyone thinks of as the yardstick by which all other OSes are measured?
It was a sincere question and I found your comment quite off-putting.
You're talking to someone who spent a month in college installing every free OS I could get my hands on (including the BSDs). I find alternate operating systems interesting, but haven't played with them much lately. I compare other free Unixes to Linux because I use Linux every day and it's what I know.
It's interesting to think of hypothetical scenarios where an alternative to Linux might be more compelling to me for some reason (eg. is OpenBSD objectively more hardened than Linux? Is NetBSD objectively more portable? etc.)
The current status? If you're considering doing anything serious with Unix, absolutely you should use Linux. No question. Don't waste your time with any BSDs.
But ... if you want to teleport back to the 90s and go back to an era before Linux took off on a rocket ship to universal dominance then the BSD are for you. You will find a much more curated experience when people thought that documentation mattered. It is the road less traveled.
And dozens of critical bugs because it's basically the X.org of filesystems, complete with horrible quality C and half of Solaris tacked to it in the form of a shim?
Compared to Linux, all of them lag pretty badly in one or multiple areas (performance, features, hardware support, available software...).
They can be excellent in very, very niche use-cases. I run my personal site on openbsd, because I want to do minimal admin for what is a super-basic setup; but that's it.
My thought here is to proactively verify that LLVM elided the automatic bounds checks in places where you believe that your explicit checks should be sufficient.
1. It's not reasonable to expect the application layer to carefully partition its work into "I/O heavy" and "CPU heavy" parts.
2. It's not reasonable to queue up an arbitrary amount of work without back-pressure.
I haven't used Tokio much, but if it falls prey to these pitfalls, it would make me pause before adopting it.
I think there are probably ways of using Rust async that don't fall prey to these. Maybe not so much with network servers (I haven't written that many of those), but models where you are evaluating a graph and have more control over how new work is added to the system.
I think 2 is a reasonable concern (and one which has solutions in rust async/await tokio, as FridgeSeal points out). I'm not sure about 1 though. I think having a rough idea what part of your programs are computationally expensive shouldn't be to much to ask of programmers.
> but if it falls prey to these pitfalls, it would make me pause before adopting it.
This issue isn't really a Tokio concern, it's pretty straightforward to write Rust code that has back pressure mechanisms. The "it's not reasonable" in my mind implies that if someone goes and _does that_ then there's not much a library can do to restrain the developer.
> It's not reasonable to expect the application layer to carefully partition its work into "I/O heavy" and "CPU heavy" parts.
If your application has both of these and doesn't partition them, you already have a fundamental flaw in your application architecture. Every serious piece of software does this, from web GUIs, to servers, all the way to video games.
> It's not reasonable to queue up an arbitrary amount of work without back-pressure
Absolutely, which is why we use pull-futures instead of push-futures, across the entire rust ecosystem. Creating unbounded queues in Tokio requires a fair bit of error on the part of the programmer
> There's a dichotomy being presented here where you have to either choose a "style guide" or a programming language feature in order to avoid bugs. The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it. You're not giving TigerBeetle nearly enough credit. Quite simply they put in the time to find and eliminate the bugs, they make an effort to maintain a healthy relationship with ZSF, and Bun did not do that.
This is not a compelling sales pitch. The point of using a memory-safe language is not needing to put in extra work to avoid use-after-free or out-of-bounds memory access.
It would have been more reassuring to hear that Zig has its own memory safety story that should also be able to prevent most of the same bugs. But instead the answer is "work harder for the same result."
When Zig was first created, Rust looked genuinely harder to use because the borrow checker is so demanding and its errors sometimes so hard to reason about and fix. It made Zig look much simpler and easier by comparison. But now, LLMs are very good at writing Rust. I've been writing Rust using LLMs for weeks and haven't thought about the borrow checker once.
AI made Rust tractable without heroic effort, and in doing so eroded one of Zig's major advantages.
The point about compile times is taken though. Rust is definitely slow to compile, easier to believe it's slower than Zig.
I think you can easily turn this around: scientists who are only willing to do science if it involves preferential treatment, DEI statements, and other practices that half of the country despises are saying that it's better to do no science at all than to set those divisive practices aside and just do science.
Proponents of these policies want to have it both ways; they're at one moment just this small thing that nobody should be bothered by, but in the next moment a nonnegotiable bedrock principle that they are unwilling to stop doing, even under threat of losing funding.
This group of people you're describing ("scientists who are only willing to do science if it involves preferential treatment") is simply not real. The idea that academics would cling to DEI statements or refuse funding is beyond laughable, and could only be dreamt up by someone who has never experienced academia.
It happens indirectly all the time. As of 2025, despite all the funding cuts, the AAAS is still publishing its yearly DEI report, now rebranded as an "Inclusivity for Excellence Report", but containing all of the same stuff: an effort to collect and publish as much demographic data as possible, and a stated goal of getting all the numbers to go in the "right" direction. These practices are too ingrained and sacrosanct at this point to let a mere funding crisis throw them off course.
Williams College wasn't content to blindly follow a vague directive restricting their speech. They already received very few grants as the article said. You better bet most scientists at big institutions were tripping over themselves to police their own speech to ensure they aren't uttering any of the new forbidden words like "engender."
> These practices are too ingrained and sacrosanct at this point to let a mere funding crisis throw them off course.
Yes, some people have egalitarian principles. As much as you think there is a conspiracy against your group to keep you down it's just not true.
The French, who have "égalité" in their national motto, prohibit the kind of demographic tracking and reporting that US Progressives consider core to their project. Do you think the French don't care about egalitarianism? No, they just have a different concept of what that means. Just like many Americans.
Academics could broaden their horizons and consider the possibility that there are multiple perspectives on egalitarianism, and that the public that funds them is quite split on the issue. If Science is really the priority, it should be easy to stay neutral on unrelated contentious social issues. But I guess it's more fun to preach and condescend to people who disagree, and then complain when those people don't want to fund your enterprise anymore.
US science is in chaos not because of pushback against this evil "demographic tracking and reporting", but rather an extremely capricious attitude towards any research from the administration. This isn't about the practices of the universities choosing who gets a grant. The administration is terminating random grants based on keywords that they find in the abstracts even if the keyword has nothing to do with evil DEI.
> If Science is really the priority, it should be easy to stay neutral on unrelated contentious social issues.
Science is being used to study these contentious social issues. That's the kind of science that's getting suppressed, _but that's not even the issue here_
I am not convinced that separating students by ability harms anybody's academic performance. I think it's a false premise that a parent who wants their kid in advanced classes (or advanced schools) is behaving "antisocially."
When there is too great a difference in ability in a single classroom, teachers struggle to serve everyone's needs. I don't believe anyone is well-served by this.
>I am not convinced that separating students by ability harms anybody's academic performance.
You're not convinced that it can do that, that it typically does as currently implemented, or that it always will do that?
Presumably you agree that as long as a student is capable of keeping up with the material, they'll do better (in the long run if they get placed in) in a higher level class. Otherwise there would be no benefit in separating the students in the first place! I assume you also agree that we don't have any perfect tools for assessing a kid's potential. Thus, when separating kids, we will necessarily get some wrong, to their detriment. So, I hope, you're willing to concede that this could harm their academic performance.
Now, the extent to which that happens under any given paradigm is very much up for debate. But hopefully this illustrates how separating students by "ability" could harm "anyone's" academic performance.
Instead of "verb object" (eg. delete word or "dw"), it is "object verb" (eg. word delete, or "wd").
In particular, it seems to obsolete "visual mode" from vim (which I use often), because you're essentially always in visual mode. You always get to see a selection before you perform an action. Or at least that's what I understand, I haven't tried it yet.
reply