4 ms·

Regardless of whether one likes or dislikes systemd itself, I think that unfortunate debacle can only be seen as causing harm to the entire Debian project. The

Regardless of whether one likes or dislikes systemd itself, I think that unfortunate debacle can only be seen as causing harm to the entire Debian project. The politics of it certainly generated a lot of distrust and resentment among the users and contributors. The project's reputation was undoubtedly hurt. Perhaps most importantly where the technological impacts. It's one thing when a user can generally ignore the politics surrounding a Linux distro, and the software still does what it needs to do. It's another matter when one routine update after another causes their computer(s) to no longer boot, among other serious problems, all thanks to systemd. Users definitely notice incidents like that, and it decreases, or even eliminates, their trust. So much hard-earned and invaluable goodwill was unnecessarily lost during and after that period of time. If any good did arise from that situation, it was that more people became aware of the BSDs, or tried them again if they'd used them in the past. FreeBSD and OpenBSD saved users who needed the reliability and trustworthiness that Debian used to offer, before systemd negatively affected the quality of Debian.

Aeolos 3y ago
> before systemd negatively affected the quality of Debian Is there any publication quantifying this? I followed the whole debacle with interest, and my personal experience with my servers was the exact opposite: adopting systemd improved reliability and made administration significantly easier. It's sad that this was politicized by a small part of the community, but the end result was worth it.
- dietrichepp 3y ago
  Yeah, I agree. Systemd is incredibly controversial among a niche group of people who have strong opinions about how init & core system functionality should work, and then there’s an outer ring of people who focus on one or two problems with some relatively minor problems that Systemd caused for which there are viable workarounds. Like how Systemd terminates processes that belong to your session when you log out. I remember writing SysV style init scripts or rc.d / BSD style init scripts. It was awful. You had all these copy-pasted shell scripts with various gaps in functionality depending on who wrote them. Getting a service to run in Systemd feels like heaven by comparison. I don’t even care about, like, Docker. I think the reports of problems (like background processes getting termed on logout, how any security problems in Systemd tends to be severe by nature) were just so numerous compared to the reports of the benefits (like the boot time improvements and the massive improvements running daemons). It was some bad decisions and a lot of bad PR, but the overall impact IMO is very positive.
  - SoftTalker 3y ago
    Have you looked at OpenBSD? Here's the /etc/rc.d/sshd: #!/bin/ksh # # $OpenBSD: sshd,v 1.7 2022/08/29 19:14:25 ajacoutot Exp $ daemon="/usr/sbin/sshd" . /etc/rc.d/rc.subr pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*" rc_configtest() { ${daemon} ${daemon_flags} -t } rc_cmd $1 Pretty much any service/daemon is similar. You define a few things and you're done.
    - abenga 3y ago
      A declarative unit file is still more readable for me.
    - unixhero 3y ago
      Why in the world korn shell? I stumbled upon an auditor with programming skills, who did all his scripting in Korn shell. To me it was like he was from another planet.
      - SoftTalker 3y ago
        It's the standard shell on OpenBSD.
    - Aeolos 3y ago
      Here is the systemd unit for comparison: [Unit] Description=OpenBSD Secure Shell server per-connection daemon After=auditd.service [Service] EnvironmentFile=/etc/default/ssh ExecStart=/usr/sbin/sshd -i $SSHD_OPTS StandardInput=socket I leave it to the reader to decide which of those two is easier to understand and maintain.
      - SoftTalker 3y ago
        Debatable, but I was mainly reacting to "... rc.d / BSD style init scripts. It was awful. You had all these copy-pasted shell scripts with various gaps in functionality depending on who wrote them." Simply not true in (modern) BSDs, well at least OpenBSD; I'm not familiar with the others.
- VancouverMan 3y ago
  When I was trying to resolve the numerous problems that systemd was causing for me on multiple computers that Debian had previously worked perfectly fine on, I certainly ran across a lot of bug reports, mailing list postings, forum postings, IRC logs, blog articles, and other online communications from people who were also having problems with systemd. Beyond that, I've heard of enough problems involving systemd from my Debian-using colleagues and acquaintances, too. I don't know if it's been formally studied in any way, but it was clear to me that I definitely wasn't alone in experiencing problems involving systemd. The widespread negative sentiment that exists toward systemd, including from well beyond the Debian community, didn't just come out of nowhere. From what I can see, it was generated thanks to a lot of people directly experiencing a lot of unnecessary problems caused by systemd.
nolist_policy 3y ago
Sigh.
klysm 3y ago
I’m pretty convinced it was net positive in the long term. If Debian hadn’t gone with systemd, then where would it be today? Stuck in shell script hell?
- gorgoiler 3y ago
  We would have been forced to bite the bullet and implement a packaging extension that allowed debs to describe what to start at boot time, when, and how. The compatability layer would have allowed any init system to be used. Instead we welded the systemd engine into the chassis and pray that when it comes to replacing it we aren’t the ones on the hook.
  - klysm 3y ago
    > The compatability layer would have allowed any init system to be used. I don’t see how such a compatibility layer would work in a way that doesn’t suck horribly.

Aeolos 3y ago

> before systemd negatively affected the quality of Debian Is there any publication quantifying this? I followed the whole debacle with interest, and my personal experience with my servers was the exact opposite: adopting systemd improved reliability and made administration significantly easier. It's sad that this was politicized by a small part of the community, but the end result was worth it.

dietrichepp 3y ago
Yeah, I agree. Systemd is incredibly controversial among a niche group of people who have strong opinions about how init & core system functionality should work, and then there’s an outer ring of people who focus on one or two problems with some relatively minor problems that Systemd caused for which there are viable workarounds. Like how Systemd terminates processes that belong to your session when you log out. I remember writing SysV style init scripts or rc.d / BSD style init scripts. It was awful. You had all these copy-pasted shell scripts with various gaps in functionality depending on who wrote them. Getting a service to run in Systemd feels like heaven by comparison. I don’t even care about, like, Docker. I think the reports of problems (like background processes getting termed on logout, how any security problems in Systemd tends to be severe by nature) were just so numerous compared to the reports of the benefits (like the boot time improvements and the massive improvements running daemons). It was some bad decisions and a lot of bad PR, but the overall impact IMO is very positive.
- SoftTalker 3y ago
  Have you looked at OpenBSD? Here's the /etc/rc.d/sshd: #!/bin/ksh # # $OpenBSD: sshd,v 1.7 2022/08/29 19:14:25 ajacoutot Exp $ daemon="/usr/sbin/sshd" . /etc/rc.d/rc.subr pexp="sshd: ${daemon}${daemon_flags:+ ${daemon_flags}} \[listener\].*" rc_configtest() { ${daemon} ${daemon_flags} -t } rc_cmd $1 Pretty much any service/daemon is similar. You define a few things and you're done.
  - abenga 3y ago
    A declarative unit file is still more readable for me.
  - unixhero 3y ago
    Why in the world korn shell? I stumbled upon an auditor with programming skills, who did all his scripting in Korn shell. To me it was like he was from another planet.
    - SoftTalker 3y ago
      It's the standard shell on OpenBSD.
  - Aeolos 3y ago
    Here is the systemd unit for comparison: [Unit] Description=OpenBSD Secure Shell server per-connection daemon After=auditd.service [Service] EnvironmentFile=/etc/default/ssh ExecStart=/usr/sbin/sshd -i $SSHD_OPTS StandardInput=socket I leave it to the reader to decide which of those two is easier to understand and maintain.
    - SoftTalker 3y ago
      Debatable, but I was mainly reacting to "... rc.d / BSD style init scripts. It was awful. You had all these copy-pasted shell scripts with various gaps in functionality depending on who wrote them." Simply not true in (modern) BSDs, well at least OpenBSD; I'm not familiar with the others.
VancouverMan 3y ago
When I was trying to resolve the numerous problems that systemd was causing for me on multiple computers that Debian had previously worked perfectly fine on, I certainly ran across a lot of bug reports, mailing list postings, forum postings, IRC logs, blog articles, and other online communications from people who were also having problems with systemd. Beyond that, I've heard of enough problems involving systemd from my Debian-using colleagues and acquaintances, too. I don't know if it's been formally studied in any way, but it was clear to me that I definitely wasn't alone in experiencing problems involving systemd. The widespread negative sentiment that exists toward systemd, including from well beyond the Debian community, didn't just come out of nowhere. From what I can see, it was generated thanks to a lot of people directly experiencing a lot of unnecessary problems caused by systemd.

nolist_policy 3y ago

Sigh.

klysm 3y ago

I’m pretty convinced it was net positive in the long term. If Debian hadn’t gone with systemd, then where would it be today? Stuck in shell script hell?

gorgoiler 3y ago
We would have been forced to bite the bullet and implement a packaging extension that allowed debs to describe what to start at boot time, when, and how. The compatability layer would have allowed any init system to be used. Instead we welded the systemd engine into the chassis and pray that when it comes to replacing it we aren’t the ones on the hook.
- klysm 3y ago
  > The compatability layer would have allowed any init system to be used. I don’t see how such a compatibility layer would work in a way that doesn’t suck horribly.