I think we are witnessing the software equivalent of Planck's Principle.

Parallel startup? Who cares with the hardware speeds we have today.

I care a lot about this on my laptop. It makes a significant difference.

I argue that anything that systemd does, you can write an init script that does the same job with around 1 million less lines of code, less bugs, less attack surface, and 50-75% less processes running in RAM.

And I'd argue that you're wrong. Does the average sysadmin write init scripts with the same care that software developers (are supposed to) take when they write software? That is, using version control, writing tests, having code reviews, etc? Maybe some do, like around 1% of them. Most spit out a script and never look at it again as long as it "works".

In my opinion, the less code an admin has to write to get things done, the better.

When every Linux distro that matters is using systemd, it's not much of a lock-in.

And guess what? I distribute email-filtering software that runs on a wide variety of UNIX systems. I include sysvinit scripts for systems that use that, and systemd units for ones that use systemd. There's no lock-in.

OK, so you disagree with my point 3. How about the other 5 points?

So much wrong.

Devuan is free and you no have dependencies on suppliers

So Devuan ships zero packages from third-party suppliers? That's a hot take.

Uses less energy because less is running in memory

Another hot take. A program sitting in memory uses essentially no energy unless it's scheduled to run.

One of my recent email servers, with dovecot 2.4 and postfix, has only 121 running processes.

My Raspberry Pi server running dovecot and postfix has 247 processes, but it also runs PostgreSQL, Asterisk, an IRC server, a mattermost-to-irc bridge, home automation software, Pi-Hole, Xymon, nginx, and a bunch of other things. If I do: ps auxww|grep -c [s]ystemd the answer is 9. Oh the horrors! 9 whole processes!!!!

Finally, I think you'll find that in most cases, systemd machines are not slower than non-systemd ones, and in my experience, they boot quite a bit faster.

Yes, I obviously have a lack of engineering skill... hmm... M.Eng in Electronics; seven engineering patents to my name; retired on the proceeds of selling a successful software company... yeah, that's it. Low skill for sure.

LOL. It's so funny how insecure people get personal instead of actually discussing technical merits.

Everyone is a "guy" dude. You aren't special man.

In case it's not obvious, about 50% of people are not "guys". I guess sysvinit folks are not great at seeing cases outside their own experience. :)

Change just for the sake of change isn't a good thing.

Yes, I agree. However, on balance, I think systemd (or something like it) is a good change for a number of reasons I've outlined in other posts:

1. Easy ability to do dependency management.
2. Ability to start services in parallel (which flows from 1).
3. Remove the necessity for every service to write its own daemonization code; you can just let systemd do it for you.
4. Standard way to run services as a non-root user
5. Standard way to use newer Linux features like cgroups and namespaces.
6. Standard commands for monitoring and controlling the status of a service.

All of those things can be (and probably have been) implemented in sysvinit environments, but usually as hacks. systemd at least standardizes the procedures and reduces the amount of hacky sysvinit code support required.

OMG, lookit the triggered snowflake! LOL. A whole paragraph to whine about a simple two-letter spelling correction.

Meh, whatever. If you don't want to use systemd, that's fine. But debate it on its merits, not because its author has an abrasive personality or because it doesn't follow some nebulous "UNIX philosophy".

A few things that are hard to do with sysvinit scripts: Parallel startup, dependency management, and management of running services. Also, every service has to duplicate the bits of code needed to properly daemonize a service under UNIX, instead of having the service manager do it for them. Glibc does have a daemon library function, but it is non-standard.

There are hacky or ad-hoc solutions for all of these things, but they no longer really resemble the "simple" sysvinit scripts of the past.

I remember when people joked that Emacs stood for "Eighty Megs And Constantly Swapping"

*sob* VSZ of a current Emacs at startup is about 740MB and RSS is over 90MB.

But I still use Emacs. My muscle memory goes back 36 years and it's not going to change.

So when you say "we -- the people who've been working in this field for many decades", note that I have been developing software as a hobby since 1982 and professionally since 1990, and ran a software development company for 18 years. I think I'm likely as "seasoned" as anyone on Slashdot.

Second: If you say: "We considered it carefully, we debated it at length, and we rejected it.", then why is it that most Linux systems use systemd, Solaris uses smf, and Mac OS uses launchd, all of which are systemd-like things?

I think only the BSDs still use rc scripts and even then, they don't use sysvinit scripts, AFAIK, because they are not System-V. I didn't see a whole lot of anger when Linux went with sysvinit scripts instead of the conceptually-simpler BSD rc system.

I think you are tilting at windmills. Or telling the kids to get off your lawn. Times change; software evolves; might as well get used to it.

No, probably not. Most people have made their peace with systemd and I think it'll persist.

But you are not making sense. (And it's "Her", by the way, not "Him".)

As the person I replied to pointed out, if systemd doesn't quite do what you need, you can always fall back on a script. So the common use cases are easy and the uncommon ones are possible.

Now I personally have not encountered a use case that systemd couldn't handle natively, but I'm willing to admit that such use cases exist, in which case... you use a script that you call from a systemd unit. Problem solved.

I never began as a "proprietary UNIX guy" for two reasons; one is that I'm not a guy and second is I used SunOS and Solaris mostly as a student and a little bit on the job, and this was back in the day before SMF, etc. when the system was much more BSD-like.

The problem with appealing to "the UNIX way" is that nobody really knows what that is, beyond a few vague generalities. Systemd itself is not one monolithic program, by the way. It consists of 38 small purpose-built executables (on Debian 13, anyway), all of them under 1MB in size. Though I guess they do dynamically link to a bunch of other stuff.

I'd say a lot of small purpose-built tools is "the UNIX way"

Anyway, I'd rather use a system that accepts changes than one that's doctrinaire and rigid and becomes ossified.