Live data from Hacker News

Why systemd?

blog.jorgenschaefer.de

171–180 of 263 posts

Re: Why systemd?

#171
post #145
post #139

Earlier quoted context omitted.

Reminds me of the joyful early days of moving from grub to lilo. Grub was (is) more fragile due to being more complex -- but at least the grub shell gives more information than lilo failing at "LI"... Grub always seemed like the improved features made up for the added complexity; I'm not convinced about systemd.

Even Grub isn't all flowery. I have a background of using what I think is now called grub-legacy. Then I ended up running Debian, with newfangled Grub. I needed to change some kernel parameter (IIRC) but all I could find was a mess of undocumented scripts which say "don't touch this". I don't know where the documentation went, and it seemed needlessly complicated to configure. Why couldn't I say man grub and learn al…

The config files you want are /etc/default/grub and possibly also /etc/grub.d/ - though you're right, this doesn't seem to be documented anywhere obvious like in the man page. Gentoo installs its own version of /etc/default/grub with comments and examples but Debian may not be so helpful.

Re: Why systemd?

#172
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've not claimed that Systemd gets everything right. I've claimed it gets enough right enough that a lot of people will be entirely unwilling to give up those advantages and return to something that for many of us is now an inferior solution, just because there are things about Systemd we may not agree with.

For my part, I agree that binary logs was not necessary, though I've yet to encounter any issues with it, and journald certainly does provide a lot of functionality that makes it more pleasant to deal with logs than before. All of that could have been achieved while retaining text logs, though. But at the same time, it is still trivial to log to text files by telling journald to log to syslog if that matters to you.

Other things I do care about include getting rid of init scripts - that is a persistent source of problems. I'm inclined to believe not a single one of them are bug free, though that's probably a bit uncharitable. Unit files helps. So does cgroup containment to rid us of the abomination that is the need to rely on pid-files and hope that works reliably (it doesn't, since pretty much nobody are through enough when writing init scripts). Other things include better recoverability in cases where critical processes gets killed, and well thought out handling of early stage logging. And things like systemd-cgtop and systemd-cgls are nice.

I'm sure we'll eventually get solutions that split more of this functionality out into more cleanly separate components, and that'll be great, but until then I'm happy to stay with systemd.

As for the problems you ran into, that sucks, but any large change like this will have painful teething problems and they're not a good basis for judging whether it's a good long term solution - I've had plenty of boot failures caused by problems with init scripts as well.

Boot time is a long way down the list of benefits for me too - most of our servers have uptimes measured in years, and even my home laptop usually goes a month or two between reboots.

Re: Why systemd?

#173
post #132

Earlier quoted context omitted.

My FreeBSD system has a 30-second timeout during which the entire boot process is halted because it waits for a default route to the internet... which it won't get, because I haven't configured one. It's pretty dumb, and not enough of a problem for me that I'd figure out how to work around it, but it's a pretty good example.

I don't think this 30-second timeout is a bug in FreeBSD or in rc. You may want your server to wait for the network to become available. Ubuntu Server has the same "waiting for network" timeout: http://askubuntu.com/questions/63456/waiting-for-network-con...

But the only reason this is necessary is when the boot system isn't smart enough to start whatever can safely be started through proper dependencies.

My experience is that a substantial amount of time is wasted weeding out undesired timeouts in startup scripts, because they lead to increasing downtime.

Re: Why systemd?

#174
post #84

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…

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, at which point every dbus-using application will require systemd to function. They're also planning to make udev dependent on kdbus[2] in a way that can't be worked around by forking or using old versions, since apps will use the kdbus API to call it directly[3] )

[1] http://lists.freedesktop.org/pipermail/dbus/2013-July/015726... [2] http://lists.freedesktop.org/archives/systemd-devel/2014-May... [3] http://lists.freedesktop.org/archives/systemd-devel/2014-May...

Re: Why systemd?

#175
post #163
post #130

Earlier quoted context omitted.

There's legal freedom, and there's practical freedom. Sadly, the latter is seldom talked about. You can be stuck in a maze, in a pit or under a tree trunk. You're legally free, since no law or copyright license is saying may not get out. Yet, you're stuck and if you can't get out, you're not free at all. When it comes to software, it is the size, complexity and complicated interdependencies that make the maze. As the…

> How would Dr. Stallman have felt if he had gotten his printer driver with a free license but so much code ... that it would've been impossible ... to actually port it and make it run on his system? While I am not an expert on legal language and how it can be used by lawyers, I believe RMS and the FSF at least attempt to address this in the GPL Version 2 (there is probably a similar requirement in the GPL Version 3,…

> Code that is so large complex that it is not practical to understand or port wasn't written by a human. Such code is probably a template or macro expansion of the real source

Or it was written by thousands of people over twenty years.

GPL doesn't protect you from accumulated cruft, complexity and snarly design that makes it hard to understand let alone modify a system.

Re: Why systemd?

#176
post #171
post #145

Earlier quoted context omitted.

Even Grub isn't all flowery. I have a background of using what I think is now called grub-legacy. Then I ended up running Debian, with newfangled Grub. I needed to change some kernel parameter (IIRC) but all I could find was a mess of undocumented scripts which say "don't touch this". I don't know where the documentation went, and it seemed needlessly complicated to configure. Why couldn't I say man grub and learn al…

The config files you want are /etc/default/grub and possibly also /etc/grub.d/ - though you're right, this doesn't seem to be documented anywhere obvious like in the man page. Gentoo installs its own version of /etc/default/grub with comments and examples but Debian may not be so helpful.

I'm pretty sure I poked in those very files, and some of them gave me the impression that they are generated by a script (hence "don't touch this"). Some of them gave me an impression they are read by some undocumented script. I still don't know what script.

But it's been a while.

Re: Why systemd?

#177

Earlier quoted context omitted.

Isn't that a pretty narrow corner case? I can count the number of times the process manager has been killed on one hand.

Also you depend every-day on another process that is special in some sense just as the process manager: Xorg. If Xorg dies all your desktop applications die. By your line of reasoning Xorg should be moved into PID 1 too, which is definetely not a good idea. I don't say that Xorg hasn't crashed, it did rarely when running RC code or proprietary drivers. In fact I probably had as many Xorg crashes as kernel panics, whi…

That is a pretty bizarre argument. I would conclude from init and Xorg rarely crashing that it is possible to write a reasonably stable daemon, and that perhaps it's not a good trade-off to introduce a lot of complexity into those daemons to be able to recover from crashes.

Re: Why systemd?

#178

Earlier quoted context omitted.

This. The FreeBSD rc system just works, is well documented and is small enough to understand by one person without too much effort.

I've been tinkering with NetBSD the last couple of weeks in a VMWare Fusion virtual machine and the RC system it uses it very nice. OpenBSD's is nice as well.

NetBSD can run as a xen dom0 host too though normally I use Alpine Linux/OpenRC as dom0 because it's so small.

Re: Why systemd?

#179
There's a lot of negativity going on here...

As far as my experience goes, I've found it actually works really well on all the servers I've moved to CentOS 7 and on the Fedora desktop I play around with (my main dev machines are Macs) it's significantly improved boot time...

I'm sure there are some valid concerns about design and such, but as far as my usage in production goes, I can't say I've had a single problem with it... It makes it a lot easier when I need to write files then the messy init scripts before also.

Re: Why systemd?

#180
post #122
post #42

Earlier quoted context omitted.

This init process debate has brought out one of the worst elements of people in the FOSS community: treating some FOSS technology as an extension of their identity. Let's keep some perspective here. We are literally just talking about an init system. There are many others you can use. systemd is not taking away your freedom in any meaningful sense of the word "freedom". Debates should be about the technical merits of…

> 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.

Post reply on HN