15 ms·

If systemd is so horrible why is everyone switching to it? EDIT: This is an honest question. I read quite a few negative comments on it and yet people in charge

by tener 10y ago

If systemd is so horrible why is everyone switching to it? EDIT: This is an honest question. I read quite a few negative comments on it and yet people in charge seem to be convinced this is the way forward. I'm curious why.

naivepiano 10y ago
I don't know about other distros but let me remind you that ubuntu sometime ago switched from gnome desktop to Unity despite all the cries that the latter is just horrible.
- dorfsmay 10y ago
  But you can still run gnome on Ubuntu (I do), and Linux without a graphical interface at all.
  - naivepiano 10y ago
    True. Or you can switch to Mint. The think with systemd though is that you don't have this option anymore. Regardless of how bad idea you think it is - you are stuck with it (as it seems). I think that's on the core of arguments against it.
  - snaky 10y ago
    Without "Desktop Environment", not without graphical interface.
    - digi_owl 10y ago
      Huh? When did a console become a graphical interface?
      - snaky 10y ago
        Not a console. X Window System and window manager.
- reacweb 10y ago
  If you do not like unity, you can just use ubuntu-gnome like me. IMHO, Unity is horrible, but you have the choice to not use it. There is no need to complain.
  - naivepiano 10y ago
    Criticism does not equal complain. If I find something horrible I'll say so - that's feedback. By your way of thinking, since I don't have to use brainfuck (an intentionally horrible language) I should not mention that it is horrible. You just don't make sense other than patting youself on the back for being 'positive' downvoting the grumpy ones while letting bad ideas forward.
- digi_owl 10y ago
  And? I don't see Canonical hog tying their DE to user space internals such that everyone else had to fork it or adopt it. Why are people constantly trying to demonize Canonical?
jacquesm 10y ago
Because systemd makes certain desktop related tasks easier to present to the user. It's a huge loss imnsho because linux on the desktop wasn't held back by a lack of such niceties but by market conditions, at the same time linux on the server will be held back by systemd because of its tendency to do things 'its' way. I haven't seen any single subsystem harm the linux eco-system as much as systemd has and while I understand the desktop vendors clout in this the server is where linux shines and that was territory that was hard won. If all systemd had done was offer an alternative init system then that would have been a non-event, to take over the entirety of the linux system side tried-and-true and battle tested utilities is irresponsible at best and dangerous at worst. It wasn't broken, so it did not need fixing / rewriting.
- lossolo 10y ago
  You didn't provided any real argument besides the obvious one - change. I use systemd on my Debian servers and i just don't see it as something bad. I have created systemd services that i use and it's really convenient.
  - jacquesm 10y ago
    Yes, it is much more convenient, and as an init system there isn't much wrong with it. But in software change for change's sake alone is simply wrong, it creates friction because a lot of knowledge has to be discarded and then has to be replaced by different knowledge. Large amounts of regression testing suddenly become useless which will generate ample opportunity for re-hashes of old bugs and issues (see linked article). Modular designs are good, monolithic designs are bad. Dependencies are bad and so on. Lots of choices at the design level were made against fairly hard won knowledge on how to architect complex software systems. All these dependencies translate into 'all or nothing' and that is never a good thing in the software world. It's just another form of lock-in, something that the world of closed source software is good at and I'm quite sad to see it pollute the world of open source. Edit: I suspect a lot of the pushback against systemd - mertited or not - is because a lot of people in charge of little parts of the bazaar have seen their pet projects cast aside by the major distros and taken over by the systemd devs. In a world where street cred is a big force in motivating people to contribute to open source being maintainer of 'x' where 'x' is part of each and every linux distro out there and then to see 'x' taken over by systemd in a fairly rough manner without any kind of co-operation between the old maintainers and the new kids on the block there are bound to be a lot of ruffled feathers. But that's not technology, that's just ego.
sunseb 10y ago
Maybe because Red Hat pays the bills ?
- digi_owl 10y ago
  Bingo. A full time programmer can churn out code and keep up with lists much better than someone that do so on their spare time. Never mind that if you have several programmers on RH payroll on the same project, it is quite possible for them to use corporate channels to make decisions and then effectively dump that into the codebase over night.
gaius 10y ago
Red Hat's marketing muscle to "embrace and extend".
- snassar 10y ago
  How does this argument even make sense? Since when are Debian developers or Arch linux developers overly concerned with Red Hat marketing muscle?
  - nitrogen 10y ago
    RedHat controls development of other important Linux subsystems and introduced hard dependencies on systemd.
    - snassar 10y ago
      This might or might not be true. I would be inclined to agree more with it if the evidence from other distribution highlighted this argument. I don't see Debian or Arch developers making that argument. Are they hiding how much pressure from Red Hat they feel? Unlikely. Linux developers are happy to blog, tweet, and post to mailing lists about large and small things, but somehow a concerted push by a corporation makes them fall silent and accept SystemD?
      - nitrogen 10y ago
        Those things all happened, it's just been going on subtly over a period of years. A search for Gnome and systemd on HN should turn up some of the earlier complaints. The *BSD developers certainly made some noise.
      - digi_owl 10y ago
        I think it is pressure in the overt sense. It is rather that RH can throw dollars and thus coder man hours at a problem while most other distros have to make do with volunteers (or can't field the amounts RH can). Then again, there is a certain email from Poettering thats of interest. https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
na85 10y ago
Because scope creep means more and more packages have systemd as a hard dependency.
- snaky 10y ago
  And that is not a coincidence > Well, it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there's really no point at all in doing so. > Due to that our plan is to enable all this by default in "make install". Packagers may then choose to disable it by doing an "rm" after the "make install", but we want to put the burden on the packagers, so that eventually we end up with the same base system on all distributions, and we put an end to senseless configuration differences between the distros for the really basic stuff. > If a distro decides that for example the random seed save/restore is not good enough for it, then it's their own job to disable ours and plug in their own instead. Sooner or later they'll hopefully notice that it's not worth it and cross-distro unification is worth more. https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...
naivepiano 10y ago
"There is also concern that it forms a system of interlocked dependencies, thereby giving distribution maintainers little choice but to adopt systemd as more user-space software come to depend on its components" from relative wikipedia article (https://en.wikipedia.org/wiki/Systemd https://en.wikipedia.org/wiki/Systemd). This does not sound any good.
petepete 10y ago
I don't think it's really all that bad; several big, popular, widely-deployed distributions are using it and most people appear to be getting on just fine. It's just that people against it are extremely vocal. I do dislike the idea of binary logs, though.
- pas 10y ago
  I like binary logs. They are faster, which is not a bad thing if you have to grep them. And easy to filter thanks to a fix metadata interface, and so on. journalctl could use some work, but it can just print JSON, and there's jq.
  - petepete 10y ago
    Maybe my dislike for binary logs is because I haven't yet learnt the tooling around them. I'm familiar with dealing with text files in Linux/Unix land and have built up years of knowledge on doing so. I feel reluctant to throw that away.
- fridsun 10y ago
  People against it are extremely vocal because it is much harder to work around than previous stuff. Don't like PulseAudio? Use alsa directly is fine, I did in my Arch Linux box. Don't like Flash? HTML5 FTW. Don't like systemd? I have to go to FreeBSD altogether.
pmlnr 10y ago
Because it started small and OK. When distros made the decision to switch, it looked OK. It has proliferated into something else since then and none of the distros seems to be willing to take a step back.
- digi_owl 10y ago
  Problem there may be that going back means picking up maintenance on code that has been abandoned for years. There is a fork of Consolekit out there, Consolekit2, but they have to contend chasing logind's tail as most DEs have either stripped out their consolekit support, or it is suffering from severe bitrot.
coroutines 10y ago
systemd is a good thing (tm) - I recognize that and am grateful for it. However. In the beginning a lot of distros were "forced" to accept systemd because udev was merged into its codebase. Systemd is great, but its group of devs are absolutely fucking terrible at public relations. Sometimes they make changes that upset users. Like the recent one that has (logind?) by default killing all user-created processes when the user logs out (this surprised people as it became a new default). Or the security incident before that where systemd made it possible for users to get access to framebuffer contents. Sometimes things happen. It's just made worse when you go to the systemd group with your problem and they act like what they've done is correct and everybody should just live with it. Sometimes we're wrong, sometimes they're wrong. Poettering writes up these really long posts which are mostly good reads, but sometimes he calls us neckbeards who want to live in an unchanging, static past. Great project, great code, great devs - but terrible attitudes [sometimes].
- Qantourisc 10y ago
  "Great code" -> I am sorry, but if the allegations are true it's not great. (Not saying every part of it is bad, I kinda like the idea of systemd-init-part, but I describe them as utterly inconsiderate to everyone else.)
- rwmj 10y ago
  Gigantic thread on the KillUserProcesses setting: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZNQW72UP36UAFMX53HPFFQTWTQDZVJ3M/ https://lists.fedoraproject.org/archives/list/devel@lists.fe...
  - digi_owl 10y ago
    Dear deity... https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TE2YM2PFMWSOJ3DYZ7JQOCTCQPJA3SRD/ https://lists.fedoraproject.org/archives/list/devel@lists.fe...
- JdeBP 10y ago
  It was indeed logind. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 * https://news.ycombinator.com/item?id=11782364 https://news.ycombinator.com/item?id=11782364 The systemd developers' way of addressing that was to go and ask the people who wrote things like tmux to change tmux. The response of the tmux developers was to repeat the question asked and not answered 5 years ago. * https://news.ycombinator.com/item?id=11798515 https://news.ycombinator.com/item?id=11798515 * https://news.ycombinator.com/item?id=11797075 https://news.ycombinator.com/item?id=11797075 The problem where the people who just switched to Ubuntu 16 are hitting problems with high-end database servers, middleware, containers, large builds, and so forth all running out of threads because of another systemd default that was switched by its developers, is still quietly on-going. * https://news.ycombinator.com/item?id=11675129 https://news.ycombinator.com/item?id=11675129
sklogic 10y ago
Under a severe pressure from a vocal and extremely tribal minority, of course. There are no technical reasons to do it.
snassar 10y ago
I am not an Arch Linux developer, but I am a systemd user on Debian 8 and Arch Linux systems. Here is one answer from an Arch developer about why they adopted systemd: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...
- baldfat 10y ago
  This was a GREAT answer. The problem is that this is not a factual argument but more an emotional argument. "From 2brainz (Former Arch Linux Developer for Init Scripts" > I was the primary maintainer for Arch's init scripts for a while and I can share a couple of thoughts. Arch's initscripts were incredibly stupid. In their first phase, there was a static set of steps that would be performed on every boot. There was almost no way to adjust the behaviour here. In their second phase, the configured daemons were started in order, which only meant that a init scripts were called one after another. In the early 2000s, that seemed like a good idea and has worked for a while. But with more complex setups, the shortcomings of that system become apparent. With hardware becoming more dynamic and asynchronous initialization of drivers in the kernel, it was impossible to say when a certain piece of hardware would be available. For a long time, this was solved by first triggering uevents, then waiting for udev to "settle". This often took a very long time and still gave no guarantee that all required hardware was available. Working around this in shell code would be very complex, slow and error-prone: You'd have to retry all kinds of operations in a loop until they succeed. Solution: An system that can perform actions based on events - this is one of the major features of systemd. Initscripts had no dependency handling for daemons. In times where only a few services depended on dbus and nothing else, that was easy to handle. Nowadays, we have daemons with far more complex dependencies, which would make configuration in the old initscripts-style way hard for every user. Handling dependencies is a complex topic and you don't want to deal with it in shell code. Systemd has it built-in (and with socket-activation, a much better mechanism to deal with dependencies). Complex tasks in shell scripts require launching external helper program A LOT. This makes things very slow. Systemd handles most of those tasks with builtin fast C code, or via the right libraries. It won't call many external programs to perform its tasks. The whole startup process was serialized. Also very slow. Systemd can parallelize it and does so quite well. No indication of whether a certain daemon was already started. Each init script had to implement some sort of PID file handling or similar. Most init scripts didn't. Systemd has a 100% reliable solution for this based on Linux cgroups. Race conditions between daemons started via udev rules, dbus activation and manual configuration. It could happen that a daemon was started multiple times (maybe even simultaneously), which lead to unexpected results (this was a real problem with bluez). Systemd provides a single instance where all daemons are handled. Udev or dbus don't start daemons anymore, they tell systemd that they need a specific daemon and systemd takes care of it. Lack of confiurability. It was impossible to change the behaviour of initscripts in a way that would survive system updates. Systemd provides good mechanisms with machine-specific overrides, drop-ins and unit masking. Burden of maintenance: In addition to the aforementioned design problems, initscripts also had a large number of bugs. Fixing those bugs was always complicated and took time, which we often did not have. Delegating this task to a larger community (in this case, the systemd community) made things much easier for us. I realize that many of these problems could be solved with some work, and some were already solved by other SysV-based init systems. There was no system that solved all of these problems and did so in a realiable manner, as systemd does. So, for me personally, when systemd came along, it solved all the problems I ever had with system initialization. What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. You can say what you want about Poettering, but he actually realized what the problems with system initialization were and provided a working solution. I could go on for hours, but this should be a good summary.
jpgvm 10y ago
Basically because RedHat has an obscene amount of clout in the ecosystem and can basically push through whatever they want. See here systemd, pulseaudio, lvm, selinux, kvm, many more. Some of these things are good, some of them are bad. The important thing is once RH has decided they want to take over another component of the ecosystem there isn't really a lot anyone can do. Not even Linus has been able to halt the systemd nonsense. Why do other distros cave? Well because RH controls most of the other important projects too and they go to great lengths to create integration that is unnecessarily difficult to decouple. For instance Gnome. Probably impossible to run without systemd now (or at least highly impractical). At the end of the day it has nothing to do with the technical merits of systemd and everything to do with how much power RH has to steamroll whatever solutions they want through.
- baldfat 10y ago
  > At the end of the day it has nothing to do with the technical merits of systemd and everything to do with how much power RH has to steamroll whatever solutions they want through. RedHat is a premium member of our community that has a well earned reputation which makes whatever they do get noticed. Why are they to be the focus of a witch hunt like if they were MicroSoft of the Steve Ballmer era? If these things didn't solve problem they wouldn't get used period. RedHat being an evil member of Linux seems almost comical. Linux has won the war and yes RedHat has been a key member in winning the technology war. I fail to see how all distros who can do whatever they want continue to chosen RedHat solutions over and over again? They make developers lives better and arguably Linux better. Canonical on the other hand continues to be a Linux community member that tries to compete with everyone else and doesn't contribute upstream as much as everyone else. I say it is good news now we can have less wasted work on different solutions. Why hasn't Canonical's projects caught on? They don't work as well or seen to not work as well as other solutions. Unity anyone? PulseAudio has been a HUGE success that so many talk down due to the rocky start of the project and the personality of the developer (Who also created SystemD) Audio in Linux was a huge mess prior to Pulse Audio. KVM - is the best virtual system bar none. lvm - I don't really need to defend this project? selinux - This was started by the NSA not RedHat
  - 10y ago
rwmj 10y ago
systemd is many things. It's a sensible init system, better in some ways than upstart and lightyears ahead of SysV init. Its native support for confining daemons' process tree using cgroups is generally a good idea. But it's also a load of unrelated utilities like this one. Unfortunately if you get systemd as an init system, you generally get all this other stuff (unless you take steps to remove them, which in some cases is simple and in others is painful). Some of these utilities might be a good idea, but they should be separate projects, not bundled.
- pmahoney 10y ago
  As a daemontools fan, I'm frustrated that something in the daemontools family never became popular (process supervision, be it daemontools, upstart, systemd, etc. makes managing services so much nicer). But I do recognize the utility of using cgroups as part of this. Is there, or could there be, a "do one thing" utility that can launch a process in its own cgroup, such that it would fit in nicely in a daemontools-style run script?
  - JdeBP 10y ago
    There indeed could be. (-:
    - JdeBP 10y ago
      Hey, presto! jdebp % cat /var/sv/epmd/service/run #!/bin/nosh #Run file generated from services/epmd.service #Erlang Port Mapper service move-to-control-group epmd.service setuidgid rabbitmq userenv epmd jdebp %
fridsun 10y ago
My 2 cents: init script wasn't a enough pain in the ass for people in charge to search for alternatives but still a pain, and systemd was introduced to them by Red Hat manpower. It seems good enough so they went with it. Actually, init script wasn't anyone's enough pain in the ass in Linux world save for djb. daemontools came out in 1997 and no one seemed to care. Systemd replaced those init scripts IMO only because they wrote all the replacement service files as well with the manpower at Red Hat's disposal. It's hard to match that from open source world.

by tener 10y ago

naivepiano 10y ago

I don't know about other distros but let me remind you that ubuntu sometime ago switched from gnome desktop to Unity despite all the cries that the latter is just horrible.

dorfsmay 10y ago
But you can still run gnome on Ubuntu (I do), and Linux without a graphical interface at all.
- naivepiano 10y ago
  True. Or you can switch to Mint. The think with systemd though is that you don't have this option anymore. Regardless of how bad idea you think it is - you are stuck with it (as it seems). I think that's on the core of arguments against it.
- snaky 10y ago
  Without "Desktop Environment", not without graphical interface.
  - digi_owl 10y ago
    Huh? When did a console become a graphical interface?
    - snaky 10y ago
      Not a console. X Window System and window manager.
reacweb 10y ago
If you do not like unity, you can just use ubuntu-gnome like me. IMHO, Unity is horrible, but you have the choice to not use it. There is no need to complain.
- naivepiano 10y ago
  Criticism does not equal complain. If I find something horrible I'll say so - that's feedback. By your way of thinking, since I don't have to use brainfuck (an intentionally horrible language) I should not mention that it is horrible. You just don't make sense other than patting youself on the back for being 'positive' downvoting the grumpy ones while letting bad ideas forward.
digi_owl 10y ago
And? I don't see Canonical hog tying their DE to user space internals such that everyone else had to fork it or adopt it. Why are people constantly trying to demonize Canonical?

jacquesm 10y ago

Because systemd makes certain desktop related tasks easier to present to the user. It's a huge loss imnsho because linux on the desktop wasn't held back by a lack of such niceties but by market conditions, at the same time linux on the server will be held back by systemd because of its tendency to do things 'its' way. I haven't seen any single subsystem harm the linux eco-system as much as systemd has and while I understand the desktop vendors clout in this the server is where linux shines and that was territory that was hard won. If all systemd had done was offer an alternative init system then that would have been a non-event, to take over the entirety of the linux system side tried-and-true and battle tested utilities is irresponsible at best and dangerous at worst. It wasn't broken, so it did not need fixing / rewriting.

lossolo 10y ago
You didn't provided any real argument besides the obvious one - change. I use systemd on my Debian servers and i just don't see it as something bad. I have created systemd services that i use and it's really convenient.
- jacquesm 10y ago
  Yes, it is much more convenient, and as an init system there isn't much wrong with it. But in software change for change's sake alone is simply wrong, it creates friction because a lot of knowledge has to be discarded and then has to be replaced by different knowledge. Large amounts of regression testing suddenly become useless which will generate ample opportunity for re-hashes of old bugs and issues (see linked article). Modular designs are good, monolithic designs are bad. Dependencies are bad and so on. Lots of choices at the design level were made against fairly hard won knowledge on how to architect complex software systems. All these dependencies translate into 'all or nothing' and that is never a good thing in the software world. It's just another form of lock-in, something that the world of closed source software is good at and I'm quite sad to see it pollute the world of open source. Edit: I suspect a lot of the pushback against systemd - mertited or not - is because a lot of people in charge of little parts of the bazaar have seen their pet projects cast aside by the major distros and taken over by the systemd devs. In a world where street cred is a big force in motivating people to contribute to open source being maintainer of 'x' where 'x' is part of each and every linux distro out there and then to see 'x' taken over by systemd in a fairly rough manner without any kind of co-operation between the old maintainers and the new kids on the block there are bound to be a lot of ruffled feathers. But that's not technology, that's just ego.

sunseb 10y ago

Maybe because Red Hat pays the bills ?

digi_owl 10y ago
Bingo. A full time programmer can churn out code and keep up with lists much better than someone that do so on their spare time. Never mind that if you have several programmers on RH payroll on the same project, it is quite possible for them to use corporate channels to make decisions and then effectively dump that into the codebase over night.

gaius 10y ago

Red Hat's marketing muscle to "embrace and extend".

snassar 10y ago
How does this argument even make sense? Since when are Debian developers or Arch linux developers overly concerned with Red Hat marketing muscle?
- nitrogen 10y ago
  RedHat controls development of other important Linux subsystems and introduced hard dependencies on systemd.
  - snassar 10y ago
    This might or might not be true. I would be inclined to agree more with it if the evidence from other distribution highlighted this argument. I don't see Debian or Arch developers making that argument. Are they hiding how much pressure from Red Hat they feel? Unlikely. Linux developers are happy to blog, tweet, and post to mailing lists about large and small things, but somehow a concerted push by a corporation makes them fall silent and accept SystemD?
    - nitrogen 10y ago
      Those things all happened, it's just been going on subtly over a period of years. A search for Gnome and systemd on HN should turn up some of the earlier complaints. The *BSD developers certainly made some noise.
    - digi_owl 10y ago
      I think it is pressure in the overt sense. It is rather that RH can throw dollars and thus coder man hours at a problem while most other distros have to make do with volunteers (or can't field the amounts RH can). Then again, there is a certain email from Poettering thats of interest. https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...

na85 10y ago

Because scope creep means more and more packages have systemd as a hard dependency.

snaky 10y ago
And that is not a coincidence > Well, it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there's really no point at all in doing so. > Due to that our plan is to enable all this by default in "make install". Packagers may then choose to disable it by doing an "rm" after the "make install", but we want to put the burden on the packagers, so that eventually we end up with the same base system on all distributions, and we put an end to senseless configuration differences between the distros for the really basic stuff. > If a distro decides that for example the random seed save/restore is not good enough for it, then it's their own job to disable ours and plug in their own instead. Sooner or later they'll hopefully notice that it's not worth it and cross-distro unification is worth more. https://lists.freedesktop.org/archives/systemd-devel/2010-September/000391.html https://lists.freedesktop.org/archives/systemd-devel/2010-Se...

naivepiano 10y ago

"There is also concern that it forms a system of interlocked dependencies, thereby giving distribution maintainers little choice but to adopt systemd as more user-space software come to depend on its components" from relative wikipedia article (https://en.wikipedia.org/wiki/Systemd https://en.wikipedia.org/wiki/Systemd). This does not sound any good.

petepete 10y ago

I don't think it's really all that bad; several big, popular, widely-deployed distributions are using it and most people appear to be getting on just fine. It's just that people against it are extremely vocal. I do dislike the idea of binary logs, though.

pas 10y ago
I like binary logs. They are faster, which is not a bad thing if you have to grep them. And easy to filter thanks to a fix metadata interface, and so on. journalctl could use some work, but it can just print JSON, and there's jq.
- petepete 10y ago
  Maybe my dislike for binary logs is because I haven't yet learnt the tooling around them. I'm familiar with dealing with text files in Linux/Unix land and have built up years of knowledge on doing so. I feel reluctant to throw that away.
fridsun 10y ago
People against it are extremely vocal because it is much harder to work around than previous stuff. Don't like PulseAudio? Use alsa directly is fine, I did in my Arch Linux box. Don't like Flash? HTML5 FTW. Don't like systemd? I have to go to FreeBSD altogether.

pmlnr 10y ago

Because it started small and OK. When distros made the decision to switch, it looked OK. It has proliferated into something else since then and none of the distros seems to be willing to take a step back.

digi_owl 10y ago
Problem there may be that going back means picking up maintenance on code that has been abandoned for years. There is a fork of Consolekit out there, Consolekit2, but they have to contend chasing logind's tail as most DEs have either stripped out their consolekit support, or it is suffering from severe bitrot.

coroutines 10y ago

systemd is a good thing (tm) - I recognize that and am grateful for it. However. In the beginning a lot of distros were "forced" to accept systemd because udev was merged into its codebase. Systemd is great, but its group of devs are absolutely fucking terrible at public relations. Sometimes they make changes that upset users. Like the recent one that has (logind?) by default killing all user-created processes when the user logs out (this surprised people as it became a new default). Or the security incident before that where systemd made it possible for users to get access to framebuffer contents. Sometimes things happen. It's just made worse when you go to the systemd group with your problem and they act like what they've done is correct and everybody should just live with it. Sometimes we're wrong, sometimes they're wrong. Poettering writes up these really long posts which are mostly good reads, but sometimes he calls us neckbeards who want to live in an unchanging, static past. Great project, great code, great devs - but terrible attitudes [sometimes].

Qantourisc 10y ago
"Great code" -> I am sorry, but if the allegations are true it's not great. (Not saying every part of it is bad, I kinda like the idea of systemd-init-part, but I describe them as utterly inconsiderate to everyone else.)
rwmj 10y ago
Gigantic thread on the KillUserProcesses setting: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZNQW72UP36UAFMX53HPFFQTWTQDZVJ3M/ https://lists.fedoraproject.org/archives/list/devel@lists.fe...
- digi_owl 10y ago
  Dear deity... https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TE2YM2PFMWSOJ3DYZ7JQOCTCQPJA3SRD/ https://lists.fedoraproject.org/archives/list/devel@lists.fe...
JdeBP 10y ago
It was indeed logind. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394#221 * https://news.ycombinator.com/item?id=11782364 https://news.ycombinator.com/item?id=11782364 The systemd developers' way of addressing that was to go and ask the people who wrote things like tmux to change tmux. The response of the tmux developers was to repeat the question asked and not answered 5 years ago. * https://news.ycombinator.com/item?id=11798515 https://news.ycombinator.com/item?id=11798515 * https://news.ycombinator.com/item?id=11797075 https://news.ycombinator.com/item?id=11797075 The problem where the people who just switched to Ubuntu 16 are hitting problems with high-end database servers, middleware, containers, large builds, and so forth all running out of threads because of another systemd default that was switched by its developers, is still quietly on-going. * https://news.ycombinator.com/item?id=11675129 https://news.ycombinator.com/item?id=11675129

sklogic 10y ago

Under a severe pressure from a vocal and extremely tribal minority, of course. There are no technical reasons to do it.

snassar 10y ago

I am not an Arch Linux developer, but I am a systemd user on Debian 8 and Arch Linux systems. Here is one answer from an Arch developer about why they adopted systemd: https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_a...

baldfat 10y ago
This was a GREAT answer. The problem is that this is not a factual argument but more an emotional argument. "From 2brainz (Former Arch Linux Developer for Init Scripts" > I was the primary maintainer for Arch's init scripts for a while and I can share a couple of thoughts. Arch's initscripts were incredibly stupid. In their first phase, there was a static set of steps that would be performed on every boot. There was almost no way to adjust the behaviour here. In their second phase, the configured daemons were started in order, which only meant that a init scripts were called one after another. In the early 2000s, that seemed like a good idea and has worked for a while. But with more complex setups, the shortcomings of that system become apparent. With hardware becoming more dynamic and asynchronous initialization of drivers in the kernel, it was impossible to say when a certain piece of hardware would be available. For a long time, this was solved by first triggering uevents, then waiting for udev to "settle". This often took a very long time and still gave no guarantee that all required hardware was available. Working around this in shell code would be very complex, slow and error-prone: You'd have to retry all kinds of operations in a loop until they succeed. Solution: An system that can perform actions based on events - this is one of the major features of systemd. Initscripts had no dependency handling for daemons. In times where only a few services depended on dbus and nothing else, that was easy to handle. Nowadays, we have daemons with far more complex dependencies, which would make configuration in the old initscripts-style way hard for every user. Handling dependencies is a complex topic and you don't want to deal with it in shell code. Systemd has it built-in (and with socket-activation, a much better mechanism to deal with dependencies). Complex tasks in shell scripts require launching external helper program A LOT. This makes things very slow. Systemd handles most of those tasks with builtin fast C code, or via the right libraries. It won't call many external programs to perform its tasks. The whole startup process was serialized. Also very slow. Systemd can parallelize it and does so quite well. No indication of whether a certain daemon was already started. Each init script had to implement some sort of PID file handling or similar. Most init scripts didn't. Systemd has a 100% reliable solution for this based on Linux cgroups. Race conditions between daemons started via udev rules, dbus activation and manual configuration. It could happen that a daemon was started multiple times (maybe even simultaneously), which lead to unexpected results (this was a real problem with bluez). Systemd provides a single instance where all daemons are handled. Udev or dbus don't start daemons anymore, they tell systemd that they need a specific daemon and systemd takes care of it. Lack of confiurability. It was impossible to change the behaviour of initscripts in a way that would survive system updates. Systemd provides good mechanisms with machine-specific overrides, drop-ins and unit masking. Burden of maintenance: In addition to the aforementioned design problems, initscripts also had a large number of bugs. Fixing those bugs was always complicated and took time, which we often did not have. Delegating this task to a larger community (in this case, the systemd community) made things much easier for us. I realize that many of these problems could be solved with some work, and some were already solved by other SysV-based init systems. There was no system that solved all of these problems and did so in a realiable manner, as systemd does. So, for me personally, when systemd came along, it solved all the problems I ever had with system initialization. What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. You can say what you want about Poettering, but he actually realized what the problems with system initialization were and provided a working solution. I could go on for hours, but this should be a good summary.

jpgvm 10y ago

Basically because RedHat has an obscene amount of clout in the ecosystem and can basically push through whatever they want. See here systemd, pulseaudio, lvm, selinux, kvm, many more. Some of these things are good, some of them are bad. The important thing is once RH has decided they want to take over another component of the ecosystem there isn't really a lot anyone can do. Not even Linus has been able to halt the systemd nonsense. Why do other distros cave? Well because RH controls most of the other important projects too and they go to great lengths to create integration that is unnecessarily difficult to decouple. For instance Gnome. Probably impossible to run without systemd now (or at least highly impractical). At the end of the day it has nothing to do with the technical merits of systemd and everything to do with how much power RH has to steamroll whatever solutions they want through.

baldfat 10y ago
> At the end of the day it has nothing to do with the technical merits of systemd and everything to do with how much power RH has to steamroll whatever solutions they want through. RedHat is a premium member of our community that has a well earned reputation which makes whatever they do get noticed. Why are they to be the focus of a witch hunt like if they were MicroSoft of the Steve Ballmer era? If these things didn't solve problem they wouldn't get used period. RedHat being an evil member of Linux seems almost comical. Linux has won the war and yes RedHat has been a key member in winning the technology war. I fail to see how all distros who can do whatever they want continue to chosen RedHat solutions over and over again? They make developers lives better and arguably Linux better. Canonical on the other hand continues to be a Linux community member that tries to compete with everyone else and doesn't contribute upstream as much as everyone else. I say it is good news now we can have less wasted work on different solutions. Why hasn't Canonical's projects caught on? They don't work as well or seen to not work as well as other solutions. Unity anyone? PulseAudio has been a HUGE success that so many talk down due to the rocky start of the project and the personality of the developer (Who also created SystemD) Audio in Linux was a huge mess prior to Pulse Audio. KVM - is the best virtual system bar none. lvm - I don't really need to defend this project? selinux - This was started by the NSA not RedHat
- 10y ago

rwmj 10y ago

systemd is many things. It's a sensible init system, better in some ways than upstart and lightyears ahead of SysV init. Its native support for confining daemons' process tree using cgroups is generally a good idea. But it's also a load of unrelated utilities like this one. Unfortunately if you get systemd as an init system, you generally get all this other stuff (unless you take steps to remove them, which in some cases is simple and in others is painful). Some of these utilities might be a good idea, but they should be separate projects, not bundled.

pmahoney 10y ago
As a daemontools fan, I'm frustrated that something in the daemontools family never became popular (process supervision, be it daemontools, upstart, systemd, etc. makes managing services so much nicer). But I do recognize the utility of using cgroups as part of this. Is there, or could there be, a "do one thing" utility that can launch a process in its own cgroup, such that it would fit in nicely in a daemontools-style run script?
- JdeBP 10y ago
  There indeed could be. (-:
  - JdeBP 10y ago
    Hey, presto! jdebp % cat /var/sv/epmd/service/run #!/bin/nosh #Run file generated from services/epmd.service #Erlang Port Mapper service move-to-control-group epmd.service setuidgid rabbitmq userenv epmd jdebp %

fridsun 10y ago

My 2 cents: init script wasn't a enough pain in the ass for people in charge to search for alternatives but still a pain, and systemd was introduced to them by Red Hat manpower. It seems good enough so they went with it. Actually, init script wasn't anyone's enough pain in the ass in Linux world save for djb. daemontools came out in 1997 and no one seemed to care. Systemd replaced those init scripts IMO only because they wrote all the replacement service files as well with the manpower at Red Hat's disposal. It's hard to match that from open source world.