Why systemd? • Hacker News Board

Re: Why systemd?

#181

Post by jbb555 » Tue, Sep 23, 2014, 1:27 PM UTC

bigbugbag wrote: post #142

vidarh wrote: post #111

Earlier quoted context omitted.

Feel free. Most people won't, as systemd solves very real problems that people care a great deal about, whether or not you like the way it has solved them.

15 years linux user here, systemd is pushing me hard towards leaving linux. Please tell me what very real problems people care a great dead bout systemd solved by turning log files from text to binary. Also I care about being able to use my computer and for the first in 15 years a systemd update caused my computer to needlessly dropping into systemd emergency mode at boot and this emergency mode being broken I was ef…

I couldn't agree more. If it become impossible to use linux without systemd then I won't be using linux any more.

Re: Why systemd?

#182

Post by chousuke » Tue, Sep 23, 2014, 1:28 PM UTC

lmm wrote: post #137

chousuke wrote: post #133

Earlier quoted context omitted.

You're blaming the wrong party here. The systemd project has no control over what Gnome relies on. They independently rely on systemd because it provides functionality that makes their lives easier, and it's their right to do that. If you want "up-to-date Gnome" to work on FreeBSD, go and write some code to help make it happen.

What are my real options? I could write patches that reimplement the functionality that Gnome gets from systemd using lower-level functionality, in a cross-platform way. But those patches would be rejected; the Gnome project has decided to use systemd and would not want to duplicate its code. If I were to maintain my own gnome fork I would have to convince distributions to adopt it. I could write patches that add Fre…

The real option actually is to bring up FreeBSD to the level that it can provide the same functionality (specifically, dbus interfaces) as systemd and Linux. Gnome depends on systemd features because they're useful and solve real problems. As it is, FreeBSD can't provide those features.

You can of course make the case that the interfaces provided by systemd are substandard, but so long as you don't have an alternative to offer, it's just talk.

As far as I know, Gnome does currently have fallbacks (with reduced functionality) on non-systemd systems, so it's not the case that they just ignore things. However, I perfectly understand why they would not bother with duplicating code just to support systems that aren't good enough.

EDIT: I'm apparently not able to respond to the reply below me for whatever reason, but... It's been said many times that making systemd portable makes no sense, which is why it provides interfaces. And regarding the interfaces, which part of them, exactly, are not stable? There's a very reasonable interface stability promise, which to my knowledge has held, so far.

Re: Why systemd?

#183

Post by lmm » Tue, Sep 23, 2014, 1:31 PM UTC

spain wrote: post #180

lmm wrote: post #122

Earlier quoted context omitted.

> systemd is not taking away your freedom in any meaningful sense of the word "freedom" Systemd has made it impossible for me to run an up-to-date Gnome on FreeBSD. That feels a lot like taking away my freedom.

>Systemd has made it impossible for me to run an up-to-date Gnome on FreeBSD. That feels a lot like taking away my freedom. It sounds to me like Gnome is the reason why you can't run Gnome without systemd, and that you should probably direct your complaints against them.

It seems to me that Gnome's position of "we want to use this useful library that exists on our biggest platform" is much more reasonable than systemd's position of "we won't accept patches to add cross-platform compatibility, and we won't provide stable interfaces".

Re: Why systemd?

#184

Post by andor » Tue, Sep 23, 2014, 1:31 PM UTC

makomk wrote: post #174

cbsmith wrote: post #84

Earlier quoted context omitted.

> double forks That's actually not something you want. It turns out that makes process management unnecessarily hard. That said, the glibc implementation isn't terribly good either. The CW is not to use either. > I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. The most exasperated criticism I see about systemd is its use of dbus for a communications infra…

The systemd developers are planning on replacing dbus with their own NIH reimplementation, kdbus, soon - complete with its own serialisation format, its own in-kernel IPC framework, and a hard dependency on systemd. (Oh, and it requires everyone to rewrite their code to use systemd's dbus library rather than libdbus too.[1] That library currently supports old-style dbus but they're planning to drop support for that,…

Oh, and it requires everyone to rewrite their code to use systemd's dbus library rather than libdbus too.

Have you actually read the mail you're giving as "evidence"?

The last paragraph begins with: "The current idea is that systemd will provide a bridge service, that offers the current D-Bus socket, and an unmodified libdbus (or an alternative implementation) can talk to that socket like it talks today to the dbus-daemon."

Edit:

kdbus is also not a NIH-implementation, in any meaning of the word. It was "invented there", and it also fixes things: it will have much lower latency and overhead than the current userspace D-Bus.

http://kroah.com/log/blog/2014/01/15/kdbus-details/

Re: Why systemd?

#185

Post by UnoriginalGuy » Tue, Sep 23, 2014, 1:36 PM UTC

edwintorok wrote: post #165

nextos wrote: post #3

We often criticise systemd for being too bloated, and making it hard to write a drop in replacement. I totally agree with this line of thought. However, in my mind it has made several awesome things possible. My boot time got dramatically shorter when I adopted it thanks to parallelization. Besides, daemons have now simple and robust service definitions. Sys V had become a mess! Lastly, lightweight containers are the…

Boot time again. In a server environment it happens that the various DRAC/BIOS(es) are initialized and the bootloader reached is far longer (several minutes sometimes) than the boot time of sysvinit. So optimizing boot time in the Linux part on a server is probably moot for me. On the laptop you can suspend/hibernate as others have said if you care about startup time. I have full-disk encryption and need to type in p…

Holy heck, I get being defensive, but you've let logic totally fall by the wayside here. Where do I start...

The fact that BIOS/DRAC/RAID initialisation is slow on some servers is irrelevant. Linux's init and the firmware initialisation don't run concurrently, therefore if init takes longer the whole boot takes longer. Additionally many servers manufacturers have improved boot times in the last few years (down from 10+ minutes, to 5+ minutes, to less).

Most routers don't take as long to boot as you claim. The entire OS is about 8 MB (uncompressed) and RAM is only 32 MB, and the medium that the OS is stored on is faster than a computer's hard drive. So just looking at IO should tell you your supposition is flawed. In my experience most Linux based routers boot the RJ-45 interface (LAN side) in under 20 seconds unless it is allocating slowly on the WAN interface (e.g. unable to get an IP, etc). If you set a static WAN IP/gateway/etc, then boot times comes down substantially.

Additionally the whole concept that every time your PC turns off you'll also turn off your router at the mains is, uhh, strange. Sure there are power cuts but that isn't the only time you shutdown your PC throughout the year.

The concept that your PC needs to wait for the server is equally flawed. Again, yes, power cuts. But PCs get shut down significantly more often than servers and if we're playing that game then wouldn't a "server" have a UPS anyway?

So overall your argument for why boot times don't matter lacks any kind of substance. It is also purely based on a PC->Server->Router infrastructure where nothing is on a UPS and everything suffers from a power cut (then "races" to all come back up).

In the real world my phone has Linux, our "Tivo" has Linux, our printer has Linux, our car's entertainment system has Linux, etc. So bad Linux boot times will be noticed day to day. It matters to a lot of people and while I don't know if systemd is the solution, I do know that progress is needed relative to the classic UNIX init system (per the article).

Re: Why systemd?

#186

Post by lmm » Tue, Sep 23, 2014, 1:45 PM UTC

vidarh wrote: post #110

uselessdguy wrote: post #51

Disclaimer: I develop uselessd, probably have a warped mindset from being a Luddite who values transparency, and evil stuff like that. The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set t…

> The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set the session and process group IDs, and optionally exec the process manager. The process manager gets killed. How do you recover? If you have respawn logic for it in PID 1, how do you log information about a failure to respawn the process manager? Perhaps you build in some basic logic for logging. Whe…

Wait what? What happens if the process manager crashes if you're running non-systemd: you might respawn it but not be able to log the fact that you did so. Worst case, you fail to respawn it and your system crashes.

What happens if the process manager crashes if you're running systemd: the process manager is in PID1 (or, equivalently, in a tightly coupled process that PID1 depends on - because the whole point of your post was that you can never get to a state where PID1 is working but logging isn't working), so your system crashes, every time. How is that better? And if that's really what you want, it's easy to configure a decoupled init system to do that.

Hey, some people like their logs to be sent as email. Maybe we should move sendmail into PID1 as well.

Re: Why systemd?

#187

Post by lmm » Tue, Sep 23, 2014, 1:58 PM UTC

chousuke wrote: post #182

lmm wrote: post #137

Earlier quoted context omitted.

What are my real options? I could write patches that reimplement the functionality that Gnome gets from systemd using lower-level functionality, in a cross-platform way. But those patches would be rejected; the Gnome project has decided to use systemd and would not want to duplicate its code. If I were to maintain my own gnome fork I would have to convince distributions to adopt it. I could write patches that add Fre…

The real option actually is to bring up FreeBSD to the level that it can provide the same functionality (specifically, dbus interfaces) as systemd and Linux. Gnome depends on systemd features because they're useful and solve real problems. As it is, FreeBSD can't provide those features. You can of course make the case that the interfaces provided by systemd are substandard, but so long as you don't have an alternativ…

FreeBSD can and does provide these interfaces. We've had e.g. cgroups-equivalents for years. The reason systemd doesn't run on FreeBSD is pure politics, not technical - after all, if it were technically impossible to implement systemd on FreeBSD, there would be no need for a policy of refusing patches.

> You can of course make the case that the interfaces provided by systemd are substandard, but so long as you don't have an alternative to offer, it's just talk.

The problem isn't that the interfaces are particularly bad, it's that they're not standardized. If systemd would offer standardized interfaces that let me offer a compatible alternative that would be fine. But they don't. Trying to remain compatible with software that will make no effort to provide compatibility from its side is a mug's game.

Re: Why systemd?

#188

Post by earlz » Tue, Sep 23, 2014, 2:05 PM UTC

ultramancool wrote: post #63

uselessdguy wrote: post #51

Disclaimer: I develop uselessd, probably have a warped mindset from being a Luddite who values transparency, and evil stuff like that. The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set t…

Well said. I recently migrated to FreeBSD after trying sytemd on Arch and seeing that Debian and Ubuntu are planning to move too. The dead simple rc.conf file seems so much nicer than the stuff I was dealing with in the entire world of Linux-based systems, like going back to the way Arch used to be when I really liked it.

The really sad thing is that Arch Linux use to pride itself on being BSD-like. It used a similar rc.conf system. Each service had exactly one init script, not the weird multiple file init script system Debian has. Before systemd, Arch was the closest you could get to BSD simplicity on Linux

Re: Why systemd?

#189

Post by ldng » Tue, Sep 23, 2014, 2:06 PM UTC

drdaeman wrote: post #19

ultramancool wrote: post #5

Am I the only one who's disgusted with this bloated, convoluted, dbus-dependent pile of crap? I mean, c'mon, binary log files? I'll pass, thanks. It replaces way more than it needed to. I prefer the BSD-style philosophy, nice, simple rc.conf, used to run Arch till it got infected with this garbage too. It slowly progressed away from it's BSD-style roots. So recently, I just gave up and moved to FreeBSD. Not a single…

I think I'm mostly fine with journald (as a concept). At least I can explain reasoning for it to myself. A switch from non-structured to structured data provides a significant advantage, and indexes are useful. At least I had too many times grepping a multi-gigabyte log file. Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So,…

Systemd is more like busybox than sysvinit. People bitch about Systemd because they're not foul. Systemd folks (mostly Redhat) have their agenda. I don't mind that. Heck I even agree on some of it. But pushing the whole bloated thing down nearly everyone's throat disguising it as just a simple init replacement is a bit too much.

Re: Why systemd?

#190

Post by tankenmate » Tue, Sep 23, 2014, 2:08 PM UTC

cbsmith wrote: post #84

Sanddancer wrote: post #17

I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. One of the things this post criticizes, and Poettering criticizes, is the BSD-inherited daemon() function. Being curious, I looked at the function's implementation, both in FreeBSD's implementation, and glibc's implementation. FreeBSD's implementation handles pretty much everything the daemon writer themself…

> double forks That's actually not something you want. It turns out that makes process management unnecessarily hard. That said, the glibc implementation isn't terribly good either. The CW is not to use either. > I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. The most exasperated criticism I see about systemd is its use of dbus for a communications infra…

You need to double fork() in order to ensure that the daemon won't be the controlling owner of the tty once it calls setsid(); i.e. that it will be re-parented to init.

So personally as a sysadmin that occasionally runs daemons from the command line I much prefer a double fork(); I don't want the daemon to exit when I log out.