FreeBSD definitely has things to offer compared to other operating systems, but I'd also argue that the reverse is true in many cases.
Linux, generally speaking, has a much nicer upgrade story. FreeBSD's works, but having to reboot and run freebsd-update multiple times during a major upgrade is annoying.
FreeBSD's init system works and is generally fine, but I much prefer the simplicity of systemd unit files over FreeBSD's rc scripts. The common use-case of "Run $X as user $Y, capture it's output, restart it if it dies, and track it's PID" is incredibly easy to do in a systemd unit file. FreeBSD could learn a lot here[0].
Related to the upgrade story, packaging is interesting in FreeBSD. The base system is just "there" and managed by freebsd-update, but 3rd party software is installed via packages (ports build a package then install it). The separation of base (/, /usr, etc) vs 3rd party (/usr/local) is good, but it would be nice if all of the software was managed the same way. FreeBSD has started work on this[1], but I have no idea if it's actually going anywhere.
> Linux, generally speaking, has a much nicer upgrade story. FreeBSD's works, but having to reboot and run freebsd-update multiple times during a major upgrade is annoying.
This also annoyed me so I implemented one reboot way with ZFS Boot Environments - described here in details:
Sometimes its even possible to upgrade without reboot as beadm(8) supports the 'reroot' feature. If you kernel did not upgraded - then you do not need to reboot - just reroot:
The first one goes into a servicename/run file, and the second into servicename/log/run.
Running the run file is precisely what the daemontools system will do. There's no need to track the PID. `svstat servicename` will tell you how long it's been running or if it's disabled. The default is to restart on death, and if it flickers too much, disable it. Adding /etc/init.d wrappers to this is a 60 second edit of a skeleton file.
Code is superior to configuration when the code is this simple.
As much as I really really dislike systemd, bash is not the answer.
I think we should try to do something better, I’m certain nobody will agree on a good language to use but I might propose starlark (a dialect of python, which recently got a rust implementation of the language thanks to Facebook).
I should add: I’m quite adept at bash (I have the LinkedIn skill badge! (This is a joke)) but I can agree with people who dislike it, there are too many edge cases, it’s not easy to understand and while expressive and powerful: evidently we should have something that is easy too.
First, there's no requirement to use bash. Any shell that has an exec equivalent and can redirect stderr to stdout will work. There's not even a requirement for it to be a script -- daemontools-style supervisors don't parse the run program, they execute it. It's pretty convenient to use the setuidgid tool, though.
So if you want to run starlark, or oil, or your favorite lisp dialect, go ahead.
Nothing prevents us using alternative interpreters for rc.d, ones with hooks for process supervision, hooks for something akin to cgroups, centralised logging and so on.
But as a user who makes init scripts: you can do anything, which is pretty liberating when you really think about it.
> Linux, generally speaking, has a much nicer upgrade story. FreeBSD's works, but having to reboot and run freebsd-update multiple times during a major upgrade is annoying.
This is the only issue I have with FreeBSD. On my desktop is one thing, but trying to manage upgrades across a large fleet of remote servers? No thanks.. (To be fair, this goes for some Linux distributions as well. Upgrades should never require user intervention.)
We do it via ansible, we create a boot environment (bectl create something) mount it (bectl mount something), then ansible upgrades the os and|or pkgs in the new be, and reboots into it. BE choice at boot is provided by some pxe/DHCP magic we rigged up.
If a host fails to come back up, we boot back into the old environment, and someone from ops gets a ticket to try it again manually (rare, usually the OS upgrade works, but then fails the app healthcheck).
We manage 1000s of instances this way, and it's saved our skin lots of times.
We can't do that on linux where we have to depend on hypervisor snapshots (we run proxmox hypervisors mostly) which stop the world for memory state and cause some issues for us.
I can generally rely on FreeBSD to actually boot up properly, after doing a major upgrade.
I can't say the same thing for Ubuntu. I've lost track of the number of "oddities" that have occurred. Examples: network interfaces getting renamed, missing default routes, UEFI boot weirdness that can only be resolved from the console. Maybe I just have bad luck.
Systemd is in control of all of those issues (network devices, routes, mounts, etc). Unfortunately, almost all Linux distributions are really just different distributions of systemd now.. most likely the lines of code in systemd components far outweigh the package management components which are the clearest differentiator between one distribution and another. (definitionally, a distribution distributes packages.)
FreeBSD was the first *nix distro I used, and I used it for many years as both a server environment and a workstation.
I agree with every point I ever see (in this and similar articles) about why FreeBSD is awesome, but I don't use it because when I create a virtual machine on GCP the default is Debian, and when I download disk images from the Orange PI or Raspberry PI websites they're Debian.
I know that I can set up FreeBSD on both those platforms, but it's way easier to use the default because it's the thing that's most widely supported and has the most documentation.
Nowadays the internet is so well stocked with answers that I can find copy and paste ready configuration and/or commands for just about everything I need to do with Linux on StackOverflow so the fact that I don't particularly know a lot about Debian doesn't really matter.
I have no idea how or why Debian became so popular, and I have no idea how FreeBSD could replace it.
I hope someone figures it out though! There's a lot to love about FreeBSD.
> I have no idea how or why Debian became so popular
Oh, that's simple, it's the package management system, debs.
The early redhat experience involved opening up the redhat webpage and downloading every rpm related to the system you were maintaining in order to update or install stuff. yum came in 2002.
Debian started with apt-get in 1998. With debian, it was `apt-get update`, `apt-get install thing`, and `apt-get upgrade` and you get everything you want/need to run stuff.
For why not FreeBSD, IDK, but I'll guess that the linux kernel simply got more attention and corporate support. I don't think there's much beyond that.
Linux became more popular than BSD because the AT&T lawsuits made the legal status of BSD questionable. By the time it was cleared up, Linux had the momentum.
I am not sure that Debian popularity really had much to do with it. The first Linux distro to really pull away from the pack was Red Hat ( pre RHEL and Fedora ) with the introduction of a package manager ( RPM ). Most of the other popular distros of that era were based off RPM ( Mandrake and SUSE for example ). But RPM at first required downloading packages individually before they could be installed or upgraded. You could upgrade an entire installation to the next release with a CD that had all the new RPMs on it.
Debian solved that problem by introducing the concept of a repository. While .deb files worked similarly to RPM, “apt-get update && apt-get upgrade” was a new thing. Even then, Debian was kind of a niche, power-user distro. The revolution came when Ubuntu created a more user friendly version of Debian. RPM based distros eventually got YUM and other repository based equivalents to apt-get but by then Ubuntu had the momentum. I think Debian became more popular later because of Ubuntu ( though I may have that wrong ). Ubuntu itself had a huge diaspora with many other popular distros starting off as basically Ubuntu modified to address some user complaint or other.
These days, it feels like the torch is being passed to the Arch based distros.
FreeBSD may never regain its position vs Linux but it has maintained its market position pretty well relative to some Linux distros I would say.
> These days, it feels like the torch is being passed to the Arch based distros.
It does. What would you say are the features driving that? My guesses are:
1. Users find repository management painful or cumbersome, especially but not exclusively on deb-based distros. On Arch you've basically got a couple of distro repos plus a giant catch-all (the AUR) so there's no real repo management in practice.
2. Speed is a package manager's most visible, user-facing feature, and pacman is very fast, relatively speaking.
3. People have bad experiences of botched release upgrades, and most Arch-based distros just don't have those
4. The AUR has a very low barrier to entry, which substantially soothes the typical 'straying from the happy path' pain point, because it means there are easily available packages for novel, proprietary, and quirky or ill-behaved applications which can be difficult, impossible, or slow to get packaged and maintained so they can reside in a distro's main repos.
> Linux became more popular than BSD because the AT&T lawsuits made the legal status of BSD questionable. By the time it was cleared up, Linux had the momentum.
In theory this was the e
reason. In practice, Linux played nicely with the PC partition table and linux installers became newbie friendly much earlier than BSD. BSD did not have a graphical installer until DragonflyBSD. Also for many users, the ability to coexist with Windows and DOS was crucial. BSD did not advertise DOS compatibility (fatfs) and dual booting.
> I have no idea how or why Debian became so popular
Ah, the old days of sourceforge, when each package downloaded for configuring something in redhat asked for a couple of another missing packages. Packages that in turn asked for a trio of missing packages. Each one of them asking for four new libraries missing...
As a long time Mac user with a FreeBSD home server… what does homebrew do that pkg doesn’t? I guess homebrew has casks but that’s moot on a server that’s never going to run anything with a UI.
I don’t have much to say about docker except that its dominance can be irritating when you don’t want to strongly couple all your things with Linux (yes, it technically runs on macOS and Windows but not very nicely…). I keep hoping for a more platform agnostic container to steal the show.
Unless you absolutely need BSD in production, there's a lot to be said to just use something more common/mainstream instead. I.e. Linux. It's probably going to be a lot cheaper and there's not a lot it can't do.
I'm sure BSD has some unique features and properties that make it very appealing to use for certain things. However, what makes it very unappealing is the fact that there just aren't a lot of people with relevant skills and that the ones that do exist are probably on the expensive side. Many Linux users could probably train up, if they wanted or needed to. But the reality is that most never do that. Either way, hiring people with BSD skills is probably harder than finding people with Linux skills.
The price of running BSD in production in a responsible way is that you need a fairly sizable team of >4-6 people. Probably salary cost alone would run close to a million per year. That's a big commitment to run anything and hiring is going to be tough.
Bare metal linux has the same problem but with the difference that a lot of people have experience using it and there are all sorts of companies that can support you with this. And people tend to start using linux in cloud based environments where they can outsource the business of keeping the environment up and running. So Linux allows you to start very cheaply, relying on skills most devops people and developers already have, and then later transition to a bare metal setup with some standardized thing from a company that can offer you lots of support.
No reason BSD could not work like that but of course it has been historically been like that at all and is mostly a thing that shows up on bare metal instead in a few companies that for whatever reason decided that was a good idea; maybe a very long time ago.
Running BSD on a vm hosted on linux is of course possible but probably does not make a lot of sense. Doing it the other way around might make sense if you are in the PAAS/IAAS business but it seems most of that industry has long standardized on Linux. Would there be any benefit for them to switch?
>The price of running BSD in production in a responsible way is that you need a fairly sizable team of >4-6 people. Probably salary cost alone would run close to a million per year. That's a big commitment to run anything and hiring is going to be tough.
This is flat-out wrong.
I single-handedly managed a fleet of over 100 FreeBSD servers running in various data-centers all over the world. 90% Nginx, 10% Apache. Mostly Wordpress websites. The 'brand' was #3 in the world for it's niche. $Million+ revenue.
So, what happens when you sleep and any of your 100 servers go down; or you are on vacation; or you get hit by a bus; etc. and they need somebody with BSD skills to fix it? Don't tell me that doesn't happen.
The words "single handedly" are a dead give away: you're a single point of failure unless there's more than 1 of you.
It might be easier for you personally. But for a typical organization finding 4-6 of you would be a challenge. And unless they would, it would be a problem waiting to happen.
The problem you describe is the same for any org that needs sysadmins. Linux or Windows can go down as easily as FreeBSD, and a single operator would be just as much a point of failure.
What should an organization that cannot afford a full operations team do? This is not an OS question.
Let me throw in a personal anecdote. I live pretty much in the middle of nowhere, in a city you've never heard of, in a relatively poor country. (The typical dev salary here is around $1k per month, 3× less that for juniors). Even around here, practically every IT person I know has some Linux experience. System administrators of various sorts have loads of it. Meanwhile, most have never heard that the BSD family exists at all, and almost no-one has any experience with it.
Of course, it isn't representative at all of what happens in places that actually matter (like California..), but still.
> Linux or Windows can go down as easily as FreeBSD, and a single operator would be just as much a point of failure.
That wasn't the original point though.
The problem presented is "The market for FreeBSD operators is smaller than the market for Linux operators". Which was countered with "I, as one guy, could manage 100s of freebsd servers".
That does not address the initial problem. There are a LOT more sysops people skilled in linux operation vs BSD operation. That means choosing FreeBSD limits your pick of people that could reasonably manage a fleet of servers.
The problem is that it is a self-amplifying logic, a self-fulfilling prophecy of disaster: you pick Linux because it's easier to hire, so there's less job offers for FreeBSD, so job seekers (and schools) focus on Linux, so it's harder to hire FreeBSD sysops and easier to hire Linux sysops.
That's how we create software mono-cultures, end up being forced to use mediocre software, and how searching for vulnerabilities becomes very profitable (ransomware etc.). Companies should think about the ecosystems they live in, not only about their sole immediate profit.
> Companies should think about the ecosystems they live in, not only about their sole immediate profit.
I contend that companies ARE thinking about the ecosystems they live in when they pick the boring things everyone else is doing. That's what drives picking boring technology is the ecosystem surrounding that tech (Libraries, articles, experts, education, etc). Ecosystem is more than just the diversity of choices.
Software doesn't live in a bubble and we are long past the days when an interesting language feature can trump modern infrastructure.
A company that decides to write their app in Erlang because it's neat and interesting will be at a disadvantage to a competitor who decides to do the same project in java. Even though erlang has a lot of neat features, java has a giant ecosystem and support structure.
While you may have a point that its harder to find a BSD person, I would say because BSD has a cathedratic model, it is much much easier to get up to date with it. While Linux has sporadic documentation, you have to go scavenge through the entire internet looking for answers, everything is in one place, the freebsd forum. ports itself even comes with a file containing bugfixes and notes, telling you what breaks and what precautions to take with each software. The bazaar model is hard to grasp and learn from. GNU has pushed their business model to be books. It means you have incomplete documentation (man pages) everywhere. You either buy the books to know how things work internally, or hopefully someone somewhere jotted down your problem/solution, albeit in SO, a ML, some book or who knows where.
This is the truth right here. With the skills you have as a Linux person you can easily migrate to (Free|Open)BSD.
I started with Debian in ~1994'ish (USB didn't work yet, it was probably the stable branch at the time). I had DECADES of experience with Linux.
It was easy to transition to *BSD. This is the beauty of Unix. I still get a brain fumble when I'm bouncing between systems and type the wrong command on OpenBSD vs FreeBSD when I'm doing something common like installing or searching for software. The core mechanics work everywhere. Knowing the right question to ask when searching gets you that last 10%.
How do I restart the $X service on: (OpenBSD, FreeBSD, RedHat, Debian, Arch, ...etc)
(Free|Open)BSD are more simple, while Linux feels more automagical in the way services are managed. I dislike SystemD for this reason and prefer the BSDs.
I absolutely need to use BSD for my hobby pursuits :) I think that reasoning is iron clad :D (In probably a lot of cases, that's where future popular things start.)
Certainly, if I was in the position to make infrastructure decisions for my employer (which I am not, plan never to so it will never happen), then the decision has mostly been made for me. In fact, many decisions have been made, and it doesn't just stop at relying Linux and the GNU userland if I rely on a popular distribution.
FWIW, there is a lot of obscured differences between BSDs and GNU/Linuxs as I see, but installing and getting setup on FreeBSD on my laptop felt quite familiar (maybe more culture shocks than anything - like there is no `sudo` in the base system :) )
> installing and getting setup on FreeBSD on my laptop felt quite familiar
Yeah, people are making it out like the two environments are totally different from each other. Any competent Linux admin would be able to cross-train on any of the BSDs pretty quickly, and vice-versa. It's mostly a matter of, "Hey Google, where the hell is X in TrendyBSD? Ok, thanks."
> The price of running BSD in production in a responsible way . . . would run close to a million per year
If true, this would of course be a great reason not to use BSD, but I've seen too many single person startups on HN using FreeBSD over the years to believe this statement.
Lots of startups fail. Lots more get lucky just not having anywhere close to five 9s or people that just don't take vacations, leave, get sick, etc. Been there done that.
The wiser move is to outsource risk like that to cloud services. It will cost you but far less than hiring a team to get your five nines of uptime would. I maintain several clusters and we have a few people that can do some emergency fixes. But I am a bottleneck when it comes to knowing how to. Having BSD in the mix would make this far worse for us.
>The price of running BSD in production in a responsible way is that you need a fairly sizable team of >4-6 people. Probably salary cost alone would run close to a million per year. That's a big commitment to run anything and hiring is going to be tough.
I remember when MS used to say similar things about Linux.
> The price of running BSD in production in a responsible way is that you need a fairly sizable team of >4-6 people. Probably salary cost alone would run close to a million per year. That's a big commitment to run anything and hiring is going to be tough.
Not sure where you got your numbers from, but I have been maintaining FreeBSD servers for 2 decades and would estimate the attention a machine needs at about 10% of what a Linux box needs.
> I have been maintaining FreeBSD servers for 2 decades and would estimate the attention a machine needs at about 10% of what a Linux box needs.
I was talking with a longtime Linux security administrator about why he was converting much of his security stack over to OpenBSD and retiring his Linux security boxes in mass.
Similar to what you mentioned, he estimated his maintenance needs for OpenBSD at 5-10% of equivalent Linux systems, and the increased security posture was gravy on top.
> there's a lot to be said to just use something more common/mainstream instead. I.e. Linux
For those of us who worked the industry in the 90s and remember the pains of "just use windows like a normal person and forget this weird linux hobby thing", there's some irony in saying that.
Common/mainstream doesn't always (even usually) mean better. With Linux (not Linux the actual kernel, but Linux userspace distros) going in directions away from security and stability in the search for mainstream-ness, the BSDs feel like breath of fresh air these days. Very similar to how Linux felt back when everyone was telling me to run windows.
> The price of running BSD in production in a responsible way is that you need a fairly sizable team of >4-6 people. Probably salary cost alone would run close to a million per year. That's a big commitment to run anything and hiring is going to be tough.
Meanwhile WhatsApp ran their entire infrastructure on FreeBSD and were able to serve a billion end-users with not a lot of people.
I have read that the FreeBSD networking stack is one of the best out there. Some of the largest companies are running their products on FreeBSD. Facebook, I believe, runs a ton of FreeBSD.
>The price of running BSD in production in a responsible way is that you need a fairly sizable team of >4-6 people. Probably salary cost alone would run close to a million per year.
It's the price of not being dependent on IBM, Oracle, or any other customer-hostile company. Besides, frankly, those 4-6 people will provide _way_ better quality of service than offshoring.
The learning curve from Linux to BSD is not much really. I took on a gig looking after 100+ FreeBSD boxes (IBM bare metal servers) and the transition was much easier than expected. The documentation is fantastic, and the separation of "base" vs 3rd party software/config was a refreshing change.
The client opted for FreeBSD as the OS seemed to handle much bigger traffic without breaking a sweat (HAProxy, Nginx, PHP & MySQL)
Overall I enjoyed the exposure to FreeBSD and learned a lot in the process.
In all fairness all these comparisons and all these BSD vs. another BSD vs. Linux OS wars are becoming long in the tooth. There haven't been any news or revelations in a long, long time. Want to try a BSD (or a Linux distro) on a VPS? Good for you. Want to do it on a laptop? By all means. Want things to work out of the box? Get a system with an OS preinstalled (and supported). Otherwise, the differences between the OS you'll find will be minor.
> Otherwise, the differences between the OS you'll find will be minor
I think this is by design. If things are too different from one os to another, it raises the barrier to entry and hampers adoption. Furthermore, Linux distributions often also rely on things like standardized tooling and file system layout to ensure backwards compatibility
There are people who try to do new things in the space (gnu guix and nixos come to mind), but they tend to be comparably fringe when put side by side with something more mainstream (and perhaps battle-tested) like Debian or BSD
I feel like these articles always do a disservice by misrepresenting things about Linux. Just some parts I stumbled over:
> [about jails] They are also very easy to debug and troubleshoot comparing even to plain Docker – not to even mention Kubernetes which requires whole team of highly skilled people to maintain.
Yeah, of course, a single-node container tool is easier to run than a Kubernetes cluster.
> Can you tell my how many steps (and which ones are required) to rebuild CentOS or Ubuntu for example without Bluetooth support?
Why do I need to rebuild without Bluetooth support?
> When using systemd(1) you never know how the services gonna start because it will be different each time. Zero determinism.
systemd starts services in dependency order. The author makes it sound like systemd just randomly shuffles the services each boot for fun.
I'm not sure if this is still the case, because I no longer use Linux, and I may be misremembering it. But IIRC a good while back, there was no way to guarantee service start order at boot.
You could specify dependencies for some services, but even then, if there was more than one choice of dependency order that satisfied the requirements, systemd did not guarantee that the same one would be used on each startup. Otherwise, services with no dependency specs (or groups of services at the end of the same dependency chain) would get started in parallel. If you really wanted to start a sequence of services in order, doing so by specifying dependencies in separate unit files was really painful and basically impossible to debug, especially since dependencies weren't exactly easily described (various combinations of After=, Requires=, Wants=, BindsTo= that went both ways between targets and service links in the dependency chain).
Please note the "I may be misremembering it" part. My life is a lot happier now that I no longer need to care about Linux userspace stuff so I may be repressing some memories :-D.
Edit:
> Why do I need to rebuild without Bluetooth support?
The author chose a lazy example. Yeah, you don't usually need it. A better example: rebuild with `CONFIG_BFQ_GROUP_IOSCHED=y` to enable proportional weight division of disk bandwidth in CFQ.
Systemd still has no dependency order. You still use Requires=, After= ,etc. Otherwise it'll start when it starts.
I don't think dependency order is particularly valuable in the real world. Manually specifying order imposes a strictness upon reality that isn't there. Most apps are messy and starting a system tends to be a messy affair in of itself.
The much simpler solution to specifying services to start in order is to write a script and have one big service start and terminate them.
But I can't really imagine a real world scenario where that is somehow better than just giving each service the dependency definitions it needs.
edit: the simpler solution to compiling the kernel is just blacklisting the module. Then bluetooth won't be loaded obviously. Though not everything can be a module, in practise I've found it to be rare that I was looking for a kernel option to be enabled that wasn't in my distro (but then again, I run most of my personal stuff on archlinux, which ships a near default config of the kernel anyway).
> I don't think dependency order is particularly valuable in the real world. Manually specifying order imposes a strictness upon reality that isn't there.
I mean... sometimes you have to do it, because that strictness really is there.
> the simpler solution to compiling the kernel is just blacklisting the module.
What module? I'm not talking about removing a module, but changing a compile-time option for one.
Removing a module is certainly best achieved by just blacklisting it, that's why I mentioned this as a lazy example that the author picked. (But, FWIW, even that has unexpected consequences. A while back, for example, you could (sometimes significantly) improve the startup time of most embedded devices running Linux by removing the modules instead of blacklisting it because going through the list of blacklisted modules is surprisingly slow. That's probably not a relevant use case for what the author of this article is describing though)
If it's really needed and there is no way around it, it'll be painful in almost any sane and modern init system (OpenRC isn't that much better at it than Systemd, neither is svcs from Solaris which sucks the most at configs).
A good init system IMO doesn't have deterministic behaviour built in but rather as emergent property. Your start order falls out of the service definition.
---
The bluetooth module. Linux is highly modular and you can blacklist modules you don't want. And you can even compile modules after the fact. If you need bluetooth but your distro didn't ship it, you can in fact compile just that module and load it.
Only some core options need a full recompile of the kernel but that isn't too terrible on most distros (apt source, Arch's ABS, etc.) either.
What bluetooth module? `CONFIG_BFQ_GROUP_IOSCHED=y` is a cgroup-related option.
It's not pretty, and not because of a lack of tooling (apt source, ABS, whatever). The problem is that, since there's no "standard" configuration that you can depend on (unlike FreeBSD), you can't just take a "standard" system and reliably change a compile-time setting (or compile a module, or blacklist a module). There are a lot more moving parts (other compile options enabled downstream, additional patches applied downstream, especially in LTS kernels, compile-time options for userland applications and so on) which vary from one distro to another.
I personally see the value of this approach. I think it's more flexible than what FreeBSD does. But it is far more time-consuming and, generally, pretty nerve wracking.
NixOS lets you do that kinda of stuff though. You specify that you want a kernel option enabled and it'll make sure that any kernel you install has it enabled or compiles one from the upstream source you set (or the default one).
Even upgrading your kernel will ensure the option is enabled. And it'll ensure that any downstream modifications done by wherever you pull the kernel from has them enabled too.
Any distribution can do that -- at the end of the day, you can always get e.g. the linux-kernel deb-src and set the option in Kconfig. That will not solve the rest of the problem -- interaction with other kernel config flags, or side-effects vs. applications that assume a specific kernel configuration and patch set.
No, NixOS solves that. Apps can require Kernel Config Flags to be set and the interactions between flags can be modelled in NixOS. And it'll all be side-effect free and the nixos rebuild command will tell you at build time if it's wrong.
> sometimes you have to do it, because that strictness really is there.
In that case, wouldn't it be more correct to specify the strictness explicity through service dependencies?
Service dependencies form a DAG. Sequential start of services can be modeled by a DAG in which every node except the first and the last one has exactly one dependency and one dependant. So systemd way of starting services is a superset of the traditional, sequential way.
That's sort of the model that systemd uses (used?). However, non-trivial setups that attempt to use it tend to degenerate into very complex beasts, for various reasons, including:
- Unit properties can be specified both ways. For example, an unit can specify both that it should start after another unit (After=) and that it should start before another unit (Before=). So if you have two units, B can start after A either because B's definition includes After=A, or because A's definition includes Before=B.
- Order and dependency is specified separately. If B depends on A (specified by Wants=A in B's definition) that does not, in fact, guarantee sequential start.
- Some properties only apply to some systemd units. For example, Before= dependencies don't (didn't?) apply to device targets.
> So if you have two units, B can start after A either because B's definition includes After=A, or because A's definition includes Before=B.
That's true. However, most software can be easily misconfigured if you don't know what you're doing. And when creating any kind of DAG, it's implied we need to avoid cycles. I suppose systemd could use a tool for visualizing service dependencies and order.
> Order and dependency is specified separately
Order is stricter than dependency, and it slows down the whole process. If things can run in parallel, they should. If they cannot, then we should specify it explicitly. Leaving out order would make systemd useless for situations when order matters, and leaving out dependency would slow the whole process down.
> Some properties only apply to some systemd units. For example, Before= dependencies don't (didn't?) apply to device targets.
I agree, the rules are pretty complex. I don't like that about systemd at all. Combined with the fact that there are 175 different options [0] you can use in a unit file makes systemd really unpleasant for writing any kinds of services. I have a couple of boilerplate unit files I've written long time ago and I just reuse them with changed parameters.
> I mean... sometimes you have to do it, because that strictness really is there.
In which case you specify service dependencies and systemd will start them one after another, you know, you have the After= option in your units just for that.
In all other cases does it matter jack shit, to put it bluntly, if your bluetooth services start after your NFS share exports or before them? Or is it some sort of OCD speaking?
> In which case you specify service dependencies and systemd will start them one after another, you know, you have the After= option in your units just for that.
First off, After= specifies order, not functional dependency. This doesn't do what you want which, I think, kind of proves my point. The complaint in the original article (and mine) isn't that it's impossible to specify order between two services, which, yes, you can do just fine. The complaint is that doing so repeatably across boot times is impossible (because systemd literally and explicitly does not support it) and that debugging the "weak" version of it is really difficult.
It's really difficult because Aftter= is, literally, one twelfth of the story, possibly less. Order and dependency ae specified not just though After=, but also Before=, Wants=, Requires=, WantedBy=, RequiedBy=, Requisite=, RequisiteOf=, Triggers=, TriggeredBy=, PartOf= and ConsistsOf=.
Ordering and dependency are treated separately by systemd. I think that's a good design trade-off but it's not without consequences.
If starting a service has dependencies, not explicitly spelling out those dependencies and relying on the init system is akin to relying on unspecified behaviour. So among other things, don't be surprised if that's unreliable.
> specifying dependencies in separate unit files was really painful and basically impossible to debug
This is actually quite easy to check and to claim otherwise is FUD
> This is actually quite easy to check and to claim otherwise is FUD
It's only easy to check if you have a small number of dependent services that mostly go one way. On the general case it absolutely isn't easy to check. If I had a dime every time I've seen non-trivial chains of serial operations implemented through a systemd target that just runs a shell script, I could erect an ice statue for Stephen Bourne and it would be made out of the frozen tears of everyone who's had to deal with both systemd and shell scripts.
Lennart wanted/wants devs to switch to "socket-based or bus-based activation", leaving explicitly defined dependencies behind; in that way, he kind of punted on the issue. That said, I find it fairly flexible, but, yes, complex (or not particularly transparent).
First off, dependencies aren't just other services. You can have "when the network interfaces are up" as a dependency, for example, so this isn't just about how many programs run at once and in what order.
Second, you care about it in scenarios where predictability is required. If your customer says they want their smart TV or their POS or whatever to boot in no more than X seconds under normal operating conditions, it's really not cool if the system can take a slightly different way to multi-user.target. Dependencies across separate chains can contend for resources, for example.
"But these are embedded systems, you should just run rc.local" I hear you say? Right. These things run like fourty services, from telemetry to user interface and from firmware update to encrypted cloud backup, half of them written in Node.js, on top of a system that's basically built for systemd. It's not something you can extricate yourself out of.
I don't know if there are equivalent examples in the server world (not my field), but I wouldn't be surprised if there were.
> Why do I need to rebuild without Bluetooth support?
Have you tried Bluetooth on FreeBSD? It's an unstable mess which does not support any newer device. Bluetooth always worked for me out-of-the box on any reasonable Linux-based OS. FreeBSD was like 20 years old memories of Linux Wi-Fi Cards. Remember 'ndiswrapper'? That's how bad Bluetooth on FreeBSD is. So the author probably assumes that Bluetooth is a piece of shite everywhere and want even Linux programs without a support or so.
I think determinism would be way better than a system with some pseudo random setup.
I think hand waving away the specific language used, ie "determinism" without really talking about what it means or why it does (not) matter is dishonest.
Causality and determinism are different, and it honestly makes sense to have it be random to tease out bugs as early as possible.
For a prime example see hash maps in Go, which is specifically non-deterministic when iterating over them to prevent users from relying on any kind of implicit behavior.
> "When iterating over a map with a range loop, the iteration order is not specified and is not guaranteed to be the same from one iteration to the next."
> Why do I need to rebuild without Bluetooth support?
I think the point here is that any code on your system is a potential security liability, regardless of whether the relevant feature is active. Removing linked in code removes potential security liabilities and as such it is always a good thing.
Regarding the original article's question Can you tell my how many steps . . . Ubuntu for example without Bluetooth support?, its not actually that bad
> Regarding the original article's question Can you tell my how many steps . . . Ubuntu for example without Bluetooth support?, its not actually that bad
Finally. I'm surprised at how many posters here deflected this point, because last I checked it's actually really easy on major distros.
I guess that tells us something about how many Linux users on HN have ever compiled their kernel, that most were like "LOL why?" and not "sure, it's easy".
> I think the point here is that any code on your system is a potential security liability, regardless of whether the relevant feature is active.
zzz... Then I guess any binary distro that you don't compile your own kernel with absolute minimum requirement aren't good? Not sure how Red Hat customers are doing their business then.
Something working out well up to the present moment does not mean that it is the best possible solution. Most stuff is garbage and could be improved. If you want the most secure system, you minimize the amount of stuff that’s in it and you increase the quality of that stuff that is there.
It's kind of crazy, people always say bloat here bloat there, but then come up with blacklisting....ahhh the forgotten "art" of just having the code you need on your machine ;)
I get the sentiment, but there is also something to be said for having a consistent and stable starting configuration. Yes, you might end up removing Bluetooth modules from servers, but you know exactly what the starting kernel config is. When you have completely custom kernels for each server, you’ll spend half of your time just figuring out what the starting configuration is.
Compiling kernels is really a lost art that many people have never done. It’s probably best to avoid too much of that in production until it’s absolutely necessary.
>It’s probably best to avoid too much of that in production until it’s absolutely necessary.
Well yes, being organized is always important, like a customer of mine wanted all Linux server with GUI and installed all of them as "Desktop-Role" aka preempt-kernel.
Gui-Server...bleh..but Customer is King, but i could at least change he's mind about the kernel so Gui-Server-Role it was.
If you blacklist it, it is also not there since it’s not loaded, and you get the added benefit of not having to recompile the kernel every time there’s an update.
A slimmed-down kernel make the difference from ~100MB (kernel) + 32MB (Modules) to 2MB (Kernel + Modules), faster load, or for smaller devices, and overall less potential attack surface.
I don't know why you people keep bringing up those subjects that have nothing to do with the thread.
This is about easily disabling support for one thing. The OP says it's easier in FreeBSD because you add a line to a text file and recompile the kernel. We're saying it's also very easy in Linux even without recompiling the kernel by simply blacklisting and/or deleting a module. Alternatively, recompiling the kernel is also quite easy but what's the point? To shave off 5kb from the kernel, or not even that, since the module is external anyway? My time is worth a lot more than those potential few kbs.
By the time you're fine-tuning your kernel to be the absolute minimum for a specific machine, it doesn't really matter if it's FreeBSD or Linux. It will take time and probably quite a bit of trial and error. And then again, if you have ever run `make menuconfig` on a Linux kernel tree you probably know it's pretty easy. In fact, the discoverability is excellent there, since the options are presented to you with explanations. Is that harder than manually editing a conf file, having to know beforehand exactly what lines to add/delete/edit and with what values? If you think it is, you can also edit the conf file for the Linux kernel.
I have nothing against FreeBSD, but this argument is total nonsense.
It should be clear that Bluetooth is not 90% of the kernel size...that's why i wrote "slimmed down" which means disable/not-compile everything not needed (like just one of 3 firewalls, filesystems, network-stacks etc).
>By the time you want to slim down the kernel that much, Linux, OpenBSD, FreeBSD, they're not that different.
Yes, but you don't do that by blacklisting modules right? Because that was your solution ;)
Oh yeah, since we care about security so much, let's have a whole fucking C compiler suite on every machine because what if we need to recompile the kernel to mitigate a potential problem that might not even be there!?
If you really care that much, you delete the modules and run depmod. It's fast and you don't need to have a compiler on hand.
Conflating a C compiler with security... Let me guess, you are some kind of old school script kiddie who believes security is improved by making it harder to compile a 0day? :-D
I know, when you run out of any arguments of merit, you call the other side "aggressive". But the truth is, you have nothing to say.
Okay, you can set up a whole container so you can recompile your kernel to your heart's delight. Fine. How does it scale? How do you distribute your new shiny kernel to hundreds of machines and keep track which is running which? What if you make a mistake, is it easy to roll back? How easy is it?
Also, need I remind you that a world where you don't have to (but can if you really really want to) compile things to get the results you want is infinitely better than a world where you have to compile things?
>How do you distribute your new shiny kernel to hundreds
Like you distribute a iso or a image, is that really so impossible for you?
>How does it scale?
As much as you want.
>What if you make a mistake, is it easy to roll back?
See you don't even know zfs or be's..or hell version's??...your a evangelist and i don't like them.
>I know, when you run out of any arguments of merit
Seams like you run out of arguments, again you can create your own image of freebsd without compiler, nfs, zfs whatever you want. But your are probably happy having the cruise-ship for the fishing side trip. Have fun with your religion.
He might be, but adding some levity to this, it might be that he is just deeply ironic (even if some here complain of things incorrect in his analysis.) :D
What’s useful about FreeBSD is that one can understand the whole system and have a complete model of it in your mind. Then you feel like it’s an extension of yourself. With Linux complexity skyrockets and sub-systems are not always consistent.
Here is the main disconnect I've found as a user of both in the past (FreeBSD 3-4 era).
Everyone forgets the GNU in GNU/Linux.
Everyone forgets the unix philosophy.
So they get on linux, and with no care of licensing, bloat, etc, tend to overutilize the vast package repos without taking a moment to think about their computing strategy.
Computing is inherently, a philosophical choice!
So for me, only having actually embraced the four computing freedoms as articulated by those such as RMS and Eben Moglen and the FSF, I transitioned into working towards making as much of my compute stack gpl-first, with compat licenses allowed but not preferred, and later, gplv3+ preferred.
What I found was that I started gravitating to tools that were often built in GNU-land tools that had been ignored while chasing the latest thing. Emacs probably being the largest game changer for this. But often third party tools written in gpl tend to remember and adopt the unix philosophy of doing one thing and doing it well, and are still a part of my userland.
Truly, there is much more behind the oft told joke, GNU is my operating system, Linux is just my (current) kernel.
Linux complexity hasnt skyrocketed that much, the available ecosystem around it core has. Thus, when keeping the core pure, I find gnu/linux just as easy to have a mental model of as freebsd. FreeBSD keeps to the unix philosophy by nature, hence the at a glance disparity.
If you can fully understand just the kernel, I think you have managed to achieve some sort of god-like transcendence. This is well above the abilities of us mere mortals. I don't even want to talk about understanding the whole system (maybe back in the 70s...)
I got started with BSDs just over 20 years ago when I needed to setup some servers and firewalls and the choice was between linux 2.2's ipchains or OpenBSD's pf. I was blown away by the simplicity of the firewall rules syntax for pf and then became enamoured with other niceties like the emphasis on security and correctness, the logical filesystem hierarchy, the simple licensing, the UNIX pedigree (sort of), the completely integrated build system for userspace and kernel, the fact that you had to actually turn services on rather than have several daemons running unnecessarily, and MAN pages that actually were useful and had examples and everything.
I'm still a big fan and have at least one of each major BSD variant running on one server or another just to keep up with developments across the space. So many innovations we take for granted come from the BSDs or were incubated there and they continue to innovate and refine the OSes in ways that I think more people should pay attention to.
Just a few of the things that we can thank BSDs for:
• The 'TCP/IP stack'
• OpenSSH
• OpenSMTPd
• OpenBGPd
• OpenNTPd
• LibreSSL
• privilege separation
• pf
• Darwin (The MacOS Kernel)
• The Ports system (pkgsrc in NetBSD and DragonflyBSD. Inspired Gentoo)
• A whole slew of security innovations : https://www.openbsd.org/innovations.html
• NetBSD can run your toaster: https://wiki.netbsd.org/ports/
• DragonflyBSD's HAMMER filestystem
• OpenBSD's Todd Miller also looks after development of sudo
My main desktop is Debian Stable. A few years ago I tried FreeBSD, but its desktop didn't work properly.
A couple of weeks ago I decided to try it again for an amd64 server and a Raspberry Pi (model 1), headless, without desktop.
The ports collection for the amd64 is extensive. Undoubtedly it is not is not as wide as Debian. FreeBSD had a binary port for Zig, which Debian doesn't have in any of its versions. The FreeBSD ports seem quite fresh, too.
The letdown for me is that the binary ports for the Pi 1 (which will also include the Pi 0) on FreeBSD was much more restricted compared to amd64. I don't want to get involved in compiling from source. I did try compiling Zig, and there seemed to be a problem with the version on llvm involved.
This means that for the Pi 1 I'm going back to Raspberry Pi OS.
FreeBSD vs Linux: they each have their pros and cons. A lot of the technical arguments on either side tend to be overblown. You pays your money and you takes your choice. But if you held a gun to my head and said I could only choose one, I'd choose Linux.
I'd say, though, that if you like Slackware, then you'll probably like FreeBSD more.
> I'd say, though, that if you like Slackware, then you'll probably like FreeBSD more
Hehe, someone saying this exact thing to me was what made look into BSD for the first time, and whoever said it to me was correct.
On the desktop/laptop, I prefer GNU/Linux, because the hardware support etc. is just much better. My home server runs FreeBSD, though, and it hasn't given me any trouble in almost seven years (other than a µSD card dying, but I don't think the OS is to blame here).
My experience with declarative set-up tools ranging from systemd to gradle to kubernetes is that they're amazing as long as you don't have any sort of problem.
If you do have a problem, you invariably find yourself in a byzantine hell maze where you are celebrating if you manage to find a cryptic error message (often you aren't even entitled to that). It can be incredibly nasty to debug as there is no actual code to step through, nothing to reason about. There is no where it went wrong.
I feel a lot of the points in the article boils down to "it's not what I'm used to". I mean, that's totally fine as an argument for not switching away if you already run FreeBSD, but not so much as an argument for switching to it.
A shell script _is_ a way of specifying what binary to run. It's just that it's standardised and relatively well thought-out, as opposed to one-off hacks, like with systemd.
Maybe if it was in Lua or Scheme. But Bourne shell script is a nasty messy language.
Pretty much the only thing about shell scripting that is useful and not easy to do in other languages is input/output redirection and piping. Service managers should take care of things like figuring out where stdout and stderr logs are sent to, so you shouldn't have to do that stuff in your service scripts.
Thus there is no benefit to shell compared to other languages / formats, and there are a lot of problems with shell scripting otherwise.
>Service managers should take care of things like figuring out where stdout and stderr logs are sent to, so you shouldn't have to do that stuff in your service scripts.
You don't have to. The fact that Linux had anachronisms like that wasn't because of shell scripts, it's an entirely orthogonal issue; a typical rc script in, say, FreeBSD, looks like this: https://github.com/freebsd/freebsd-src/blob/main/libexec/rc/.... It's declarative, it's easy to understand, but it also provides you with flexibility when you need it, as opposed to one-off hacks with custom, fixed functionality and random syntax.
You're justifying my point! There is no reason (other than historical) why this should be a Bourne-flavored shell script compared to any other scripting language. You could just as well write this in Lua or Scheme. Even the fact that there is runtime information embedded in the comments should be a big red flag that the wrong tool was chosen for this purpose.
Yes - except you can't really expect anyone to know Lua or Scheme, while you can assume every even remotely competent Unix/Linux system administrator or power user to know sh(1).
Possibly. But, FWIW, this was posted a few days ago and it was good at explaining the design decisions in NetBSD's rc system over earlier versions that FreeBSD uses as well (there are a few differences): https://news.ycombinator.com/item?id=31637755.
This is a big sticking point for me when evaluating other init systems / system service managers. There are a lot of weird and bad things about Systemd, but the declarative service file format is a big plus to me.
My only experience with FreeBSD is running a TrueNAS server, and there's some weird bug where once a month or so all the RAM (literally like 70 GB) gets eaten up by FreeBSD Laundry which crowds out the ZFS cache causing performance to tank and then never goes down again. I've not installed anything "weird", just running a few basic jails like FAMP.
I've taken to periodically running a task that allocates craploads of memory and lightly dirties it to force the OS to "collect" the laundry.
Googling it finds a random smattering of other people who have the same issue but no solutions.
So my take on FreeBSD is that it's pretty nice but without the larger user base of Linux it has more weird bugs that don't get teased out.
I have been toying again with FreeBSD after a 15 year absence for fun. The intent of the project was to document every experience I have with it, from setup, to packages installed (with shell scripts to cover setting it up) and then do things like catch errors. I installed and toyed with it on another laptop and just moved to my main personal laptop a few days ago.
Why FreeBSD though? I used it for two years in college, so it has a sentimental quality for me :) But also, I want to catch up when life took over (i.e. job, etc.) and understand more of my own and other biases about UNIX operating systems, particularly as I understood and now understand it. It is also a way to comfortably go through problems I encounter without mental commitments. For example, I have two issues now: the wireless doesn't load after resume sometimes and sometimes X crashes. It's ok it happens - the FreeBSD is not even setup for desktop use by default. Anything I learn here like this gets applied to work, even if it is on Linux systems. It's a form of freshening up my problem solving skills, something I miss sometimes from work.
BTW, vermaden's guides are great. I use his desktop configurations and they are filled with things to look into.
Is there a tool like multipass out there where I can boot and run a FreeBSD VM to try it out easily? Even if there were some bash script in the form of a Gist that curls an ISO and boots in in QEMU that would be fantastic.
It might (just barely) be an accurate description of (some) of the issues, but it is absolutely not "so true".
OSS is not a de-facto standard, and has many issues that led to us moving on from it back in the late 1990s.
It might offer you precisely what you want, but it does not solve all the problems, and in addition is still absolutely the wrong API to offer for application development. Hint: you don't use open/read/write/close to do video, and for some similar reasons and some different ones, it's the wrong model for audio too.
I've been doing audio development on Linux (and macOS and tangentially Windows) for more than 20 years. I wrote device drivers for pro-audio interfaces, application frameworks (JACK) and large applications (Ardour); I used to have to spend the closing part of the aughts and early part of the 2010's explaining to seriously misinformed people what all the problems with OSS were. That doesn't mean that there have not been issues with audio on Linux, but OSS (4 or otherwise) is not the answer to those problems and never was.
Why do you think ALSA was developed? Do you imagine that it was just a temporary whim of a developer somewhere "oh, I think I'll write a new driver stack for audio on linux"?
The issues are too many (and too old) for me to list them all, but the biggest of all was that OSS tries to do everything inside the kernel, which is (a) inefficient (b) prevents the use of floating point (the preferred sample format for mixing) (c) makes inserting processing elements within audio streams much more complex (and likely to be rejected because of Linus' practice of mechanism not policy). Even macOS, which originally implemented its audio mix engine in the kernel, gave up on this idea, and moved it into user space (coreaudiod).
OSS's API also made dealing with pro-audio interfaces quite difficult, because of channel layout. I can't recall if OSS4 fixed this, but OSS also did not offer mmap. When it comes to device control, you really not want to export thousands of OSS_IOCTL_FOOBAR constants to describe every control on every device, so ALSA made an attempt to create a parallel control API (parallel to the I/O API). This has been partially successful, but not entirely (note that on other platforms, there is frequently a dedicated device control app; more recently a few h/w makers have shifted to provide a web interface for device control)
>"oh, I think I'll write a new driver stack for audio on linux"
Linux is kind of famous for this approach. From what I've seen most problems with OSS were either problems with Linux implementation, and could be fixed without inventing a new proprietary API, or problems of OSS being too low-level, and thus could be fixed by providing a higher-level API on top of OSS (which userspace part of ALSA kind of is, but my question was about the kernel API). From what I can tell pretty much every single one you've mentioned above fits into those two categories - except device control, but I honestly have no idea what it is; can you give some real-life example?
> except device control, but I honestly have no idea what it is; can you give some real-life example?
You want to adjust the gain level used for capture. Or hardware gain control for playback. Or which input stream will be captured. Etc. etc.
By your apparent definition above, the kernel API doesn't matter, it is inward facing, and really just affects device drivers. Nobody cares, because within a couple of months ALSA had all the drivers OSS had, and then rapidly gained many more (partly it was much better structured for writing drivers than OSS was).
Even without an application framework like JACK though, it matters what the API presented to user space is, and ALSA made the deliberate choice to essentially completely hide the actual kernel interface and wrap it in libalsa. This allows for interposition (without using LD_PRELOAD) and very flexible configuration, all occuring in user space. Fun fact: "reading" audio data with ALSA is actually done with an ioctl() call!
Okay, gain. Also maybe bit width, and number of channels, and sampling rate, and maybe five other things. It's not "thousands"; there is a limited number of things one can adjust in DACs and ADCs.
>By your apparent definition above, the kernel API doesn't matter
Replacing a standard, portable API with a proprietary one doesn't matter to Linux - but it makes life harder for everyone else.
On an RME9652, there are 3136 gain controls on that single device alone.
On most Intel HDA-compatible chipsets (i.e. the builtin audio for just about every off-the-shelf motherboard in existence these days), there are between a dozen and 500 controls.
> Replacing a standard, portable API with a proprietary one doesn't matter to Linux
>On an RME9652, there are 3136 gain controls on that single device alone.
Not that I don't believe you, but quick googling shows this card doesn't have analog, so... what do those gain controls do?
>On most Intel HDA-compatible chipsets (i.e. the builtin audio for just about every off-the-shelf motherboard in existence these days), there are between a dozen and 500 controls.
Again, what for? I don't remember Windows or OSX showing 500 controls for internal sound card. More like five - two gains, two input/output dropdowns, left/right.
>I have no idea what this is supposed to mean.
OSS wasn't perfect, but was portable. ALSA is proprietary. Forcing it is no different from other vendors forcing their proprietary replacements for open solutions.
The device has a matrix mixer, so there's a gain level for (at least) every input to every output. More than that, however.
Yes, Windows and macOS won't show you those controls, and neither will Linux (for the most part). However, ALSA provides a standardized API to access them, and utilities like alsactl and amix can be used to set them in a device independent way.
You seem to be using the word "proprietary" in a very different way than most people in this world and on HN use it. ALSA in GPL'ed, part of the Linux kernel, and part of most typical Linux run-time environments, and has been worked on by hundreds of individuals. OSS4 was developed by 4Front Technologies, and they made money by developing non-GPL, non-open-source device drivers under contract. There are no such drivers within ALSA, and there have even been some attempts to port ALSA to other posix-y OS's, generally but not entirely limited to the user-space component.
OSS was not portable to anything except a few other Unix-y systems that also used OSS. That did not include Solaris or macOS/OSX, and at the time OSS was developed for Linux, it was not available for any of the *BSD systems (that came later). The only sense in which it was "portable" was that it provided /dev/dsp as did several other Unix-y systems, which is useful for doing party tricks on the command line, but very little else. ALSA still (or used to) provide that too, for back-compatibility with a tiny number of toy applications that used it.
No, but it is used for "serious audio" as in professional music and other media production and is Unix as in Apple went and paid Open Group to certify it as one. I thought this was fairly common knowledge and you'd be trying to refute one or other. But yes, a specific Unix system (macOS) is used for stuff that most people would consider serious audio, and OSS is not involved unless it's hidden somewhere under layers of Core Audio.
One thing that FreeBSD really was great at was setting up traffic shaping for a large network. I set up per-user shaping of all DSL users for a rural ISP in maybe a couple commands and it worked very reliably. Meanwhile in Linux I've tried several times to set up shaping, and anything more than just the most basic setup I've never really gotten working reliably.
> After a week or month many of these packages will get updates sometimes making this CentOS system unusable or even unbootable (recent GRUB Boothole problem for example).
Exaggerating a niche case doesn't do it any justice. I usually use Ubuntu but never had the system become unusable with package updates for 15 years.
People say FreeBSD is more integrated but never felt it brings any benefit from user's perspective. Tried to like FreeBSD by using it on a personal server on several occasions but I see no reason to use it anymore because it lacks Homebrew and Docker which is becoming more essential to make a comfortable environment with modern tools and apps.
The only better part is zfs integration but Ubuntu also has a very painless integration of zfs, I see no advantage at all.
> When using systemd(1) you never know how the services gonna start because it will be different each time.
What is this guy talking about?
Apparently the article is heavily biased only trying to make it look like FreeBSD is saner but apparently not.
> After a week or month many of these packages will get updates sometimes making this CentOS system unusable or even unbootable (recent GRUB Boothole problem for example).
I sometimes feel like some people live in an alternate dimension where everything is broken all the time. I can't remember a single time that a Linux system I use was rendered unbootable from a regular update. It happened once, when I was messing around with nonfree Nvidia drivers under OpenSUSE, which had (has?) poor support for such things.
I know it does happen to some people once in a while, but I feel like some people complain about it as if it happened to them constantly.
Somehow I think there is some irony, that although FreeBSD lost to GNU/Linux in installed based, there is a growing number of MIT/BSD/Apache OSes targeting the IoT space like Azure RTOS, NuttX, Zephyr, Mbed.
And bare metal runtimes like Arduino and ESP-IDF.
Kind of proving the point GNU/Linux partnership was a lucky one.
BSD also somehow lost the embedded and appliance market where GNU is nowhere to be found. (Yes, we all know of the two or three exceptions like PlayStation and a couple of NAS vendors, which just proves the point.); that is harder for me to understand. Is the driver support and more widespread knowledge of the Linux kernel to blame for that?
Most likely, Android kind of proves the point that OEMs can do whatever they feel like without complying with GPL requirements, and hardly it matter to their bottom line.
Still, that increase in alternative OSes seem to be triggered by not wanting to deal with Linux despite of that.
I guess the only advantage of FreeBSD is that it's got a permissive license for them to not open up the modification sources which can be a primary concern for corporates.
I always want to love FreeBSD, it's the first Unix system I used with any regularity many years ago. Every few years I get some inspiration to load it up and play. Without fail every time I have tried I've run into some problem with hardware support. From it just refusing to boot on an Opteron server to networking just not working on a mini PC. Ubuntu on those same machines had zero problems.
So it doesn't matter what FreeBSD can offer if I can't run it on the hardware I have available. If I'm stuck running it in a VM why would I bother with it?
The reason FreeBSD is not my daily driver is 1) limited video card support, and 2) limited steam/proton support. In other words, I game on my desktop machine, and play Windows games under Steam in Linux.
I have moved to using FreeBSD for my servers though, and am happy with it for the most part.
The problem with lists like this is that any possibly convincing feature tends to get copied after a while.
For instance, jails are nice -> docker, podman,... exist. Might be better or worse for your use case, but similar enough that it is not worth switching for.
Or ZFS is nice -> ZFS is still nice and also available on linux. Btrfs also exists.
Boot environments are nice -> Snapper does this and more and things like NixOS or Fedora Silverblue go much further still.
Popular package is in the repos of ... -> It is in any OS's repo.
Kdeconnect offers nice integration of your phones, tablets and pcs -> Apple copies it, MS copies it; gsconnect, mconnect....
Combine that with the fact that switching always involves some uncomfortable adjustment and any "killer feature" becomes -> Eh, now I will have to wait a bit until it is available on the OS I am comfortable with.
Yes, FreeBSD these days does not really have any unique selling point. Anything you can do on FreeBSD, you can do on Linux. But you can also do them on FreeBSD, and usually do them well.
But having some variety is good thing in itself, IMHO. I recall some major DNS company making a point of always running a mixture of various hardware/OS platforms to ensure that a problem with a particular configuration would not take down the entire site. (This is a bigger issue, too - on the server and desktop, you basically have the choice between Windows and some variant of Unix[0]. There are a few alternatives on the server, OS/400, OpenVMS, z/OS, etc., but those are pretty niche.)
FreeBSD definitely has things to offer compared to other operating systems, but I'd also argue that the reverse is true in many cases.
Linux, generally speaking, has a much nicer upgrade story. FreeBSD's works, but having to reboot and run freebsd-update multiple times during a major upgrade is annoying.
FreeBSD's init system works and is generally fine, but I much prefer the simplicity of systemd unit files over FreeBSD's rc scripts. The common use-case of "Run $X as user $Y, capture it's output, restart it if it dies, and track it's PID" is incredibly easy to do in a systemd unit file. FreeBSD could learn a lot here[0].
Related to the upgrade story, packaging is interesting in FreeBSD. The base system is just "there" and managed by freebsd-update, but 3rd party software is installed via packages (ports build a package then install it). The separation of base (/, /usr, etc) vs 3rd party (/usr/local) is good, but it would be nice if all of the software was managed the same way. FreeBSD has started work on this[1], but I have no idea if it's actually going anywhere.
[0] https://papers.freebsd.org/2018/bsdcan/rice-the_tragedy_of_s...
[1] https://wiki.freebsd.org/PkgBase