News for hackers. Stuff that matters.
Re:Systemd, 10 years later: a historical and technical retro... by 7bit on Tuesday August 06, 2024 @06:41PM (#41176222)
Man I love systemd. Never has it been easier for me to setup a binary as a service. I dread the memories of customizing or writing init scripts and dependencies.

I don't get all the hate, that primarily argues about the philosophy of Linux, when the philosophy made everything just harder..but I guess some people just want to suffer for their believes, mich like some Catholics

Re:Systemd, 10 years later: a historical and technical retro... by chronid on Tuesday August 06, 2024 @07:11PM (#41176497)
The "hate" was not about the philosophy of linux.

It was about the udev/systemd maintainers writing "fuck you Gentoo developers" in a mailing list when they wanted udev to support only systemd, actually that udev should be part of systemd (for no real reason) and reimplementing things (sometimes badly for years) instead of reusing what was in place. It was about pretty big bugs (I remember a bug around coredumps being cut at ~700MB in size, which the systemd maintainers responded with the equivalend "well that's your problem not ours, journald is not fast enough and so we cut the max size" and was only closed eventually - ~3 years - probably because some RH customer screamed loudly enough). And the original discussions were even before systemd decided to hardcode what essentially is random IP addresses into resolved ("maintainers should change those values if they don't like them!") and other network services (NTP? I don't remember now anymore). It was about the billion libraries (later on there have been some security fun issues) it brought in and made your stuff link to (I vaguely remember something to parse qr codes?). It was about not-documented DBUS interfaces and making DBUS a core part of the system...

Most complex services still had heavy, long prestart script written in bash anyway at that point in time even when using systemd, so the script complexity was not really gone (and I think postgresql for example still has something like that).

Now, Redhat pushed hard for it and you cannot just ignore what they do and go your own way since the number of maintainers they employ is massive along the entire stack, from kernel to GNOME - Systemd was convenient to use and people went for it even with all the issues it had/has for good reasons (same as pulseaudio), but thinking the only discussion at the time was about the "linux philosophy" is a strawman and changing history a fair bit. :)

Re:Systemd, 10 years later: a historical and technical retro... by palata on Tuesday August 06, 2024 @06:53PM (#41176316)
I hate that "modern" developers think Linux == Ubuntu and write software that only supports Ubuntu. Same thing for systemd.

"But it is just harder to learn how to write proper software that would work on a machine slightly different than my own"...

Re:Systemd, 10 years later: a historical and technical retro... by Spivak on Tuesday August 06, 2024 @07:03PM (#41176412)
What does "proper software" have to do with systemd? Sometimes upstream provides unit files but normally it's on the packager to provide the integration into your distro.

I've seen some software depend on libsystemd for the sd_notify but I think after the whole security kerfuffle there won't be many of those anymore.

Re:Systemd, 10 years later: a historical and technical retro... by lmm on Tuesday August 06, 2024 @10:53PM (#41177808)
> Never has it been easier for me to setup a binary as a service. I dread the memories of customizing or writing init scripts and dependencies.

If you just wanted simple/easy init scripts you could do that with runit for years without having to switch dozens of unrelated system components over to the systemd-approved version and render your system unbootable every so often.

Re:Systemd, 10 years later: a historical and technical retro... by jeltz on Wednesday August 07, 2024 @04:30AM (#41179364)
And that is a fair point. Sysvinit on the other hand was a total mess with almost all services being broken in some way.