[mdlug] Big brother gives M$ a 10 out of 10

[Jonathan Billings]

> On May 25, 2024, at 00:38, Ron / BCLUG <admin at bclug.ca> wrote:
> 
> Jonathan Billings wrote on 2024-05-23 13:43:
> 
>>>> However, the encroachment of systemd is beginning to threaten this OS model.
>>> Oh, look at that, you had the same thought
>> I’m curious, how does systemd threaten that OS model?
> 
> It doesn't.
> 
> 
> I've shared this excellent presentation from linux.conf.au called "The Tragedy of systemd", by Benno Rice - a FreeBSD developer, in which he debunks a lot of claims against it and even suggests BSD ought to have something similar (services management system):
> 
> https://www.youtube.com/watch?v=o_AIw9bGogo

I’ll start and say I’m a fan of systemd, I’m in agreement with most of your points here.

One of the arguments I hear against systemd is that SysV init is somehow more “pure” open source because it’s made up of a bunch of separate open source projects, all with their own developers with different release schedules and priorities.  FreeBSD has all its OS components (that make up its init) in a single source tree, release management much more centralized. I’m really not surprised FreeBSD devs would be more positive about systemd, although systemd itself is very Linux-focused.

Of course, that’s also why systemd, as an init system, helps the Linux world.  Before systemd, each distro had its own style of SysV init scripts, runlevels didn’t match, dependencies were based on numeric ordering which also were not consistent between distros, it was just a mess, and service developers had to create a Debian init script, a red hat init script, and whatever else came up. And don’t get me started with the terrible bash syntax used in init scripts.

> I don't think I have ever heard someone make a claim against systemd that hasn't been addressed in that video.
> 
> 
> Claims I have seen, like "systemd is a marketing scheme", and "all the idiots behind systemd came from Windoze [sic]" are not worth addressing.
> 
> 
> The claim that it's too complicated is quite subjective, and on a list dedicated to an advanced computer topics is kinda odd.
> 
> Pushing technology to make it easier to do more complicated tasks seems the essence of tech (to me).
> 
> 
> As for this:
> 
> > My rebuttal is that nobody needs that kind of complexity.
> 
> I'm pretty sure one doesn't get to claim "nobody needs" unless you've surveyed "everybody".  "I don't need" ≠ "nobody needs".
> 
> 
> 
> 
> Basically, there seems to be a form of digital Amish thinking going on: "tech was best back at $time and anything afterwards is too complicated / I don't need it so shouldn't exist / I don't wanna learn it".
> 
> 
> It's similar to "music was best when $teenager and everything after sucks".
> 
> 
> Also, a dash of cynicism masquerading as wisdom, couched in late stage Slashdot talking points.
> 
> 
> Still waiting to hear a good-faith argument against systemd that deals with the fact that Canonical and RedHat were *both* looking for a new services management system (Canonical with Upstart, which Suse and RedHat bundled briefly), strongly indicating some need for such a tool.

I was a Red Had sysadmin for years, and was surprised by the number of people who didn’t even *know* RHEL6 used upstart. When RHEL7 shipped with systemd, so many of my coworkers decried that SysV was so much better, and it blew their mind that they weren’t even using it anymore, and that SysV init scripts work fine in systemd.

I think the best argument I hear today is that systemd has scope creep.  They’ll concede that systemd is a good startup/init system, but it’s doing other things now.  However, I’ll argue that many of those things are to take advantage of a kernel feature (such as login management and resource management) or bootloader (which is to resolve a lot of issues with GRUB2), for example.

I also have a complaint about how systemd launches process as part of the login. Systemd launches a systemd --user process, which runs as the user, but it doesn’t descend from the user’s login process but instead the pid 1 systemd process, so it doesn’t inherit certain things from the login process that have traditionally been used by PAM modules, such as session keyrings. The systemd devs think it’s fine to just use user keyrings, but historically, services like Kerberos used session keyrings, so you could have multiple logins with different credential caches in a session keyring, and now systemd says that’s not possible. Kinda frustrating, but there are workarounds. 

-- 
Jonathan Billings