Hacker News Reader

Comment by pzmarzly | Hacker News Reader

I am not a big fan of systemd, but I am impressed in how they put this security feature all across the boot process. I also used some of the tools shown in presentation and they are pretty well made, kudos to the devs. (Also, most of them work fine without systemd running, they just happen to be in the systemd monorepo???)

View on HN

Systemd is packed with impressive things.

The more you research it, the more you find to be impressed with.

I'll be impressed when they figure out how to not break bind mounts and NFS on boot

The problem with systemd isn't that it's not packed with impressive things, it's how inextricable the things are from each other. systemd distros are practically whole new distros on the inside, designed by committee. Every part of systemd really wants to integrate with every other part, so while you can technically compile and run just part of it, it really wants you to use the whole thing and throw away all the things those parts replace.

In other words the complaints are political, not technical.

It's just user space though. As long as the kernel remains independent there's problem.

I agree that there are some very cool components of systemd (or rather, very cool programs living in systemd repo) - networkd, resolved, repart, boot and stub come to my mind first, they have no alternatives that come even close to them.

Also, systemd made writing service definitions easy, hats off to them. With cgroups, namespaces and capabilities support out of the box - great.

However, every time I have to debug why some target wasn't reached (because some dependency of dependency failed), or why systemd mounted something wrongly, or just want to know how often and why some service restarted, I feel like the core part of systemd (which is, the systemd init and service runner) is working against me.

And let's not get started on journald, I declare it my enemy.

I've kept my eye on the project from afar. What's impressive about systemd aside from its ability to manifest conformity and avoid social accountability for how it gained influence?

Boot charts and NIH syndrome for system level stuff ain't it for me. Binary journals ain't it, either. Services suck, you're never sure the difference between units, services, sockets, and other similar INI style files. Extra BS like $HOME management? Not necessary.

In over ten years, I've not found a single good reason to lean into systemd or like it. It runs my current computer, but not by choice and I will remedy that when I build my custom distro.

This thing isn't really complicated, because all the hard-lifting is done by the design of TPM, not even TPM chips. Measurements and integrity checks are proven to be mundane tasks, and, for security, it's a good thing. Even without systemd, one can learn and integrate TPM in one or two months. But the systemd team has been working on this like 2 years now.

I'm quite curious what they've been doing. Security audits, maybe? Preparations for other integrations? I'm not criticizing here - I've been away from that scene for an year, and I wonder if there have been some new interesting developments or ideas that I'm not aware of.

Reply on news.ycombinator.com