InitWare, a portable systemd fork running on BSDs and Linux

https://github.com/InitWare/InitWare

Discussions: https://discu.eu/q/https://github.com/InitWare/InitWare

InitWare: systemd-like clone for BSDs https://lobste.rs/s/utis5o #netbsd #systemd
https://github.com/InitWare/InitWare

I've created the first alpha release of libkirmes, a Rust and C library which provides an API to access the systemd userdb.

It will be used in our localkdc project to enrich user information of a user in our kerberos database with information from the local userdb.

https://crates.io/crates/kirmes

Huh. Now that I have #otel traces on a bunch of things at home, it's pretty clear that my clocks aren't in sync on every system. They're maybe 1ms off, but it's enough that supposedly-nested trace spans aren't quite nested right.

Which is annoying since I have two local GPS #NTP receivers.

The two "bad" machines were using #systemd-timesyncd to talk to Ubuntu's pool clocks instead of the local clocks. The "good" machines are using #chrony and claim that they're ~2 us off of GPS time.

Now I'm curious -- is this a problem with network latency and Ubuntu's pool, or is that just as good as timesyncd gets?

My Way to Remove Linuxisms from FreeBSD https://lobste.rs/s/njhsdh #freebsd #linux #systemd
https://eugene-andrienko.com/en/it/2025/03/30/freebsd-pkgs-wout-unwanted-deps

So, we did a thing.

https://github.com/systemd/systemd/pull/36914

#Debian #systemd maintainer today removed both systemd-resolved and systemd-nspawn packages from Testing/Trixie/Debian 13 - soon to be in feature freeze - due to disagreements with the Technical Committee. New installs can use resolvconf. https://tracker.debian.org/news/1632477/accepted-systemd-2574-4-source-into-unstable/

From Debian Unstable changelog:

systemd-resolved is going away!

systemd-resolved is disappearing in #Debian:

"Drop systemd-resolved package. The ctte has declared that the way the systemd-resolved tool works is incompatible with their decision to prioritize avahi in Debian. Furthermore, the resolved tool is being used to inflict pain on the maintainer, and induce burnout. Regrettably, the only safe solution to ensure this package is compliant with this decision is to drop it, as all reasonable alternatives put forward have been rejected:
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/289
(Closes: #1098914)"

https://tracker.debian.org/news/1632477/accepted-systemd-2574-4-source-into-unstable/

Bloody love computers.

Imagine being forbidden from scheduling a shutdown on your very own computer.

What kind of decisions led to this horrid mistake to happen?!

Is there a "user-oriented" version of #systemd that one can use on servers? We have this hardware controls framework that has a tool to graphically see all the device servers running and restart them with a right click → restart. That'd be cool, but for systemd services. #linux

Converting my dev laptop to https://devuan.org/ - Debian fork minus systemd.

Going well so far...

Deal a lot with systemd, so wrote a VSCode extension to observe the state of services.

https://github.com/gbraad-vscode/vscode-systemd-manager

It is at a very early devel; it shows all units and their state, you can start/stop/restart and see status. I would like to do daemon-reloads, auto reloading status/follow, filter for service, sort by state, mask, unmask, etc.

I use this over code serve-web, to help with remote management of services. Use in combination with:

https://marketplace.visualstudio.com/items?itemName=hangxingliu.vscode-systemd-support

WDYT?

I wonder why systemd-sysv-generator is deprecated for removal.

I mean, it's not particularly consequential—it's a separate program and can therefore be forked if anyone still cares about it—but what's the point of dropping it?

Is it burdensome on the #systemd maintainers somehow? Pretty hard to imagine, seeing as how the LSB specification is frozen and the systemd unit specification is guaranteed backward compatible.

A #systemd thing I just discovered: I was having problems with a service starting on boot before the disk that had the data for it was mounted, and so it'd get upset about missing files and I'd have to manually fix it. I found that systemd has a `RequiresMountsFor=` option, so I can say `RequiresMountsFor=/mnt/path` and the service won't start until that path has been mounted. Simple, handy, and took a surprising amount of searching to find that (for some reason depending on the unit for the mount itself just didn't work.)

So, guys.

How much further do I take this?

Quadlet: Running Podman containers under systemd

https://mo8it.com/blog/quadlet/