Systemd, ten years later: a historical and technical retrospective

Re:Systemd, ten years later: a historical and technical retr... by Karunamon on Monday May 04, 2020 @12:01AM (#23064434)

My argument is remarkably simple.

1. Systemd did not solve any problems I actually had.

2. Systemd introduced problems that I did not have previously.

3. Systemd did not provide me any net benefit, that is, the few benefits it did provide over Upstart/SysV/etc. (easier service configuration and ordering) did not overshadow the issues it caused. Its introduction into my home and professional computing life has been a net negative.

[ Parent | on HN ]

Re:Systemd, ten years later: a historical and technical retr... by tpoindex on Monday May 04, 2020 @11:37AM (#23069279)

This, exactly.

My first experience with SystemD (Ubuntu 16.04 IIRC) turned into a frustrating experience, mostly around trying to mount a NFS volume in /etc/fstab, defined with 'soft' and 'bg' mount options. SystemD would often fail to mount the volume, and as a result would never fully boot to login prompt. Additionally, on shutdown SystemD would hang again forever trying to unmount that volume. No amount of mount option flag tweaking seemed to make much of a difference, so I simply removed the NFS volume from fstab and manually mounted when I needed it.

Happily running MX Linux today and back to mounting NFS in /etc/fstab.

[ Parent | on HN ]

Re:Systemd, ten years later: a historical and technical retr... by crazy_hombre on Monday May 04, 2020 @05:35AM (#23066059)

systemd did make package maintainer's lives a lot easier. We don't often see the shift to systemd from their perspective. They are the ones making the distros so I think they are the ones who really get to say what goes and doesn't go in a distro. They don't have to keep maintaining long init scripts for the hundreds of packages that they are responsible for. Unit files are so much easier to deal with.

[ Parent | on HN ]

[dead]

Re:Systemd, ten years later: a historical and technical retr... by Karunamon on Monday May 04, 2020 @12:39AM (#23064611)

Yes, my systems are primarily operated for my benefit. This should not be a controversial stance, and certainly not one worth hurling insults about.

>Seriously - don’t use it if you hate it so much.

Oh how I WISH that were a viable option. Few things would make me happier than that overcomplicated, opinionated, arrogant pile of unsafe code being excised viscera ex machnia from any system I have the misfortune of managing.

Sadly I'm stuck with it if I want to run any mainstream Linux distros.

[ Parent | on HN ]

Re:Systemd, ten years later: a historical and technical retr... by cycloptic on Monday May 04, 2020 @02:18AM (#23065093)

What benefit are you really getting from using mainstream distros if you find their choices to be so objectionable and don't agree with their decisions? And have you looked at the state of the kernel or at your CPU lately? I would really suggest not using Linux or any modern x86_64 processor if you are worried about "overcomplicated, opinionated, arrogant piles of unsafe code" at the lowest possible levels of your system.

[ Parent | on HN ]

Re:Systemd, ten years later: a historical and technical retr... by dTal on Monday May 04, 2020 @07:51AM (#23066874)

>What benefit are you really getting from using mainstream distros if you find their choices to be so objectionable and don't agree with their decisions?

Well, that's an easy one: popularity = support. I dislike Ubuntu these days, but I run LTS on my work machines because no matter what obscure program I might need in the course of my job, it will almost certainly run on Ubuntu. Build instructions will target Ubuntu. Prebuilt .debs will target Ubuntu. Static binaries, or AppImages, will have been tested on Ubuntu. I get a choice between "install the snap, or build from source?" I can install the snap and get on with my day.

It's not inherently better in a technical sense, it's just overwhelmingly easier to swim with the current.

[ Parent | on HN ]