I can’t really speak for the other operating systems, but I don’t feel the illumos column is terribly well researched. I don’t know why our UFS is listed as “read only”. UFS was what people used before ZFS came on the scene in Solaris 10; our UFS is definitely read-write.
Event ports is certainly our preferred event notification system, but we also have select(3C), poll(2), poll(7D) aka /dev/poll, and epoll(5).
For network high availability if Linux can use ucarp I’m pretty sure we can too. We also have a native VRRP implementation rattling around in there somewhere, as I recall.
At any rate, I use and work on illumos because I think it has a lot going for it. I recognise that not everybody shares that perspective, but that’s OK – we don’t all have to like the same things. I don’t really understand what this article is even about.
I don’t really understand what this article is even about.
I do: tribalism. Our tribe good, other tribe bad. From an outsider perspective both tribes don’t look all that different but that only serves to reinforce this type of behaviour where adherents of one tribe try to find something, anything to mark their tribe as being different, nay, better than the others. This leads to silly claims like ‘native ZFS’, forgetting that FreeBSD ZFS is in the process of being re-based on ZoL (ZFS on Linux) [1].
I also thought the article was a bit misleading. For example, it includes pledge as a “security framework” on the same level of SELinux or AppArmor, even though they work in fundamentally different ways (Pledge is opt-in for each application). It also lists iptables as the only firewall option under linux, even though iptables is just one frontend for the actual firewall netfilter, and makes no mention of firewalld. It remarks about docker under the containers section, but no mention of cgroups. To stoke even more controversy, it lists systemd as the only possible method for services control on linux. Under event notification syscall it mentions epoll but not its ancestors poll or select, which still work as far as I know. Finally, if ZFS is supported on linux, why is “Native ZFS” relevant at all?
It remarks about docker under the containers section, but no mention of cgroups.
Also:
Linux has been late to many things, such as containers, or copy on write file systems. Container-like tehcnologies were developed back in the year 2000 on FreeBSD Jails, and later extended to Zones in Solaris.
On Linux: Virtuozzo - 2000, Linux VServer - 2001, OpenVZ 2005. (Of course, the idea of containers precedes work in Linux and BSD by decades.)
Moreover, they are just cherry picking here. There are other technologies where Linux was definitely first. E.g. kernel-based hypervisors KVM (Linux) - 2006 (mainlained in 2007), bhyve - introduced in FreeBSD 10.0, 2014.
(This is not a pro-Linux post, just pointing out that this article is incorrect in many places, and cherry-picks to make specific systems look worse.)
kernel-based hypervisors KVM (Linux) - 2006 (mainlained in 2007)
Or VM/370 made in the 1970’s with some open-source releases. Helped kernel developers with debugging, too. Still around.
Coincidentally, the high-security prototype was called KVM/370 for Kernalized [with a security kernel] VM/370. Here’s an old paper (pdf) on that one for anyone following that stuff. That puts securing hypervisors as early as 1978.
Well, it’s nice to see that marketroids aren’t the only ones who dream up feature comparison charts.
A couple of notes.
The article goes into great detail about how epoll is busted (it no longer is) and how kqueue is much better but doesn’t mention that you can run kqueue on Linux just fine. Most software won’t use it, but it’s available.
Package availability. Umm, why is package availability “latest” somehow a differentiator. sure, if you’re using an ancient Linux distro, you may not be able get the latest php from your vendor, but same goes if you’re running an older version of FreeBSD, and you can always grab the source and build it yourself on both platforms. Bonus round: most times you can find newer versions of packages for older distros compiled by the vendors, but not for *BSD. Bonus Round 2: A lot of propietary software is built for Linux, but very little is built for *BSD.
License: Viral (HAHAHAHA!) I thought we were over the whole “GPL is a cancer” thing a long time ago, but apparently not. The reason that Linux has so many features is because companies are forced to distribute the changes, and encouraged to feed them back into the kernel. Sure, there may be some rock-solid FreeBSD appliances out there, but you have no idea what changes they’ve made to the kernel or userspace, and any of the appliances I’ve tried have been … flaky, to put it mildly.
Desktops: Can you run a desktop on *BSD? Yes. Are you a masochist for doing so? Also yes. This is the best “feature” on the comparison chart for sure. Most propietary feature comparison chart have a feature that is technically true, in that most *BSDs have a desktop, of sorts, but also bullshit, in that actually using that feature might be a little bit better than pulling your fingernails out.
Now, don’t get me wrong. I like FreeBSD, in certain situations, but this article is about the worst rationale I can think of for actually running FreeBSD.
There are sure lots of FreeBSD-based appliances out there. But if you look at https://www.freebsdfoundation.org/donors/#year2018, Juniper (whose JunOS is FreeBSD-based) donated as much as a single not very big router sells for. In 2019, Adobe donated as much as Ask Hansen (the ntp.org coordinator who arguably shouldn’t feel compelled to donate anything to anyone). It’s pretty depressing.
Anyway, I like FreeBSD despite the dubious marketing efforts of some of its adherents and their attitude towards strong copyleft, and I always make sure my programs build and work on it, even though my main OS is GNU/Linux.
License: Viral (HAHAHAHA!) I thought we were over the whole “GPL is a cancer” thing a long time ago, but apparently not.
People may have ideologies and intentionally choose “inferior” software to avoid copyleft licenses, even if my choice of OS and compiler and whatnot doesn’t affect the software I produce. I’m one such person.
Also, it is weird (also in this respect) to summarize all of Linux in one column and/or using such narrow features. E.g., NixOS, Guix, and Fedora may not have boot environments, but they also do not need them. Since they do not use imperative, mutable package management, you do not need filesystem snapshots to persist older system versions, atomic upgrades/rollbacks are core to their system design.
tl;dr you can always pick the rows/columns such that the feature table looks beneficial to your system.
20 years ago the company I worked for sponsored a space for open source projects at, IIRC, a USENIX LISA event. One of the booths we sponsored was NetBSD, and I recall one of the NetBSD folks talking my ear off about how Linux was going to be beaten by the BSDs because its support for various things, like IDE, was “inelegant,” and so on and so forth.
20 years later, here we are. The BSDs still exist and still have fans, but the world quite literally runs on Linux. Yeah, it still has a lot of flaws. So does macOS, Windows, and any other OS you’ll look at.
I may be wrong, but I believe the reciprocal - “viral” for the haters - license is in part what has helped Linux. Companies using BSD have no forcing function to collaborate or share innovations. So, in many cases, they haven’t. And Linux is frequently “good enough” and mainstream enough to maintain its popularity.
The author feels that the discussion should center on “compilers, file systems, IPC, schedulers” and other “relevant” parts of the operating system. Which brings me full circle to the NetBSD dude who thought Linux was going to “lose” to the BSDs because subsystems weren’t as “elegant.”
Most people aggressively do not care. They just want the damn thing to work. Whether the damn thing is their desktop or a server or (these days) the host OS that sits under Kubernetes and runs containers. And a substantial chunk of the world has put its money and time into Linux to do these things. Even when your favorite open source UNIX is comparable or better than Linux at this or that, is it so much better that it’s worth the costs of switching? Usually not.
This is why Linux never took off substantially on the desktop, even though I could argue it logically should. But, through Android, it dominates phones. It dominates the cloud, and the top 500 supercomputers, and is all over embedded devices. Because it was better, for some value of “better” to the folks who made those decisions.
If the BSDs are going to dominate anything, they’d do well to pioneer some aspect of computing that nothing else has cornered yet. I don’t know what that is, TBH, or I’d be looking for funding. But it’s not going to displace Linux in any of these areas because whatever advantages it currently has, it doesn’t offer enough incentive over Linux for people to switch and suffer the costs.
One of the reasons I moved from Linux (Slackware/Gentoo/Ubuntu) was very poor and broken audio on Linux.
For example I could (and run) FreeBSD desktop for months. Only power outage (no UPS) could break it.
When I tried to use Ubuntu Linux (also with PulseAudio) the sound got stuck after about 1-2 days of usage and only hard reset/reboot solved the problem. Not to mention sometimes broken system after updates.
Linux always had ALSA + on OSS channel + PulseAudio as a workaround for its broken architecture.
FreeBSD has modified/improved in-house OSSv4 with up to 256 channels mixed live in kernel, but hey, its another year of Linux on the Desktop …
A bit offtopic, but what is a good/recommended illumos distribution these days?
I played around with smartos at one point – it seemed ok, but the docs were a bit sparse at the time.
Later, I was going to try out omnios, but I vaguely recall omniti effectively dropping it or something after a while?
Is openindiana still where it’s at these days?
EDIT: oh. Seems like maybe omnios is still a thing. neat!
Parts of the article is borderline incomprehensible, to me:
But why having alternatives they do get so ‘poor reputation’ and ‘marginal’ market share. Because humans love to win and they always bet to the winning horse. Betting otherswise is too risky, even if the reward may be is greater. The question now here is: who decides what are the relevant aspects to win this ‘race’. Maybe the ‘press’ might have something to do with this.
I like that it highlights how capable FreeBSD is, though.
I can’t really speak for the other operating systems, but I don’t feel the illumos column is terribly well researched. I don’t know why our UFS is listed as “read only”. UFS was what people used before ZFS came on the scene in Solaris 10; our UFS is definitely read-write.
Event ports is certainly our preferred event notification system, but we also have select(3C), poll(2), poll(7D) aka
/dev/poll, and epoll(5).For network high availability if Linux can use
ucarpI’m pretty sure we can too. We also have a native VRRP implementation rattling around in there somewhere, as I recall.At any rate, I use and work on illumos because I think it has a lot going for it. I recognise that not everybody shares that perspective, but that’s OK – we don’t all have to like the same things. I don’t really understand what this article is even about.
I do: tribalism. Our tribe good, other tribe bad. From an outsider perspective both tribes don’t look all that different but that only serves to reinforce this type of behaviour where adherents of one tribe try to find something, anything to mark their tribe as being different, nay, better than the others. This leads to silly claims like ‘native ZFS’, forgetting that FreeBSD ZFS is in the process of being re-based on ZoL (ZFS on Linux) [1].
[1] https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072422.html
I also thought the article was a bit misleading. For example, it includes pledge as a “security framework” on the same level of SELinux or AppArmor, even though they work in fundamentally different ways (Pledge is opt-in for each application). It also lists iptables as the only firewall option under linux, even though iptables is just one frontend for the actual firewall netfilter, and makes no mention of firewalld. It remarks about docker under the containers section, but no mention of cgroups. To stoke even more controversy, it lists systemd as the only possible method for services control on linux. Under event notification syscall it mentions epoll but not its ancestors poll or select, which still work as far as I know. Finally, if ZFS is supported on linux, why is “Native ZFS” relevant at all?
Also:
Linux has been late to many things, such as containers, or copy on write file systems. Container-like tehcnologies were developed back in the year 2000 on FreeBSD Jails, and later extended to Zones in Solaris.
On Linux: Virtuozzo - 2000, Linux VServer - 2001, OpenVZ 2005. (Of course, the idea of containers precedes work in Linux and BSD by decades.)
Moreover, they are just cherry picking here. There are other technologies where Linux was definitely first. E.g. kernel-based hypervisors KVM (Linux) - 2006 (mainlained in 2007), bhyve - introduced in FreeBSD 10.0, 2014.
(This is not a pro-Linux post, just pointing out that this article is incorrect in many places, and cherry-picks to make specific systems look worse.)
Or VM/370 made in the 1970’s with some open-source releases. Helped kernel developers with debugging, too. Still around.
Coincidentally, the high-security prototype was called KVM/370 for Kernalized [with a security kernel] VM/370. Here’s an old paper (pdf) on that one for anyone following that stuff. That puts securing hypervisors as early as 1978.
Poll and select work just fine. Why wouldn’t they? :)
Well, it’s nice to see that marketroids aren’t the only ones who dream up feature comparison charts.
A couple of notes.
The article goes into great detail about how epoll is busted (it no longer is) and how kqueue is much better but doesn’t mention that you can run kqueue on Linux just fine. Most software won’t use it, but it’s available.
Package availability. Umm, why is package availability “latest” somehow a differentiator. sure, if you’re using an ancient Linux distro, you may not be able get the latest php from your vendor, but same goes if you’re running an older version of FreeBSD, and you can always grab the source and build it yourself on both platforms. Bonus round: most times you can find newer versions of packages for older distros compiled by the vendors, but not for *BSD. Bonus Round 2: A lot of propietary software is built for Linux, but very little is built for *BSD.
License: Viral (HAHAHAHA!) I thought we were over the whole “GPL is a cancer” thing a long time ago, but apparently not. The reason that Linux has so many features is because companies are forced to distribute the changes, and encouraged to feed them back into the kernel. Sure, there may be some rock-solid FreeBSD appliances out there, but you have no idea what changes they’ve made to the kernel or userspace, and any of the appliances I’ve tried have been … flaky, to put it mildly.
Desktops: Can you run a desktop on *BSD? Yes. Are you a masochist for doing so? Also yes. This is the best “feature” on the comparison chart for sure. Most propietary feature comparison chart have a feature that is technically true, in that most *BSDs have a desktop, of sorts, but also bullshit, in that actually using that feature might be a little bit better than pulling your fingernails out.
Now, don’t get me wrong. I like FreeBSD, in certain situations, but this article is about the worst rationale I can think of for actually running FreeBSD.
There are sure lots of FreeBSD-based appliances out there. But if you look at https://www.freebsdfoundation.org/donors/#year2018, Juniper (whose JunOS is FreeBSD-based) donated as much as a single not very big router sells for. In 2019, Adobe donated as much as Ask Hansen (the ntp.org coordinator who arguably shouldn’t feel compelled to donate anything to anyone). It’s pretty depressing.
Anyway, I like FreeBSD despite the dubious marketing efforts of some of its adherents and their attitude towards strong copyleft, and I always make sure my programs build and work on it, even though my main OS is GNU/Linux.
People may have ideologies and intentionally choose “inferior” software to avoid copyleft licenses, even if my choice of OS and compiler and whatnot doesn’t affect the software I produce. I’m one such person.
I’m wondering where the author researched his opinions, I don’t see how boot environments are not supported on Linux.
First of all they are essentially just a function of set of ZFS clones, so if ZFS is supported, so are boot environments.
Second of all there are boot environment managers on Linux - zedenv (disclaimer I am the author) - being one of them.
Also, it is weird (also in this respect) to summarize all of Linux in one column and/or using such narrow features. E.g., NixOS, Guix, and Fedora may not have boot environments, but they also do not need them. Since they do not use imperative, mutable package management, you do not need filesystem snapshots to persist older system versions, atomic upgrades/rollbacks are core to their system design.
tl;dr you can always pick the rows/columns such that the feature table looks beneficial to your system.
20 years ago the company I worked for sponsored a space for open source projects at, IIRC, a USENIX LISA event. One of the booths we sponsored was NetBSD, and I recall one of the NetBSD folks talking my ear off about how Linux was going to be beaten by the BSDs because its support for various things, like IDE, was “inelegant,” and so on and so forth.
20 years later, here we are. The BSDs still exist and still have fans, but the world quite literally runs on Linux. Yeah, it still has a lot of flaws. So does macOS, Windows, and any other OS you’ll look at.
I may be wrong, but I believe the reciprocal - “viral” for the haters - license is in part what has helped Linux. Companies using BSD have no forcing function to collaborate or share innovations. So, in many cases, they haven’t. And Linux is frequently “good enough” and mainstream enough to maintain its popularity.
The author feels that the discussion should center on “compilers, file systems, IPC, schedulers” and other “relevant” parts of the operating system. Which brings me full circle to the NetBSD dude who thought Linux was going to “lose” to the BSDs because subsystems weren’t as “elegant.”
Most people aggressively do not care. They just want the damn thing to work. Whether the damn thing is their desktop or a server or (these days) the host OS that sits under Kubernetes and runs containers. And a substantial chunk of the world has put its money and time into Linux to do these things. Even when your favorite open source UNIX is comparable or better than Linux at this or that, is it so much better that it’s worth the costs of switching? Usually not.
This is why Linux never took off substantially on the desktop, even though I could argue it logically should. But, through Android, it dominates phones. It dominates the cloud, and the top 500 supercomputers, and is all over embedded devices. Because it was better, for some value of “better” to the folks who made those decisions.
If the BSDs are going to dominate anything, they’d do well to pioneer some aspect of computing that nothing else has cornered yet. I don’t know what that is, TBH, or I’d be looking for funding. But it’s not going to displace Linux in any of these areas because whatever advantages it currently has, it doesn’t offer enough incentive over Linux for people to switch and suffer the costs.
One of the reasons I moved from Linux (Slackware/Gentoo/Ubuntu) was very poor and broken audio on Linux.
For example I could (and run) FreeBSD desktop for months. Only power outage (no UPS) could break it.
When I tried to use Ubuntu Linux (also with PulseAudio) the sound got stuck after about 1-2 days of usage and only hard reset/reboot solved the problem. Not to mention sometimes broken system after updates.
Linux always had ALSA + on OSS channel + PulseAudio as a workaround for its broken architecture.
FreeBSD has modified/improved in-house OSSv4 with up to 256 channels mixed live in kernel, but hey, its another year of Linux on the Desktop …
I’m surprised that you didn’t mention Jack, which is used for anything resembling “pro audio” on Linux.
[Comment removed by author]
Do the BSDs and Solaris forks have integrated virtualization like KVM? I quite like having multiple layers of containment to choose from.
All the BSD’s have it: on FreeBSD it’s Bhyve, on Open and NetBSD it’s something else. Bhyve is also on macOS(as Xhyve).
Both KVM and Bhyve have been ported to illumos.
A bit offtopic, but what is a good/recommended illumos distribution these days?
I played around with smartos at one point – it seemed ok, but the docs were a bit sparse at the time. Later, I was going to try out omnios, but I vaguely recall omniti effectively dropping it or something after a while?
Is openindiana still where it’s at these days?
EDIT: oh. Seems like maybe omnios is still a thing. neat!
Parts of the article is borderline incomprehensible, to me:
I like that it highlights how capable FreeBSD is, though.