Hacker News Reader

Comment by greatgib | Hacker News Reader

Systemd, as usual randomly and suddenly breaking things that worked for decade and for people that asked nothing. Because they know better what you need...

View on HN

And what's your preferred alternative to what's described in the article? Packaging every single service in its own 500mb ubuntu chroot and using docker? Running a local dhcp server and a bridge interface so that you can selectively expose ports?

Here's an alternative title for this post: these days, two lines in a systemd service file can easily constrain arbitrary applications to just the files and resources they need, and only those.

My grumpy preferred alternative would be "you're supposed to be an init service. That's not your job".

> systemd is a suite of basic building blocks for a Linux system.

You can always use a simpler init system if you want

I linked it elsewhere in this thread, but you should really watch this talk, particularly 12:45 through 16:20: https://www.youtube.com/watch?v=o_AIw9bGogo

tl;dr: systemd isn't meant to be an init system, it's meant to manage services, and the alternative world where you don't have a unified system for managing services and events actually sucks.

> systemd isn't meant to be an init system, it's meant to

embrace and extinguish unix philosophy.

> the alternative world where [] actually sucks.

You should bear in mind that there are plenty of people here on HN who have had the experience of running pre-systemd unixes and they know exactly how much "the alternative world" sucked. Spoiler: not much.

I was in college before Debian adopted systemd, and worked part time as a sysadmin managing hundreds of pre-systemd Debian systems. You’re wrong.

I was in college when you were born. And managed thousands of pre-systemd instances including a vast zoo of unixes which were long gone by the time systemd ate the world. You're wrong.

Good for you, I'm simply saying that my feelings on the superiority of systemd are informed by having used linux before systemd was around, whereas you insinuated that I had not.

I don't really care to argue about it.

Doesn't SELinux do that (and more)?

The problem is the “more”. SELinux is extremely flexible and does what the configuration tells it to do. And it does not compose well. Want to point whateverd at /var/lib/whatever? Probably works if the distro packages are correct. Want to make /var/lib/whatever be a symlink? Probably does not do what you expect. Want to run a different daemon that accesses /var/lib/whatever or mount it into a container? Good luck. Want to run a second copy of the distro’s whateverd and point it at a different directory? The result depends on how the policy works.

And worst: want to understand what the actual security properties of your policy are? The answer is buried very, very deep.

selinux doesn't really provide anything like ProtectHome or PrivateTmp mentioned in the article. SELinux only does access control, while systemd can create new resources that are scoped to specific service.

It does, and that's why the systemd crowd want to replace and extinguish it.

The example given is a distro changing their bundled systemd unit files to use new features, yet you choose to blame systemd?

You do realize distros can also change SysV shell scripts in ways that break your use case as well, right?

Systemd is probably the part of my distro that works best.

Did you read the article? The author is complaining that aystemd introduced _optional_ security mechanisms for units. If you don’t like these mechanisms, don’t use them in your units.

Systemd didn’t “break” anything at all here. This author’s arcane debugging workflow doesn’t work for certain units who have opted into the new security mechanisms. But that is hardly systemd’s fault.

“Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".” --https://news.ycombinator.com/newsguidelines.html

systemd introduced optional timers. Not long time passed and voila - cron is deprecated and hardly works today.

systemd introduced optional socket activation. Boom: sshd in process list is faked on Ubuntu 22+.

systemd introduced optional structured logging. Voila: every distro now ships with unremovable journald.

systemd brand introduced optional systemd-resolved, easily the worst project, and soon it's going to be mandatory for DNS resolution.

Whatever systemd makes optional, practically becomes mandatory to use in distros because systemd developers do not code optional things for them to go unnoticed.

Reply on news.ycombinator.com