

I’m totally with you on that. I use systemd daily and it has enormous benefits for system administration, but I don’t like the direction it’s headed and how the project is lead. That’s what I wanted to bring across here.
Not everything in black and white makes sense.


I’m totally with you on that. I use systemd daily and it has enormous benefits for system administration, but I don’t like the direction it’s headed and how the project is lead. That’s what I wanted to bring across here.


That’s what the problem with systemd is. It started out as a “modern” init system but somehow we ended up with some kind of parasitic software heap that tries to replace the userspace.
I mean the latest addition is some kind of OS installer.
To quote James T. Kirk: “why does an init system need an OS installer.”


I’m speaking about the firmware and other blobs that are there because devices wouldn’t work without it.
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/WHENCE


Nice, something running in an eBPF context with a blob in the middle, what could go wrong …
Also there are already a lot of binary blobs in the kernel, that also makes me nervous a bit.
What are you using to ship the logs to VL?
If you want to exclude “normal” logs you should start excluding them before they reach VL, so the only logs you have are the interesting ones.
The more you can filter and label at the source, the less you have to work out in VL.
I use alloy (which is kinda heavy) to extract and prepare only the data I want and it works great so far.
Yeah, they should do an init system instead of reinventing an operating system.
That’s the main problem I have with it.
Of course advocates of systemd will say it’s modular, but there is some kind of capture process going on - you have to relay on the systemd solution, because it fits nicely into the systems ecosystem …