Live data from Hacker News

Broken by design: systemd

ewontfix.com

41–48 of 48 posts

Re: Broken by design: systemd

#41
post #25
post #11

Earlier quoted context omitted.

Functionality is not being moved out of the kernel and into userspace. It's being moved out of legacy freedesktop.org components (hald, ConsoleKit, PolicyKit, etc.) and into PID 1. Where should it be moved to? /dev/null.

hald has been dead forever. PolicyKit is not being moved into systemd, nor is it getting systemd integration? How do you want to replace ConsoleKit/logind? What should handle session management?

Something other than your init system. Not even Apple's launchd has the kinds of idiotic layering violations that systemd is full of.

Re: Broken by design: systemd

#42
post #5
post #4

systemd is like a second kernel in user-space.

and, launchd is like a second mach kernel at a higher level. https://developer.apple.com/library/mac/documentation/Darwin...

Except for the part where launchd doesn't implement anything other than traditional process/service launch and termination, and doesn't violate the layering boundaries between system components.

In a launchd system, there's absolutely no dependency on launchd by userspace software.

Re: Broken by design: systemd

#43

Earlier quoted context omitted.

How has it affected your uptime? Any specifics?

In addition to the prudential concern issues (which are laid out in the article), there are some concrete issues: With sysv init, it is very easy to add new services that may not be supported out of the box. There are scripts like rc.local, etc, which can be edited to start anything. This means that setting up a new service that can be supported properly is a lot more work, especially if it is for development systems…

That sounds strangely like the problem systemd was created to solve. It's supposed to detect double forks in the started daemon and track pid files named in it's configuration file.

At least that's how I read it in numerous articles on LWN and mailing lists, I haven't tried it on an actual system yet.

Re: Broken by design: systemd

#44
post #27

Earlier quoted context omitted.

If you upgrade systemd or the kernel, yes, you should reboot your machine. Ideally, it shouldn't take more than a minute or two.

Obviously not talking about servers here. Those RAID can take more than a few minutes to spin-up.

If you can't afford 3 minutes of downtime (how long a Dell PowerEdge R620 takes to start responding to ping again after a shutdown -r now), you really should reconsider running that service without a redundant system at the ready.

Re: Broken by design: systemd

#45
post #25

Earlier quoted context omitted.

hald has been dead forever. PolicyKit is not being moved into systemd, nor is it getting systemd integration? How do you want to replace ConsoleKit/logind? What should handle session management?

Something other than your init system. Not even Apple's launchd has the kinds of idiotic layering violations that systemd is full of.

Well, you'll be happy to learn that logind is a separate process entirely.

Re: Broken by design: systemd

#46
post #35
post #28

Earlier quoted context omitted.

The only Plymouth-specific code I see in systemd is related to asking the user questions at boot-up time, like their mount password, and it works by sending a socket message to a socket plymouth opens, and successfully falls back if it doesn't exist. I don't see any plymouth-related services or unit files hardcoded. I do, however, see a NEWS-related entry from the v186 release: http://cgit.freedesktop.org/systemd/sys…

there are no unit files, but there are units: [plo@plo-air ~]$ systemctl --all | grep plym plymouth-quit-wait.service masked inactive dead plymouth-quit-wait.service plymouth-start.service masked inactive dead plymouth-start.service

On my system, those units do have unit files, and they're provided by the Plymouth package. I couldn't find any reference to "plymouth-quit-wait" in the systemd source code, so those strings have to be coming from somewhere. Are you sure you don't have a unit file at /usr/lib/systemd/systemd/plymouth-quit-wait.service ?

Re: Broken by design: systemd

#47

Why don't the anti-systemd folks publish some actual attacks against that big ol' attack surface? I've been using it for maybe 18 months, it was different and different is some times scary but I have had no problems at all. Migrated some legacy init scripts and it's a piece of cake. It's fast, it works, it does what it claims to do. I've been shipping unix software mostly on linux for 15 years and there are very real…

> anti-systemd folks

[note: no personal hostility intended - I'm responding to the idea of "anti-systemd" in the abstract]

It's this kind of us-vs-the, faction-oriented attitude that concerns some of us. Nobody[1] is saying systemd should be expunged from the repositories or removed as an option.

The concern is that a newcomer (i.e. potentially buggy, but could prove itself over time) to the area of "init software" is demanding to be the only software allowed for that particular problem. Even more concerning is how that same newcomer as monopolistic tendencies, and has started tying/bundling together several neighboring software niches, demanding that the currently used and working solutions in those areas be abandoned as well, because of some made up requirement.

If you or anybody else wants to run systemd, you should. In reading these discussion on it, it even sounds like a great choice for some situations (the people setting up "tens of thousands" of mostly-identical systems seem to like it a lot). Some distros make it the default? Why not, variety is one of the great things about having multiple distros to choose from.

Insistence that OpenRC and such must make way for systemd is enough provoke a rather strong reaction. The deliberate incompatibilities to force adoption, on the other hand, are borderline fighting words.

This pattern - trying to suppress competing ideas while claiming the opposition is being unreasonable for suggesting some sort of compromise - is something I've had to fight in politics for a long time. It's expected any time atheism or gay marriage is brought up.

I never thought I would see that kind of "argument" used seriously[2] over UNIX...

1: "nobody", modulo the rare fanatic/ass that you find in any sufficiently large group of people. Even the linked article above - despite the presence of strong opinions - is more concerned with technical issues and how to solve the "init system problem" in general.

2: we have had our Holy Wars, but traditionally only leads to strange stuff like "evil-mode"

Re: Broken by design: systemd

#48
post #45

Earlier quoted context omitted.

Something other than your init system. Not even Apple's launchd has the kinds of idiotic layering violations that systemd is full of.

Well, you'll be happy to learn that logind is a separate process entirely.

Layering violations don't only happen within the process level.
Post reply on HN