Life long Gentoo user here. The fact that NixOS other other new fangled package management systems are rarely mentioned in the same context as Gentoo has led me to wonder whether the new kids on the block have done their homework.
I realize that Gentoo became a meme at some point, but it also seems that it might have transcended to the level of infrastructure. Thus, you rarely ever heard about it for the same reason you don't hear people talk about hammers -- it is doing its job running tens (hundreds?) of millions of chrome books among other things.
No flare, nothing fancy, it has solved a whole bunch of packaging, deployment, and environment control problems and gotten out of the way of its users (mostly ... chuckle), and it did it all with a pile of bash scripts and a little python here and there. Want to use systemd because you have a use case that would benefit from it? Go right ahead! The engineering work is done, no need for fights on the mailing list. Don't want to use systemd? `eudev` to the rescue! There are sound engineering reasons for not using systemd while also wanting to use some other (seemingly) completely unrelated piece of software that just happens to have a dependency on the kitchen sink.
Despite being a rolling release distribution, I find that the UX and workflows are more stable over long periods of time than any of the more popular LTS style distros. When I started fiddling with Ubuntu so that I could help my colleagues debug issues it took me an embarrassingly long time to realize that there isn't really such a thing as Ubuntu, just 14.04, 16.04, 18.04, etc. Each is some different form the other that stack overflow questions from one LTS are often simply wrong for another.
Writing this I wonder whether rolling release distros aren't effectively the original form of chaos engineering -- if everything is going to be changing all the time then it forces the developers to solve a different and perhaps more fundamental set of problems and ultimately leads to greater stability in the long run.
There are many. Most amount to complaints about sysadmins having to re-learn a lot of stuff, much of which didn't actually need to be changed, at least not so thoroughly. Early on, most of the complaints centered around the poor migration path, the abandonment of plain text log files, and the absurdity of high-level user-facing software like the Gnome desktop environment having a hard dependency on a particular init system that many felt was still kinda half-baked. systemd as a project has also been a poster child for feature creep, and while technically many of the new features that have been added over the years are optional, in practice few distributions make it easy to partially opt-out of new systemd stuff. And through all of the controversy, the systemd maintainers have shown a stunning inability to acquire diplomacy skills; systemd has succeeded more in spite of their ability to promote it, rather than because of it.
Starting this off with a disclaimer that these are things I've heard or read, and aren't necessarily a statement of my views.
The controversy mainly surrounds the claim that it is a single package that tries to do way too much by itself.
Calling systemd an init system isn't correct. systemd contains many things, one of which is an init system.
The other claim is that the systemd developers aren't open to much outside opinion, but have power over the community because important parts of basically all desktop Linux systems are now part of systemd and have strong dependencies on it (such as udev).
The latest round of controversy is probably because They're pushing the new 'homed' component, which is supposed to change up how home directories (and user accounts) are managed.
It's supposed to enable easier encryption of home directories, but breaks ssh logins.
Therefore it's probably only suitable for multi-user systems (which need to protect home directoried from other users) that are also never accessed remotely - a subset consisting of approximately 0 systems.
Mostly that it WAY more complicated than it needs to be, and it often replaces well written and tested tools with VERY poor implementations.
Things like NTP, syslog, DHCPd, cron, iptables, mount, automount, handling /tmp, /dev, DNS, su/sudo, etc.
Letting the init system talk to the network before userspace has the ability to setup firewalls gives me the heebie jeebies.
Often the implementations of systemd don't handle failures well, leave off critical features like encryption, DNSSEC, etc. They are often hard to debug, and generally worse than the features they replace.
Not that Linux didn't need a nice init system, but that systemd is trying to take over everything. The lastest volley on that front is taking over management of /home with homed, but in a way that's incompatible with ssh.
Do you really want to depend on systemd's homed for managing /home? I'd rather not.
Part of it is that it is a more or less monolithic package that started as an init system and now does more than some people would like.
This results in certain packages switching to require systemd modules(gnome & udev) and essentially locking systems without systemd out of using said software. Communities supporting non-systemd init systems now have to maintain forks of these modules so that they can keep these packages supported on their distros.
The other issue, which is the issue I care more about is that it does these things in a way that breaks compatibility with existing workflows and exposes it to a number of different issues due to its increased complexity.
Don't get me wrong, systemd is excellent in many ways but like many others, I am not a fan of it overall and choose not to use it where possible.
An example of something very controversal about systemd: journald.
journald is a replacement for the system journaling daemon and is a generally very good journaling daemon. It is in many ways more performant than other journaling daemons and can be easier to use as well. The issues however come largely from the fact that it uses a binary log format. This breaks the ability for other tools access logs nearly as easily unless explicit support for the interaction is added by either journald or the tool in question.
Now when I launch my desktop I have to login in tty console first, start tmux, detach it, logout from tty, then login into desktop session normally. Otherwise logout from desktop session will hang and logging in again will fail.
The issue with systemd is that it is developed in a similar way to traditional UNIX systems like Solaris, BSD etc.: the low-level user-space parts of the OS are developed as a single project with a coherent design vision, common configuration syntax, documentation, etc.
Naturally this is very controversial and people complain that it is against the UNIX philosophy.
systemd comes from a gnome developer. a gnome developer doesn't care what came from before and doesn't care what they produce. all a gnome developer cares about is the future.
the future is what is all that matters and getting there is what matters. have you heard the phrase "the end justifies the means"?
Then he adds, "Here I’m just going to mention a few operating systems that I personally have found interesting." So these few are just ones where he thought he had something fresh to say. He did not aim to compete with the more objective lists he just mentioned.
Just finished reading Hackers: Heroes of the Computer Revolution, and if we could travel back and show the original hackers at MIT things we use in 2020 like systemd, electron etc. I think they would be in complete disbelief over the amount of bloat, and ask us why we stopped caring and started to accept software design like that.
A few linux linux distos, GNU Hurd experiment, rust experiment, BeOS inspired, but none of the main stream BSD OSes? Not including the most popular linux distribution that doesn't have systemd - Android. Not including macOS, but i guess it's not OSS, so it doesn't count. Doesn't include Alpine linux.
That list is hella weird and should be named "Experimental OS that I'm curious about, but don't want to run myself. Also, none of them has systemd"
Android - anyone? Android is linux, it's init is simple and the user experience obviously successful. There is a ton here for other distros to learn and improve on.
That's... one point of view. Another is that Android is very successful at content consumption while falling short at more complex workflows, possessing a remarkably fragmented ecosystem, failing to deliver security updates to most of its users in a reasonable timeframe if at all, and possessing little to no flexibility at the lower layers (ex. supporting BTRFS or ZFS).
I think, that sums up what's wrong with the Linux world right now.
NixOS and GuixSD being the next generation of distributions and people are calling it "neat project with some unique features, but it is more fun as an intellectual curiosity than as something practical" while arguing if a distribution should use Systemd or not...
I think that NixOS could definitely become a foundational next-gen distribution if they fix the Channel system. One fix I'm particularly fond of is flakes.
Right, I definitely wouldn’t say they’re just an intellectual curiosity (although it’s certainly intellectually curious), they’re both very practical daily driver for many use cases. Both are still in active development, but for plenty of applications they are rock solid and ready to go.
In fact Guix System 1.1.0 was released a week or so ago.
[+] [-] edoceo|5 years ago|reply
[+] [-] tgbugs|5 years ago|reply
I realize that Gentoo became a meme at some point, but it also seems that it might have transcended to the level of infrastructure. Thus, you rarely ever heard about it for the same reason you don't hear people talk about hammers -- it is doing its job running tens (hundreds?) of millions of chrome books among other things.
No flare, nothing fancy, it has solved a whole bunch of packaging, deployment, and environment control problems and gotten out of the way of its users (mostly ... chuckle), and it did it all with a pile of bash scripts and a little python here and there. Want to use systemd because you have a use case that would benefit from it? Go right ahead! The engineering work is done, no need for fights on the mailing list. Don't want to use systemd? `eudev` to the rescue! There are sound engineering reasons for not using systemd while also wanting to use some other (seemingly) completely unrelated piece of software that just happens to have a dependency on the kitchen sink.
Despite being a rolling release distribution, I find that the UX and workflows are more stable over long periods of time than any of the more popular LTS style distros. When I started fiddling with Ubuntu so that I could help my colleagues debug issues it took me an embarrassingly long time to realize that there isn't really such a thing as Ubuntu, just 14.04, 16.04, 18.04, etc. Each is some different form the other that stack overflow questions from one LTS are often simply wrong for another.
Writing this I wonder whether rolling release distros aren't effectively the original form of chaos engineering -- if everything is going to be changing all the time then it forces the developers to solve a different and perhaps more fundamental set of problems and ultimately leads to greater stability in the long run.
[+] [-] oehtXRwMkIs|5 years ago|reply
[+] [-] LargoLasskhyfv|5 years ago|reply
[+] [-] jmclnx|5 years ago|reply
edit: just read it again, it is a list of OS he likes, so it was not an omission :)
[+] [-] teleforce|5 years ago|reply
https://www.gnu.org/software/shepherd/
[+] [-] jbnorth|5 years ago|reply
[+] [-] wtallis|5 years ago|reply
[+] [-] Teknoman117|5 years ago|reply
The controversy mainly surrounds the claim that it is a single package that tries to do way too much by itself.
Calling systemd an init system isn't correct. systemd contains many things, one of which is an init system.
The other claim is that the systemd developers aren't open to much outside opinion, but have power over the community because important parts of basically all desktop Linux systems are now part of systemd and have strong dependencies on it (such as udev).
[+] [-] NickNameNick|5 years ago|reply
It's supposed to enable easier encryption of home directories, but breaks ssh logins.
Therefore it's probably only suitable for multi-user systems (which need to protect home directoried from other users) that are also never accessed remotely - a subset consisting of approximately 0 systems.
[+] [-] sliken|5 years ago|reply
Things like NTP, syslog, DHCPd, cron, iptables, mount, automount, handling /tmp, /dev, DNS, su/sudo, etc.
Letting the init system talk to the network before userspace has the ability to setup firewalls gives me the heebie jeebies.
Often the implementations of systemd don't handle failures well, leave off critical features like encryption, DNSSEC, etc. They are often hard to debug, and generally worse than the features they replace.
Not that Linux didn't need a nice init system, but that systemd is trying to take over everything. The lastest volley on that front is taking over management of /home with homed, but in a way that's incompatible with ssh.
Do you really want to depend on systemd's homed for managing /home? I'd rather not.
[+] [-] jacoblambda|5 years ago|reply
This results in certain packages switching to require systemd modules(gnome & udev) and essentially locking systems without systemd out of using said software. Communities supporting non-systemd init systems now have to maintain forks of these modules so that they can keep these packages supported on their distros.
The other issue, which is the issue I care more about is that it does these things in a way that breaks compatibility with existing workflows and exposes it to a number of different issues due to its increased complexity.
Don't get me wrong, systemd is excellent in many ways but like many others, I am not a fan of it overall and choose not to use it where possible.
An example of something very controversal about systemd: journald.
journald is a replacement for the system journaling daemon and is a generally very good journaling daemon. It is in many ways more performant than other journaling daemons and can be easier to use as well. The issues however come largely from the fact that it uses a binary log format. This breaks the ability for other tools access logs nearly as easily unless explicit support for the interaction is added by either journald or the tool in question.
[+] [-] Nasreddin_Hodja|5 years ago|reply
The problem with Systemd is that every time they introduce new non necessary feature they break something in the system. https://bugs.kde.org/show_bug.cgi?id=417038 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 Do they run tests ever?
Now when I launch my desktop I have to login in tty console first, start tmux, detach it, logout from tty, then login into desktop session normally. Otherwise logout from desktop session will hang and logging in again will fail.
They suggest using `systemd-run` instead, but it's broken too at this time. https://github.com/systemd/systemd/issues/3388
[+] [-] the_why_of_y|5 years ago|reply
Naturally this is very controversial and people complain that it is against the UNIX philosophy.
[+] [-] ta17711771|5 years ago|reply
[+] [-] throw7|5 years ago|reply
the future is what is all that matters and getting there is what matters. have you heard the phrase "the end justifies the means"?
that's it.
[+] [-] ppf|5 years ago|reply
[+] [-] bmn__|5 years ago|reply
[+] [-] combatentropy|5 years ago|reply
- Linux distributions without systemd (https://web.archive.org/web/20190208034948/http://without-sy...)
- Operating systems without systemd (https://web.archive.org/web/20190208034948/http://without-sy...)
Then he adds, "Here I’m just going to mention a few operating systems that I personally have found interesting." So these few are just ones where he thought he had something fresh to say. He did not aim to compete with the more objective lists he just mentioned.
[+] [-] efiecho|5 years ago|reply
[+] [-] shrimp_emoji|5 years ago|reply
Crossplatformness or security or convenience in exchange for bloat are all EZ trades. 2.8/62.8 GB of RAM used right now, btw.
[+] [-] andoriyu|5 years ago|reply
That list is hella weird and should be named "Experimental OS that I'm curious about, but don't want to run myself. Also, none of them has systemd"
[+] [-] branon|5 years ago|reply
[0] https://github.com/void-linux/void-mklive/issues/105
[+] [-] bsg75|5 years ago|reply
[+] [-] drudru11|5 years ago|reply
[+] [-] delcaran|5 years ago|reply
[+] [-] itsajoke|5 years ago|reply
[+] [-] kitotik|5 years ago|reply
[+] [-] pengaru|5 years ago|reply
[+] [-] hedora|5 years ago|reply
Denial of service today. Disk operating system when they reinvent FAT poorly.
[+] [-] pnako|5 years ago|reply
[+] [-] tramtrist|5 years ago|reply
[+] [-] mythrwy|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] bhawks|5 years ago|reply
[+] [-] yjftsjthsd-h|5 years ago|reply
That's... one point of view. Another is that Android is very successful at content consumption while falling short at more complex workflows, possessing a remarkably fragmented ecosystem, failing to deliver security updates to most of its users in a reasonable timeframe if at all, and possessing little to no flexibility at the lower layers (ex. supporting BTRFS or ZFS).
[+] [-] catblast|5 years ago|reply
[+] [-] umanwizard|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] k__|5 years ago|reply
NixOS and GuixSD being the next generation of distributions and people are calling it "neat project with some unique features, but it is more fun as an intellectual curiosity than as something practical" while arguing if a distribution should use Systemd or not...
[+] [-] threwawasy1228|5 years ago|reply
[0] https://github.com/NixOS/rfcs/pull/49
[+] [-] justinsaccount|5 years ago|reply
[+] [-] kdtsh|5 years ago|reply
In fact Guix System 1.1.0 was released a week or so ago.
[+] [-] bzb3|5 years ago|reply
No, this didn't start now.
[+] [-] coleifer|5 years ago|reply
[+] [-] fuball63|5 years ago|reply
[+] [-] stevebmark|5 years ago|reply
[+] [-] pengaru|5 years ago|reply
Most contention is over the latter, not so much the former by itself.