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.

How ironic!

Now post the output:

ls -ld /run/systemd/io.*

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

Share the content of the file 90-systemd.preset from your system.

Let's play a game. Pick a "separate utility" from the list above, and let's see if you know what you're talking about, or just waffling.

Your "separate utilities developed under systemd umbrella" claim was simply false.

Your attempted retort was even more funny, since many coreutils implementations can actually literally be built into a single binary with many symlinks, with dispatch done based on arg0. It's even the preferred packaging option.

There are a lot of interdependencies within those source trees. Nothing is self-contained. So the "itz just monorepo bro" is also false.

they also overreaching and that’s THE point?

You literally just listed multiple projects 🤭, where their collective surface is also nowhere close the the systemd forced hegemony. Maybe they should all unite and join the "umbrella".

No, they aren't. These are the binaries from THE systemd package , built from systemd releases, from THE systemd repo.

A single source tree looking like an "umbrella", and an overreaching one at that, is THE point.

I’m the type of person who wants more systemd in my computer

Hear hear. A couple hundred more should do the trick.

bootctl
busctl
coredumpctl
homectl
hostnamectl
importctl
installkernel -> kernel-install
journalctl
kernel-install
localectl
loginctl
machinectl
mount.ddi -> systemd-dissect
mount.mstack -> systemd-mstack
mount.storage -> storagectl
networkctl
oomctl
portablectl
resolvectl
run0 -> systemd-run
storagectl
systemctl
systemd-ac-power
systemd-analyze
systemd-ask-password
systemd-cat
systemd-cgls
systemd-cgtop
systemd-confext -> systemd-sysext
systemd-creds
systemd-cryptenroll
systemd-cryptsetup
systemd-delta
systemd-detect-virt
systemd-dissect
systemd-escape
systemd-firstboot
systemd-home-fallback-shell -> homectl
systemd-hwdb
systemd-id128
systemd-inhibit
systemd-machine-id-setup
systemd-mount
systemd-mstack
systemd-mute-console
systemd-notify
systemd-nspawn
systemd-path
systemd-pty-forward
systemd-repart
systemd-resolve -> resolvectl
systemd-run
systemd-socket-activate
systemd-stdio-bridge
systemd-sysext
systemd-sysinstall
systemd-sysusers
systemd-tmpfiles
systemd-tty-ask-password-agent
systemd-umount -> systemd-mount
systemd-vmspawn
systemd-vpick
timedatectl
udevadm
updatectl
userdbctl
varlinkctl

A PR fixing the issue has already been submitted (which surfaced another issue, but it doesn't concern stable).

People likening this to the issue behind cve-rs (which is blocked on a major rework) are clueless, which happens to be par for the course regarding anything Rust. So no surprises there.

The language wouldn't have lost much without tuples actually. But they do at least have direct pattern destructuring utility. Anonymous enums don't.

They also don't pose potential future awkwardness if/when variant types become a thing.

A language feature is not needed because macros exist.

I would even argue that perhaps the most important role macros play is blocking adding endless language features 😉

To add to the other answers. Usually, the easiest way to answer such questions is to click on source. Then in this case, you would immediately see this comment:

// SAFETY: A `Vec` always has a non-null pointer.