
Linux VS open source UNIX - rodrigo975
https://www.adminbyaccident.com/politics/linux-vs-open-source-unix/
======
elagost
This weekend I started digging into OpenBSD. I'd never used a BSD - been a
Linux user for the past decade. While the table linked might show OpenBSD as
the "least complete", what seems to be the case is that they pick one tool to
fit a use case and then use that one. There aren't 400 different shells
installed by default or 5 different process monitoring/inspection programs,
because they have the one they like and use/improve upon it.

OpenBSD is a fascinating operating system. I'm only a few chapters into
Absolute OpenBSD
([https://en.wikipedia.org/wiki/Absolute_OpenBSD](https://en.wikipedia.org/wiki/Absolute_OpenBSD))
by Michael W. Lucas, but from a Linux user/admin perspective it is
enthralling. I can't wait to learn more about it.

~~~
Enginerrrd
The systemd debacle is what led me down a rabbit hole toward the BSD's. Don't
get me wrong, systemd actually adds a lot of needed functionality, but I
really feel like it is a major philosophical branch away from the conventional
Unix thinking of 'make a tool that does one thing really well'.

That mindset has such a strength in that such tools form reliable building
blocks for other tools and system components in a way that is really
approachable for amateur/volunteer developers. It takes no time to parse
through the man page of a simple tool. And only a bit longer to parse the
code. That makes it easy to build improvements, or build on top of it.

But trying to wrap your head around systemd in even a few hours isn't
reasonable. And binary log files? Wtf. It also seems like relying on certain
aspects of it's behavior is a good way to end up breaking your system.

BSD still has that old school Unix mindset that made Linux great in the first
place. Especially up against Microsoft's products.

The proof in the pudding for me is to look at the running processes of a
default system between BSD and Linux with systemd. Yikes.

~~~
dreich
> The systemd debacle is what led me down a rabbit hole toward the BSD's.

Like most, you could have simply moved to a distribution without systemd.
Unlike Linux, the BSDs offer less choice when it comes to both init, service
supervision and service management options. It is also evidenced in the
comparison table in the OP. If anything the _debacle_ resulted in creating
more awareness and leaving people open to more choice.

That said, adopting one monolith instead of another sounds more like a knee
jerk reaction than anything else.

> The proof in the pudding for me is to look at the running processes of a
> default system between BSD and Linux with systemd. Yikes.

This only scratches the surface. Daemons running under systemd have their PIDs
supervised instead of using unreliable hacks like pidfiles. This is one of the
reasons why systemd is preferred in large deployments and professional
environments.

~~~
jimktrains2
BSDs aren't a "monolith", but the system and tools are developed together and
parts can be replaced wholesale if you choose to do so.

Also, there's what, Gentoo and GUIX that don't use systemd? Gentoo still
prefers building all source on the system which is a non-starter for most, and
GUIX I didn't think was ready for a daily-driver role yet.

~~~
xouse
[https://nosystemd.org/](https://nosystemd.org/)

The most popular non-systemd distro I hear about is Void linux, which is a
rolling release style distro that's pretty comparable to(though not based on)
Arch.

As a tangent because you brought up distro's and difficulty, I know Arch has a
reputation with some as being too difficult for regular skilled users, but as
a regular skill level user myself, I find that the Arch/Void style rolling
release paradigm of doing stuff makes things easier for noobs like me, not
harder.

Once you get past the initial hurdle that is the first hour or two of install
and setup(which you can do just by copying youtube tutorial instructions line
by line) then everything after that is much simpler.

For me, I find that the majority of everyday linux problems all boil down to
trying to install or update some kind of software. Either software you already
have has a bugfix or feature you want in the newest update, or you have some
new software you want to install. And because developers like new shiny
things, often times the newest version of whatever has a dependency of some
other new shiny thing.

Installing new software in a fixed release distro often quickly gets too hairy
for me, but in Arch I can almost always a simple install directly from the
main or user repositories. This has so far eliminated 95% of everyday problems
for me defying the usual narrative I hear of it being "harder" to use for
normal Joe's like me.

~~~
AnIdiotOnTheNet
> For me, I find that the majority of everyday linux problems all boil down to
> trying to install or update some kind of software. Either software you
> already have has a bugfix or feature you want in the newest update, or you
> have some new software you want to install.

And yet the Linux Desktop community insists on sticking with the package
manager/repo model that makes stuff like this such a pain. Worse, it's
actively hostile to the concept of portable applications in general.

------
jonfw
This guy has a real knack for complaining about an issue, and than admitting
it was actually fixed a while ago.

Complains about a certain guy's benchmarks being affected by using different
compilers, but of course that guy switched to using the same compilers already

Than he does the same thing with epoll- complaining about something being
broken, but then admits it was fixed in 2016

I wasn't really able to pull anything material out of this article. I guess
this is why people like benchmarks- it's hard to write an opinion piece about
performance.

------
Mathnerd314
IIRC the "features" that Linux has over the _BSDs are usually just referring
to driver support and ported software. Since drivers are part of the kernel,
BSD licensed drivers can be easily ported from a_ BSD to Linux, but Linux
drivers are GPL and have to be rewritten for use in a *BSD.

Also FreeBSD usage is smaller so there is not as much effort to get software
working on it, like Steam or obscure/specialized software. In practice Linux
packaging efforts are fragmented among distros so the gap is not huge, but
it's still present.

------
ti_ranger
What is the situation for "reproduce a currently-installed system from a list
of packages (including version/release if relevant) and a tarball/git
checkout/package-deployment/puppet run etc. of configs"?

As far as I know, on most BSDs, unless you happen to have a complete source
tree snapshot for said system (becoming more difficult to maintain if you
build multiple systems without special tricks to retain binary artifacts),
you're out of luck, you'll get today's STABLE or RELEASE, not the one from 17
days ago when your current production box was built that works perfectly
unlike the one today that is broken.

This is trivial to accomplish on all Linux distros.

(I would say this kind of issue should be listed in the table in the article).

~~~
dijit
Which BSD?

the "preferred" way to do this in a datacenter context with FreeBSD is to run
a repo yourself with poudriere; this has the downside of causing you to build
all your dependencies (via ports), but the upside of having everything built
with your exact specifications in mind and in a way which ensures that they
are rolled out in the way you prefer and that they are consistent amongt all
instances.

For "old school sysadmins" who like controlling the versions of things in a
very well defined way and running their own repositories it is absolutely
ideal.

However, it affects developer velocity of course.

------
joosters
The author is pretty inconsistent here. They make good points when mentioning
all the problems with benchmarking and how it's a bad idea to fixate on a
specific, narrow problem - but then, go on to complain about specific, narrow
problems, using them to build a narrative about how linux/whatever is flawed.

A specific example: the part about how epoll() is broken because of its
design, and how it causes 'thundering herd' issues when using multiple
threads/processes. I had plenty of experience with epoll from over ten years
ago, and it wasn't a problem even back then. Multiple processes listening on
the same socket did _not_ all wake up when a new connection came in. Sure, why
not bring up specific issues with Apache, but there are plenty of other web
servers that work very well (nginx, etc) and have existed for over a decade.

~~~
rachelbythebay
gunicorn (Python, in case you’re lucky enough to not have run across it) forks
after creating listener socket(s). Every child does the epoll thing. When
awakened, they all call accept4 and then all but one gets -1.

This happens right now and “powers” a stupid amount of the economy. And it’s
wasteful.

~~~
joosters
Our old mechanism was a parent process that created the listen sockets, and
then sent the FDs to the previously-created child processes. (The children
would be registering their FDs with epoll and then calling accept()
themselves) That never seemed to trigger the problem.

------
unwind
Meta/mods: please shorten the title, to remove the needless duplication of the
site's name. Thanks.

------
upofadown
>Linux receives much more investment from companies and therefore more paid
developers are in it, plus BSD’s feature parity with that of Linux doesn’t
hold.

I would say that is actually true ... and is the root cause of the complexity
crisis Linux is experiencing these days. There is a strong financial incentive
to add things but no financial incentive to take things out. Every time you
add a feature to a complex system you take something away from everything
else.

------
als0
Not sure why Linux gets ‘Partial’ in Container Security whereas FreeBSD gets a
‘Yes’. Both provide mechanisms that can equally be misconfigured.

------
johnisgood
How come OpenBSD has no containers other than _chroot_?

Is there anything similar to _firejail_ [1] for OpenBSD?

[1] Firejail is an easy to use SUID sandbox program that reduces the risk of
security breaches by restricting the running environment of untrusted
applications using Linux namespaces, seccomp-bpf and Linux capabilities.

------
qplex
It would be fair to mention that Linux actually includes two other schedulers
in addition to CFQ: Deadline and Kyber.

Firewalls: Linux, and no mention of bpfilter?

~~~
darkwater
It's clear that he's biased, trying to prove to the world that *BSD is better
than Linux, Linux should not had the success it had etc. I remember the same
people, 20 years ago too. They are probably the only type of geek worse then
the typical Linux fanboy saying that Windows is bad.

------
dvfjsdhgfv
Linux supports eBPF since 3.18.

~~~
helmettoday
right

------
helmettoday
I like Linux. But what about Unix?

