I agree although I still run systemd. I run both Debian (with systemd) and Devuan (a Debian fork with anything systemd removed). The reason I still run a systemd-less fork is to not forget that Linux still works fine without systemd.

Linux is not systemd.

I did actually write systemd services and I'm not sure the "convenience" warrants what Microsoft (and Poettering) are doing to Linux.

The only one true savior we still have is Linus and, so far, Poettering still hasn't found a way to control the kernel's development.

But Microsoft/Poettering already won PID 1 on most distros/installs and, although I run systemd on several machines (including servers), it is not good that PID 1 is lost. It simply isn't.

Even if there were no technical objections (but there are: gigantic attack surface, lame binary logs, bugs regularly tagged as "not bugs" because Poettering feels like they're not bugs, etc.), it's still a huge problem how this gigantic squid spreads its tentacle everywhere.

Anyone finding it totally normal that the person in charge of PID 1 works for Microsoft is totally delusional.

People should at least acknowledge there are reasons to be concerned about that.

And whether sysvinit scripts do actually suck or not has nothing to do with PID 1 being controlled by someone working for Microsoft.

Poettering didn't join Microsoft until 2022, systemd has been around since 2010.

True, but soon he will be dropping script integration, not that I care, but the coincidence is a interesting. Join M/S, drop shell scripts :)

Script integration is not dropped. You can easily run a script from a unit file.

Yea, they're dropping the native generator for /etc/init.d, I believe. Scripts placed here implicitly became systemd services.

Nothing of huge value is lost. Distributions play an important part, we shouldn't forget. They can maintain something like this for users, if so inclined.

This mostly hurts third party/ancient/naive packages that you probably, eventually, won't want to install on your distribution for other reasons.

This won't affect any packages natively provided by your distribution of choice. Think those random RPMs/DEBs you get from an external vendor -- UPS, keyboard, whatever.

They've had over a decade to see the writing on the wall, adding ~12 lines to their entire codebase/packaging spec. Probably a net-reduction given the NIH-syndrome of these scripts.

Instead, I've seen them make this directory, put their scripts inside, and just expect things to work out. It did, arguably by chance. The compatibility was deliberate, but support isn't forever.

That’s wild! I too have seen horror I wish I could forget.

For those still worried, the pain is limited to about 15 minutes of writing a unit file, testing it, and waiting for ci or builds to finish!

I expect to have to do this for older or more esoteric stuff, but I also enjoy writing unit files.

> I expect to have to do this for older or more esoteric stuff, but I also enjoy writing unit files

You can’t even do that as those are not deterministic.

I can’t do what? Write unit files for older applications? Because unit files? the applications? are not deterministic?

What a shit take.. system boot is a complex problem requiring a monolith solution, otherwise you just building some Rube Goldberg machine. The same way the kernel is a fucking huge monolith.

Also, what would be the point with Poettering? What does he gain from being constantly criticized by lunatics? Like honestly, these takes are some jewish space laser level ones.

I've ported dozens of services many production critical over to SystemD over several companies. The only thing I've ever had issue with is systemd-timesyncd. Otherwise, its been rock solid. What the hell are you doing that gives you so much trouble with SystemD

Ditto, much success with systemd here.

The 'overreach' people complain about exists for a good reason. Services need mounts/networks/etc to actually do their job reliably.

If people could discard the 'nyeh' sentiment, use recent releases, and actually engage with the system, they can only find more reliability.

What was once tailored in scripts for each service/job/whatever is now provided by the system

It's about clearly laying out dependencies. Not a lot more.

The only bad experience I've had with systemd is on Ubuntu 18; where I've been forced at work. It's common for systemctl daemon-reexec to be needed, to resuscitate it. It's woefully far behind.

18.04 is EOL! unless they're paying for that extended support, it's time to upgrade

I should've probably mentioned this, but we've got that covered! ESM until we can finish our move to the New Home

I appreciate the mention though, never know how long people intend to keep things running.

Huh. Since learning more about systemd my frustration with IT related tasks has gone way down.

Unit files are far more functional for the same amount of effort as SysV scripts.

beyond init and udev script cobbling, I've recently plunged deep into networkd and resolved for the heck of it, discovered networkctl and resolvectl in the process, and it's been a very pleasant experience so far, making easy things trivial and hard things easy.

It really has made things much easier after a slightly frustrating knowledge speed bump.

Unit files seem like a good idea. Does systemd need to do everything it does in order to gain that benefit?

Yes? People don't realize that systemd is a project, and systemd the init system isn't journald or systemd-boot or systemd-resolved. Those are other compatible utilities by the same project. They aren't required to use systemd itself.

Many of the systemd components are separate and optional. You can easily eschew from systemd-timesyncd and systemd-resolved, for example.

Not entirely, for example:

Units can depend on networking managed outside of systemd-networkd using the target -- think of this as a 'run level'

Units can depend on mounts outside of systemd .mount units -- there's a generator that considers fstab

At a certain point, you might want to go further into systemd... but it doesn't require it.

The basic 'this service wants/needs these other ones' is very self-contained, and inherits a lot.

Yes. It needs to know what mounts and networks are needed for my various services. It needs to be sure the system is synced with NTP before moving past a certain point. And so on.

I took the opposite route, accepting defeat and embracing systemd. My purist self doesn’t like it, but my pragmatic self is happy and cannot be bothered by all the people complaining about it.

I find systemd amazing, and worlds better than sysvinit. I'll be happy to never admin a sysvinit box again!

I don't know how I feel about the implication that sysvinit ever did something that could be called "working".

I'm curious what alternative you make use of.

My issue has been that getting an alternative set up was just painful enough that the related learning doesn't fit into a very full schedule.

What kind of frustrations has systemd caused you? I know there are a lot of very valid criticisms of it, but the only time I’ve experienced actual frustration is when I’m fighting with the timer syntax that I can never seem to memorize.

Besides Nix, it’s the easiest way I’ve found to declaratively define a system that just works.

But how can I do that if I like Archlinux for the rest but everything around is based on Systemd, and most other distros also do that?

Try Artix Linux instead! It's essentially Arch, but with an alternative unit system.

I would also have no IT related problems if my computer wouldn’t boot..