12 ms·

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,

by 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
        > SystemD was selected by the Technical committee, which was very far from unanimous in the decision. I didn't know that. I thought the poll was open to anyone to vote for the relevant time window. > Debian broke their social contract, showing that their priority was no longer with their users. Isn't this a little bold claim? AFAICS, the poll has spotted the potential problems and general grievances pretty well (like binary logs, etc.), and concluded that these reservations should be addressed before systemd has included in Debian? I'm not trying to defend systemd here. As I said in my comments, I disliked it first, and then I learnt and got used to it. My teammates has shown bigger reactions to it, and then they liked it too, after we configured it to behave the way we like. I didn't migrate to systemd voluntarily. It fell from above on me in a pretty hard way.
        JdeBP 8y ago
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

by rosser 8y ago

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
      > SystemD was selected by the Technical committee, which was very far from unanimous in the decision. I didn't know that. I thought the poll was open to anyone to vote for the relevant time window. > Debian broke their social contract, showing that their priority was no longer with their users. Isn't this a little bold claim? AFAICS, the poll has spotted the potential problems and general grievances pretty well (like binary logs, etc.), and concluded that these reservations should be addressed before systemd has included in Debian? I'm not trying to defend systemd here. As I said in my comments, I disliked it first, and then I learnt and got used to it. My teammates has shown bigger reactions to it, and then they liked it too, after we configured it to behave the way we like. I didn't migrate to systemd voluntarily. It fell from above on me in a pretty hard way.
      - JdeBP 8y ago

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