First one on the list.

% readelf -d /usr/bin/bootctl | rg -r '$1' '.*NEEDED.*\[(.*)\]'
libsystemd-shared-262-1.so
libgcc_s.so.1
libc.so.6

Are you familiar with the concept of shared libraries? Please, stop embarrasing yourself.

How ironic!

Now post the output:

ls -ld /run/systemd/io.*

Chromium is open source. Google is evil.

"Fork it, grandpa!"

I pulled it from Github. Full disclosure, the experiment isn't going well, but I'm determined to see how far I can take it.

I don’t think systemd is an improvement.

Hardly any of the core systemd people work at Redhat these days. Microsoft employs more of them then Redhat. Right now I think Lennarts new company employes several of the key systemd people.

Contributions are comming in from all major distributions though.

So why bother about making init tools portable? You end up with a tool that works poorly on all OSes and nobody needs more of that.

Of course there are dependencies. They all are tools that do one thing well amd call into other tools to do thenthings those tools were built to do. E.g. many need systemd-init to function as that is the tool to manage the livetime of services running on the system.

How boring.

Will you ever get to the point where you say clearly why exactly bootctl isn't a separate utility? No, having dependencies doesn't make something not a separate utility. And no, communicating with systemd daemon over unix sockets doesn't as well.

Even if OpenRC is not widely adopted it is a commitment from Gentoo to build their package recipes in a way that’s portable across different init systems. Keeping options open is healthy and I think one of the coolest things about Linux ecosystem historically was that there were at least two non-halfassed options for most of the system components. This also helps out little guys like BSDs who benefit from portability issues Gentoo package maintainers raise upstream.

That's a false equivalence and you know it

Good.

So the tool YOU chose is NOT:

• standalone at the project level ✅
• standalone at the repo level ✅
• standalone at the source level (trivially shown with the libsystemd-shared.so dep without requiring looking further) ✅
• standalone/fully independent at the runtime level ✅

This and the sibling sub-thread where I mentioned presets show with actual facts how the systemd forced hegemony actually works, where it's not just a simple case of "they just have some stand-alone cli tools under their umbrella bro".

The project itself wouldn't try to (clumsily) dispute this either, since it's at the core of what they consider a selling point; interface unification and deeper integration with the system.

So, you've demonstarted nothing and all your points were refuted. Then you've made up a list with checkmarks and proudly proclamed yourself right? 😮‍💨

No, it's not. It's a great equivalence, even.

IMHO supporting several init tools does more harm than good to any distribution. Its a lot of extra effort that few users will even notice.

Traditionally we used a script to boot. Those of course looked different in each distribution, but the "init tool" was the same. Then we switched over to sysv init (and man did people complain about this overcomplicated mess of symlinks!), yet pretty much all distributions switched to that. Of course they shipped widely different init scripts, but the tool was pretty much the same everywhere. The Linux Standard Base even prescribed the sysv init and any compliant distribution had to use that. We never had a time where distributions offered options wrt. init tooling.

I doubt the portability issue reporting from gentoo makes any difference whatsoever for the BSDs. They come up with all kinds of Linux compatibility stuff and that gets them the software they want.

I use alpine and freebsd. I want full control of me PC/server. And many times, I need DIY unusual setups. Systemd is way too complex to master it so I can get those working. That's why I use a simple thing which I can learn well, so I can implement whatever setup I need.

I used to be on Ubuntu, Debian and Arch. And implementing such these setups was too hard under systemd. However, if you don't need this. Systemd just works fine for you as did for me in past.

How's Alpine on desktop? I've long wanted to try it, but always thought that it is more of a server thing.

So far, I'm good. It's not the best Desktop distro. But since I want an OS for development and also for a workstation, Alpine is good.

Also, it's kinda DIY like Arch, or worse!

I'm not really that deep into it but I'm also using elogind and Alpine uses the newest Kernel so do your points still apply in that case?

The kernal of course has exactly the same functionality as kernels in systemd distributions. What good is that without the user space using the functionality though? A portable init tool will not use any of that... as soon as they do, the portability is gone and they are linux-only.

Systemd-logind delegates priviledged operations like cgroup creation, power management, and such to PID1 (systemd) because that is the process with the necessary privileges and global view of the entire system to perform them. Managing that stuff is the one job systemd-PID1 has, logind is in a layer above and uses the foundational interfaces from the layer beneath it.

Elogind removes that integration by necessity. No idea what it does instead, but going by elogind devs stating that consolekit was good enough and that logind is just a power grab, I doubt they do a very thorough job. That elogind is basically only updated when a new gnome version uses interfaces not provided by elogind does not indicate a very pro-active maintainer team to me.

But you do what you think is best for your systems, I do what I think is best for mine.

@hunger @eta I do what I think is best for the future of computing, and I don't think that is systemd.

Go ahead, you have my blessing. Not that you need it or care about it :-)

Just out of interest: Where do you think the future of computing is?

@hunger I don't think the future is either #guix or #shepherd, but I do think it lies in that direction. I think there will be some merging between cron/init/make as these are all things which perform some action when some conditions happen.But I'll probably end up being completely wrong...