8 ms·

Maybe I'm just out of the loop but what is the controversy regarding systemd?

Teknoman117 6y ago
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).
- shrimp_emoji 6y ago
  For example, systemd timers (timed systemctl services) are like cron if cron was slightly more complicated and had very good logging. :3
  - yarrel 6y ago
    journalctl is a text adventure fever dream. Do systemd timers use a different logging system?
    - simcop2387 6y ago
      Nope, they go straight to journald.
    - deadbunny 6y ago
      You can output journald to syslog with one config option[1]. 1. https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html https://www.freedesktop.org/software/systemd/man/systemd-jou...
      - isbjorn16 6y ago
        Then it should be on by default. Having to use journalctl instead of reading a plaintext file in /var/log should have resulted in a swift slap upside the noggin the moment it was first considered. I otherwise don't care about systemd, except for the more-than-one locations I might find an init script hiding on my system. It's fine. But don't make me use journalctl just to tail a god damned file like a normal person. Edit: I may have reached that point on friday night where the bottle of port and my grey beard have finally reached "old man yells at cloud" stage. My apologies.
        majewsky 6y ago
        > Having to use journalctl instead of reading a plaintext file in /var/log should have resulted in a swift slap upside the noggin the moment it was first considered. I absolutely love the idea of journalctl (without commenting on the execution). As an admin, there was always the chance that $DAEMON_OF_THE_DAY put their logfile in a particularly creative place, thus sending me on some wild goose hunt. Now it's just `journalctl -u $DAEMON` and that works immediately, every single time. Also, as a user running journald on a notebook, I love that it's just one config switch to send all the logs from all the services to /run instead of /var, to reduce the write load on the SSD. Sure you could fiddle with a bind-mount but that would have to happen very early in the boot process so I don't think it would be as reliable. As a daemon writer, it's one less option for me to care about. Especially when my daemon is just some bash script, logging to stdout is the easiest way. And logging to stdout also meshes well with running the same daemon/script in container environments like Docker or Kubernetes where containers usually don't even have syslogd. (In fact, I have containerized a service that requires syslogd and that was kind of a pain. I ended up using a mini-syslogd implementation that just dumps all logs on stdout so Docker can pick it up.)
        viluon 6y ago
        It also allows you to read the logs in JSON, which is fantastic for automation. Parsing the syslog as a text file means a single newline in a syslog message screws your effort up. With journalctl, you can sift through error messages from specific services, confident that the results you are getting are exactly what the logs contain. Unless, of course, some of the binaries are corrupt.
- yarrel 6y ago
  It tries to do too much, badly, and with an air of entitlement around intentionally breaking things. Change is good, so let's change away from systemd.
  - thawaway1837 6y ago
    If someone is able to create something that is half as good as systemd then distros will switch time it. The thing is that systemd solves a lot of problems for distros in a good enough way (frankly, currently in a way that is better than any existing alternative) that they are happy to have systemd deal with those issues while they focus on the stuff the distro makers are interested in.
    - yjftsjthsd-h 6y ago
      > If someone is able to create something that is half as good as systemd then distros will switch time it. Not a given, since one of the issues with systemd is its integrations. Replacing init now requires you to replace your system logging and session manager, at a minimum, as well as replace all your service files.
      - the_why_of_y 6y ago
        systemd-logind is optional and you would be able to use ConsoleKit instead if anybody had maintained it in the last 5 years. Unlike e.g. upstart in its native mode, systemd can run SysV init scripts. https://unix.stackexchange.com/questions/233468/how-does-systemd-use-etc-init-d-scripts https://unix.stackexchange.com/questions/233468/how-does-sys...
        JdeBP 6y ago
        By "system logging" yjftsjthsd-h was referring to systemd-journald, not systemd-logind.
        the_why_of_y 6y ago
wtallis 6y ago
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.
- Teknoman117 6y ago
  Pretty much. There are components of systemd I really like. systemd-logind is really neat, it makes dealing with drm (direct rendering) devices nice by having a service where you can request access to GPUs without bumping into the problem of one process opened the endpoint and has exclusive control. It also makes dealing with machine events like closing your laptop's screen simple if you use a minimalistic window manager like i3. systemd-resolved is nice if you're using systemd's network configuration system, but it's a pain when you're trying to run your own DNS server. udev really shouldn't hard depend on systemd. I perfectly understand having some systemd specific integration, but why make it mandatory? There being said, various people have been working to cut it into separate components (eudev, elogind, etc.)
  - microcolonel 6y ago
    > udev really shouldn't hard depend on systemd. I perfectly understand having some systemd specific integration, but why make it mandatory? udev is part of systemd now, because the systemd developers were the only ones willing to maintain it.
    - RunningDroid 6y ago
NickNameNick 6y ago
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.
- m4rtink 6y ago
  Actually AFAIK the main usecase is single user client systems (say a laptop). Homed makes it easier to encrypt the home directory at any time (without the need to reformat with LUKS) and handles stuff like suspend better (can drop encryption keys before going to suspend and then requesting them on resume).
  - jdmg94 6y ago
    that's such a small sliver of linux users that the vast majority of linux users (who actually need SSH) are taking the overhead for nothing in return...
    - fsh 6y ago
      Don't use it if you don't need it. The developers made it very clear that systemd-homed is only meant for single-user laptops.
      - hedora 6y ago
        Home directory encryption is a terrible security mode for single user laptops (an attacker with disk access can simply modify the unprotected root file system and exfiltrate data after the fact). Whole disk encryption (and encrypted suspend to disk for bonus points) is simpler, more secure, and doesn’t break ssh (and all sorts of other things, like batch jobs).
ta17711771 6y ago
My pet-bitch is that it's far too large and convoluted to audit properly for most-sized teams.
- majewsky 6y ago
  As is the Linux kernel.
  - hedora 6y ago
    Yes, but the Linux kernel’s not replacing a few thousand lines of shell script.
jacoblambda 6y ago
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.
- megous 6y ago
  I find systemd journals much more accessible. Instead of passing a log file to the tool, you pass journalctl's output to the tool, and you can serialize the output to any of the supported formats (incl. json) and use much more tools, more directly, than you could previously. Compare that with random older default debian log line from one of my systems: Feb 14 01:15:30 shakes kernel: [ 4.014481] [drm] No driver support for vblank timestamp query. Is that from 2008 or 2020? Noone knows. You have to do a lot to even be able to select by date correctly in your log processing tools. Such a basic thing.
  - jacoblambda 6y ago
    My biggest issues personally are the lock-in of systemd overall and for journald the binary file format. If I could use journald on its own with OpenRC first and foremost and preferably have it store logs as text be it json or whatever then I would use it hands down. Journald just works for the most part and is much more convenient in most regards nowadays. If I remember correctly, interop was more of an issue before the big distros started to switch to systemd but now things seem to have mostly worked themselves out. With regard to my comment about wanting logs stored as text, it really just comes down to having had to deal with corrupted binary files one too many times and unless it is absolutely unavoidable I find myself preferring text files for that reason. I'd imagine file system based compression leaves most if any storage benefit from binary logs rendered moot. I know you can run a secondary syslog daemon from the output of journald or alternatively use a job to backup to a text based format but it would be so much more convenient to be able to just set a config setting. Having easy config and things "just working" is supposed to be one of systemd's strengths anyway. Final thing to note is that at least from the perspective of someone running Gentoo w/ OpenRC, issues with traditional loggers are typically config mistakes more than anything. As for your debian log example, syslog-ng which I believe Debian had used should default to isodate for the datetime format. At least this is the case after RFC 5424 was adopted in 2009. That should give something along the lines of "1985-04-12T19:20:50.52-04:00". Nowadays unless the defaults are changed, most logging systems shouldn't have that datetime issue.
throw7 6y ago
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"? that's it.
sliken 6y ago
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.
- microcolonel 6y ago
  Most of these things are simply untrue. The idea that homed is "incompatible with SSH" is preposterous. > Letting the init system talk to the network before userspace has the ability to setup firewalls gives me the heebie jeebies. Are these just random claims? The init system is userspace, and you can have any service wait for anything to access the network, including disabling the whole network target and triggering it manually.
  - wtallis 6y ago
    > The idea that homed is "incompatible with SSH" is preposterous. And yet, any honest assessment of the pros and cons of the homed proposal has to discuss the impact on SSH users in the cons section.
  - hedora 6y ago
    Here’s a remote exploit for the systemd DNS client: https://groups.google.com/d/topic/linux.debian.user/2KyNDWMjA5s https://groups.google.com/d/topic/linux.debian.user/2KyNDWMj... Here’s one for systemd DHCP: https://blog.erratasec.com/2018/10/systemd-is-bad-parsing-and-should-feel.html https://blog.erratasec.com/2018/10/systemd-is-bad-parsing-an... Firewalls wouldn’t help with either of these, in fairness.
  - 6y ago
the_why_of_y 6y ago
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.
Nasreddin_Hodja 6y ago
> Maybe I'm just out of the loop but what is the controversy regarding systemd? 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.kde.org/show_bug.cgi?id=417038 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 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 https://github.com/systemd/systemd/issues/3388

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).

shrimp_emoji 6y ago
For example, systemd timers (timed systemctl services) are like cron if cron was slightly more complicated and had very good logging. :3
- yarrel 6y ago
  journalctl is a text adventure fever dream. Do systemd timers use a different logging system?
  - simcop2387 6y ago
    Nope, they go straight to journald.
  - deadbunny 6y ago
    You can output journald to syslog with one config option[1]. 1. https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html https://www.freedesktop.org/software/systemd/man/systemd-jou...
    - isbjorn16 6y ago
      Then it should be on by default. Having to use journalctl instead of reading a plaintext file in /var/log should have resulted in a swift slap upside the noggin the moment it was first considered. I otherwise don't care about systemd, except for the more-than-one locations I might find an init script hiding on my system. It's fine. But don't make me use journalctl just to tail a god damned file like a normal person. Edit: I may have reached that point on friday night where the bottle of port and my grey beard have finally reached "old man yells at cloud" stage. My apologies.
      - majewsky 6y ago
        > Having to use journalctl instead of reading a plaintext file in /var/log should have resulted in a swift slap upside the noggin the moment it was first considered. I absolutely love the idea of journalctl (without commenting on the execution). As an admin, there was always the chance that $DAEMON_OF_THE_DAY put their logfile in a particularly creative place, thus sending me on some wild goose hunt. Now it's just `journalctl -u $DAEMON` and that works immediately, every single time. Also, as a user running journald on a notebook, I love that it's just one config switch to send all the logs from all the services to /run instead of /var, to reduce the write load on the SSD. Sure you could fiddle with a bind-mount but that would have to happen very early in the boot process so I don't think it would be as reliable. As a daemon writer, it's one less option for me to care about. Especially when my daemon is just some bash script, logging to stdout is the easiest way. And logging to stdout also meshes well with running the same daemon/script in container environments like Docker or Kubernetes where containers usually don't even have syslogd. (In fact, I have containerized a service that requires syslogd and that was kind of a pain. I ended up using a mini-syslogd implementation that just dumps all logs on stdout so Docker can pick it up.)
        viluon 6y ago
        It also allows you to read the logs in JSON, which is fantastic for automation. Parsing the syslog as a text file means a single newline in a syslog message screws your effort up. With journalctl, you can sift through error messages from specific services, confident that the results you are getting are exactly what the logs contain. Unless, of course, some of the binaries are corrupt.
yarrel 6y ago
It tries to do too much, badly, and with an air of entitlement around intentionally breaking things. Change is good, so let's change away from systemd.
- thawaway1837 6y ago
  If someone is able to create something that is half as good as systemd then distros will switch time it. The thing is that systemd solves a lot of problems for distros in a good enough way (frankly, currently in a way that is better than any existing alternative) that they are happy to have systemd deal with those issues while they focus on the stuff the distro makers are interested in.
  - yjftsjthsd-h 6y ago
    > If someone is able to create something that is half as good as systemd then distros will switch time it. Not a given, since one of the issues with systemd is its integrations. Replacing init now requires you to replace your system logging and session manager, at a minimum, as well as replace all your service files.
    - the_why_of_y 6y ago
      systemd-logind is optional and you would be able to use ConsoleKit instead if anybody had maintained it in the last 5 years. Unlike e.g. upstart in its native mode, systemd can run SysV init scripts. https://unix.stackexchange.com/questions/233468/how-does-systemd-use-etc-init-d-scripts https://unix.stackexchange.com/questions/233468/how-does-sys...
      - JdeBP 6y ago
        By "system logging" yjftsjthsd-h was referring to systemd-journald, not systemd-logind.
        the_why_of_y 6y ago

wtallis 6y ago

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.

Teknoman117 6y ago
Pretty much. There are components of systemd I really like. systemd-logind is really neat, it makes dealing with drm (direct rendering) devices nice by having a service where you can request access to GPUs without bumping into the problem of one process opened the endpoint and has exclusive control. It also makes dealing with machine events like closing your laptop's screen simple if you use a minimalistic window manager like i3. systemd-resolved is nice if you're using systemd's network configuration system, but it's a pain when you're trying to run your own DNS server. udev really shouldn't hard depend on systemd. I perfectly understand having some systemd specific integration, but why make it mandatory? There being said, various people have been working to cut it into separate components (eudev, elogind, etc.)
- microcolonel 6y ago
  > udev really shouldn't hard depend on systemd. I perfectly understand having some systemd specific integration, but why make it mandatory? udev is part of systemd now, because the systemd developers were the only ones willing to maintain it.
  - RunningDroid 6y ago

NickNameNick 6y ago

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.

m4rtink 6y ago
Actually AFAIK the main usecase is single user client systems (say a laptop). Homed makes it easier to encrypt the home directory at any time (without the need to reformat with LUKS) and handles stuff like suspend better (can drop encryption keys before going to suspend and then requesting them on resume).
- jdmg94 6y ago
  that's such a small sliver of linux users that the vast majority of linux users (who actually need SSH) are taking the overhead for nothing in return...
  - fsh 6y ago
    Don't use it if you don't need it. The developers made it very clear that systemd-homed is only meant for single-user laptops.
    - hedora 6y ago
      Home directory encryption is a terrible security mode for single user laptops (an attacker with disk access can simply modify the unprotected root file system and exfiltrate data after the fact). Whole disk encryption (and encrypted suspend to disk for bonus points) is simpler, more secure, and doesn’t break ssh (and all sorts of other things, like batch jobs).

ta17711771 6y ago

My pet-bitch is that it's far too large and convoluted to audit properly for most-sized teams.

majewsky 6y ago
As is the Linux kernel.
- hedora 6y ago
  Yes, but the Linux kernel’s not replacing a few thousand lines of shell script.

jacoblambda 6y ago

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.

megous 6y ago
I find systemd journals much more accessible. Instead of passing a log file to the tool, you pass journalctl's output to the tool, and you can serialize the output to any of the supported formats (incl. json) and use much more tools, more directly, than you could previously. Compare that with random older default debian log line from one of my systems: Feb 14 01:15:30 shakes kernel: [ 4.014481] [drm] No driver support for vblank timestamp query. Is that from 2008 or 2020? Noone knows. You have to do a lot to even be able to select by date correctly in your log processing tools. Such a basic thing.
- jacoblambda 6y ago
  My biggest issues personally are the lock-in of systemd overall and for journald the binary file format. If I could use journald on its own with OpenRC first and foremost and preferably have it store logs as text be it json or whatever then I would use it hands down. Journald just works for the most part and is much more convenient in most regards nowadays. If I remember correctly, interop was more of an issue before the big distros started to switch to systemd but now things seem to have mostly worked themselves out. With regard to my comment about wanting logs stored as text, it really just comes down to having had to deal with corrupted binary files one too many times and unless it is absolutely unavoidable I find myself preferring text files for that reason. I'd imagine file system based compression leaves most if any storage benefit from binary logs rendered moot. I know you can run a secondary syslog daemon from the output of journald or alternatively use a job to backup to a text based format but it would be so much more convenient to be able to just set a config setting. Having easy config and things "just working" is supposed to be one of systemd's strengths anyway. Final thing to note is that at least from the perspective of someone running Gentoo w/ OpenRC, issues with traditional loggers are typically config mistakes more than anything. As for your debian log example, syslog-ng which I believe Debian had used should default to isodate for the datetime format. At least this is the case after RFC 5424 was adopted in 2009. That should give something along the lines of "1985-04-12T19:20:50.52-04:00". Nowadays unless the defaults are changed, most logging systems shouldn't have that datetime issue.

throw7 6y ago

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"? that's it.

sliken 6y ago

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.

microcolonel 6y ago
Most of these things are simply untrue. The idea that homed is "incompatible with SSH" is preposterous. > Letting the init system talk to the network before userspace has the ability to setup firewalls gives me the heebie jeebies. Are these just random claims? The init system is userspace, and you can have any service wait for anything to access the network, including disabling the whole network target and triggering it manually.
- wtallis 6y ago
  > The idea that homed is "incompatible with SSH" is preposterous. And yet, any honest assessment of the pros and cons of the homed proposal has to discuss the impact on SSH users in the cons section.
- hedora 6y ago
  Here’s a remote exploit for the systemd DNS client: https://groups.google.com/d/topic/linux.debian.user/2KyNDWMjA5s https://groups.google.com/d/topic/linux.debian.user/2KyNDWMj... Here’s one for systemd DHCP: https://blog.erratasec.com/2018/10/systemd-is-bad-parsing-and-should-feel.html https://blog.erratasec.com/2018/10/systemd-is-bad-parsing-an... Firewalls wouldn’t help with either of these, in fairness.
- 6y ago

the_why_of_y 6y ago

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.

Nasreddin_Hodja 6y ago

> Maybe I'm just out of the loop but what is the controversy regarding systemd? 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.kde.org/show_bug.cgi?id=417038 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 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 https://github.com/systemd/systemd/issues/3388