4 ms·

> The hate largely stems from the way it was rolled out - the linux community at large was left feeling like it had been told it wold adopt this, and there was

> The hate largely stems from the way it was rolled out - the linux community at large was left feeling like it had been told it wold adopt this, and there was no choice, and that rubbed a lot of people up the wrong way. It wasn't just a feeling, it really was just like that. Had the architecture of Systemd been different, it would have been possible to decouple it from other components and be able too choose an init system just like in the not so distant past. As it is now, practically speaking there is no choice.

bayindirh 8y ago
Doesn't Debian support[0] init system switching? Just curious. [0]: https://wiki.debian.org/Init https://wiki.debian.org/Init
- rosser 8y ago
  It does, but packages aren't obligated to provide sysvinit scripts for your non-systemd-using convenience. Over time, the number of packages that do will fall, because engineer convenience and cognitive bandwidth are incredibly high priorities; "that's the crusty old way while this is the new hotness"; and, "oh, but we need this one little thing systemd offers," &c. And before you know it, those of us on the ops side are stuck supporting something we loathe, and having to rewrite a bunch of scripting and tooling in response to discovering new and exciting ways the "new hotness" ends up breaking things that worked perfectly well until it came along. Literally, we're facing another iteration of that very cycle right now: our non-production environment refresh process suddenly fails to complete without being manually thumped at multiple points. Why? System fucking d. But no: "It works fine for us, so it can't be a problem for anyone else, right? Right?"
  - craigsmansion 8y ago
    Debian recently reached out to Devuan for sysvinit maintenance. Devuan has, in spite of a somewhat acrimonious start, delivered what they set out to do, a Debian without SystemD, so it might be worth consideration when dist-upgrading.
  - majewsky 8y ago
    > Over time, the number of packages that do will fall, because engineer convenience and cognitive bandwidth are incredibly high priorities; "that's the crusty old way while this is the new hotness"; and, "oh, but we need this one little thing systemd offers," &c. The thing that many people don't understand about systemd is that they don't have to sell to users or developers, they have to sell to (and design for) distributors. Lennart and Kay know that because they are both working for distributors (Redhat and Suse, respectively). To distributors, the promise of systemd is the promise of less integration work. It paves over a ton of useless idiosyncracies in distributions (e.g. compare systemd's /etc/os-release with the previous /etc/*-release files that you cannot even call by name because they were called something else on each distribution). Initscripts is the biggest bullet point in that list: Initscripts were always written by the distribution because each distribution had their own scripting layer on top of sysvinit to make it a bit nicer, and each of these was incompatible with those of other distributions. Systemd units, on the other hand, can be maintained by the application developers themselves, and several distros (e.g. the patch-hating Arch Linux) actively pushes systemd units upstream. When the application developer takes care and has only one target (the de-facto standards forced by systemd), life gets a whole lot easier for distributors. And that's why distributors choose systemd.
    - dvfjsdhgfv 8y ago
      Well, it doesn't explain why Debian gave in. They're supposed to listen to the people, aren't they?
      - bayindirh 8y ago
        They have listened to the people. Systemd has selected as a result of a poll [0]. [0] https://people.debian.org/~stapelberg/2013/05/27/systemd-survey-results.html https://people.debian.org/~stapelberg/2013/05/27/systemd-sur...
        craigsmansion 8y ago
        SystemD was selected by the Technical committee, which was very far from unanimous in the decision. SystemD caused problems at the time and there was no reason not to postpone the decision to Jessie+1, which is what Debian usually does in such cases: "more discussion needed". Debian broke their social contract, showing that their priority was no longer with their users.
  - bayindirh 8y ago
    You're right, I didn't take the scripts part into consideration, also the problem of breaking pipelines is real, there's no doubt about that. However, dividing teams into developers and (Dev)Ops sides like warring factions is not healthy. I'm also an ops guy (more precisely a sysadmin who supports a lot of users and servers) in my day job, and a I develop stuff for academic world and for my own pleasure in my free time, so I know both sides of the so-called moat. Using features because they're hot is not also OK for any application, but not using features which can solve real problems is unwise in my book. We also had hacks which were working perfectly fine until systemd came. We evolved, changed how we do things and moved along. > "It works fine for us, so it can't be a problem for anyone else, right? Right?" I didn't want to tell or imply anything resembling this. I just gave my own opinion, based on my experience.
  - JdeBP 8y ago
    The Debian people were discussing what package maintainers are obligated to provide just a month ago. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911165 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911165
krylon 8y ago
Fwiw, some distros have stuck with different init systems: Void uses runit, Devuan (Debian fork) uses sysvinit, Gentoo uses OpenRC[1]. There are probably more that I am not aware of. Systemd has not given me any trouble, yet, but I run Void in a VM, and it boots extremely fast. [1] I believe one can also use different init systems on Gentoo, after all it is Gentoo, but I have not touched it in years, so I do not know for sure.

bayindirh 8y ago

Doesn't Debian support[0] init system switching? Just curious. [0]: https://wiki.debian.org/Init https://wiki.debian.org/Init

rosser 8y ago
It does, but packages aren't obligated to provide sysvinit scripts for your non-systemd-using convenience. Over time, the number of packages that do will fall, because engineer convenience and cognitive bandwidth are incredibly high priorities; "that's the crusty old way while this is the new hotness"; and, "oh, but we need this one little thing systemd offers," &c. And before you know it, those of us on the ops side are stuck supporting something we loathe, and having to rewrite a bunch of scripting and tooling in response to discovering new and exciting ways the "new hotness" ends up breaking things that worked perfectly well until it came along. Literally, we're facing another iteration of that very cycle right now: our non-production environment refresh process suddenly fails to complete without being manually thumped at multiple points. Why? System fucking d. But no: "It works fine for us, so it can't be a problem for anyone else, right? Right?"
- craigsmansion 8y ago
  Debian recently reached out to Devuan for sysvinit maintenance. Devuan has, in spite of a somewhat acrimonious start, delivered what they set out to do, a Debian without SystemD, so it might be worth consideration when dist-upgrading.
- majewsky 8y ago
  > Over time, the number of packages that do will fall, because engineer convenience and cognitive bandwidth are incredibly high priorities; "that's the crusty old way while this is the new hotness"; and, "oh, but we need this one little thing systemd offers," &c. The thing that many people don't understand about systemd is that they don't have to sell to users or developers, they have to sell to (and design for) distributors. Lennart and Kay know that because they are both working for distributors (Redhat and Suse, respectively). To distributors, the promise of systemd is the promise of less integration work. It paves over a ton of useless idiosyncracies in distributions (e.g. compare systemd's /etc/os-release with the previous /etc/*-release files that you cannot even call by name because they were called something else on each distribution). Initscripts is the biggest bullet point in that list: Initscripts were always written by the distribution because each distribution had their own scripting layer on top of sysvinit to make it a bit nicer, and each of these was incompatible with those of other distributions. Systemd units, on the other hand, can be maintained by the application developers themselves, and several distros (e.g. the patch-hating Arch Linux) actively pushes systemd units upstream. When the application developer takes care and has only one target (the de-facto standards forced by systemd), life gets a whole lot easier for distributors. And that's why distributors choose systemd.
  - dvfjsdhgfv 8y ago
    Well, it doesn't explain why Debian gave in. They're supposed to listen to the people, aren't they?
    - bayindirh 8y ago
      They have listened to the people. Systemd has selected as a result of a poll [0]. [0] https://people.debian.org/~stapelberg/2013/05/27/systemd-survey-results.html https://people.debian.org/~stapelberg/2013/05/27/systemd-sur...
      - craigsmansion 8y ago
        SystemD was selected by the Technical committee, which was very far from unanimous in the decision. SystemD caused problems at the time and there was no reason not to postpone the decision to Jessie+1, which is what Debian usually does in such cases: "more discussion needed". Debian broke their social contract, showing that their priority was no longer with their users.
- bayindirh 8y ago
  You're right, I didn't take the scripts part into consideration, also the problem of breaking pipelines is real, there's no doubt about that. However, dividing teams into developers and (Dev)Ops sides like warring factions is not healthy. I'm also an ops guy (more precisely a sysadmin who supports a lot of users and servers) in my day job, and a I develop stuff for academic world and for my own pleasure in my free time, so I know both sides of the so-called moat. Using features because they're hot is not also OK for any application, but not using features which can solve real problems is unwise in my book. We also had hacks which were working perfectly fine until systemd came. We evolved, changed how we do things and moved along. > "It works fine for us, so it can't be a problem for anyone else, right? Right?" I didn't want to tell or imply anything resembling this. I just gave my own opinion, based on my experience.
- JdeBP 8y ago
  The Debian people were discussing what package maintainers are obligated to provide just a month ago. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911165 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911165

krylon 8y ago

Fwiw, some distros have stuck with different init systems: Void uses runit, Devuan (Debian fork) uses sysvinit, Gentoo uses OpenRC[1]. There are probably more that I am not aware of. Systemd has not given me any trouble, yet, but I run Void in a VM, and it boots extremely fast. [1] I believe one can also use different init systems on Gentoo, after all it is Gentoo, but I have not touched it in years, so I do not know for sure.