How Debian managed the systemd transition
lwn.net
lwn.net
The only bug I've noticed after switching to Jessie is that on one of my systems that has two NICs for some reason both NICs will occasionally end up with the same IP on both NICs. I need to investigate further to figure out the root cause but a reboot always solves the problem for a couple days. I'm confident its not a dhcp server issue.
I expected much more grief due to edge cases that weren't planned for but I've yet to find more than the dual nic issue.
This is what happens when you throw old software out and try to replace it wholesale -- you stub your toes on all these corner cases that the prior software got right, and now you have to get it right in the new software.
And for somebody like me who personally never felt much pain from boot times or writing init scripts, the payoff from the switch has been negative so far.
I have, for what it's worth, but it's worth noting that the biggest benefits of systemd are invisible to end-users. Startup time is the one mentioned most frequently because it's one of the few that's directly observable by end-users, not because it's the most important.
For example, systemd makes it much easier to write services (both system and user services), and it definitely has delivered on this promise, since I take advantage of it frequently. Most users still don't have a need for this, though for the ones that do, it's now several orders of magnitude easier to write basic services.
But more importantly, systemd is far easier to maintain. That's the real reason distros like Arch switched so rapidly[0]; it wasn't part of some vast systemd conspiracy. They were willing to support sysvinit as long as there were people to maintain them, but it turns out that almost nobody wanted to maintain it. And since it's a volunteer/community-run distro, you can't exactly force people to maintain code they don't want to.
There was one guy who posted to the mailing list and was very adamant about providing an AUR package for it, but last I checked, it didn't have much traction.
[0] Arch switched back in 2012, long before most other distros. And they deprecated sysvinit within less than a year - far faster than they originally planned - for the above reasons.
One does not "write services" in systemd. One configures manifests for services in the unit file format, which is internally translated into a Unit object, used for representing various system resources, including services (service actions being queued as another internal unit type, that of jobs).
"systemd is far easier to maintain" is not measurable in any way. In fact, given it expects a particular FHS [2], has a lot in the way of needing optimization [3], has a rapid pace of development, adds a complicated transactional dependency system based on seven different job queuing modes and undocumented heuristics, the evidence would point that it is not. Indeed, I do recall Dave Reisner of Arch Linux complaining about systemd's pace and its poor test suite, requiring lots of patching.
[1] http://blog.darknedgy.net/technology/2015/09/05/0/
[2] http://www.freedesktop.org/software/systemd/man/file-hierarc...
[3] https://wiki.freedesktop.org/www/Software/systemd/Optimizati...
It's hardly a false dichotomy to compare what a distro was using previously to what they are using today, which is what I did (and what OP asked for).
> Indeed, I do recall Dave Reisner of Arch Linux complaining about systemd's pace and its poor test suite, requiring lots of patching.
I didn't say it was perfect, and in fact, I have a long list of complaints about the initial switch in Arch (though not Debian). That doesn't negate the point that the reason Arch (and other distros) dropped support for sysvinit was that there ended up being insufficient interest from maintainers in maintaining it.
Given that I rarely reboot my systems, no. I spend most of my time using my systems, not booting them.
[update: clarification, additional snarkiness]
As a user Ivastly PREFER the syntax and process handling of Systemd. I miss the plain text logs but no big deal.
Myth: systemd is about speed.
Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms, anyone?), but that's primarily just a side-effect of doing things right. In fact, we never really sat down and optimized the last tiny bit of performance out of systemd. Instead, we actually frequently knowingly picked the slightly slower code paths in order to keep the code more readable. This doesn't mean being fast was irrelevant for us, but reducing systemd to its speed is certainly quite a misconception, since that is certainly not anywhere near the top of our list of goals.
http://0pointer.net/blog/projects/systemd.html
Speed has always been a major motivator driving systemd. Not the only driver, but it's the first thing that's listed as a gripe with System V Init.
It may not still be the biggest priority, but to say it was never a priority is re-writing history.
Then what is it about?
Basically the biggest players in all this has long bellyached about fragmentation in the Linux ecosystem, and preached the wonders of monoculture (aka Windows and OSX).
I'm not happy Debian moved to systemd, but I understand why -- and I think they (I wish I could say we, but I didn't really encounter any unreported bugs) did a great job with the transition.
I do agree that for many use cases having a simple text-DSL for startup scripts make sense (even for someone reasonably proficient in shell scripts, the code-duplication and complexity of init-scripts are a problem. The duplication might be the worst part -- it requires a lot of job moving the system as a whole forward, and keeping even less-used packages consistent with current "best practices" as they evolve).
But that's not an argument for a monolithic init-system -- it just happened that systemd came with a DSL. One could even generate shell scripts based on unit-files[1].
I'm keeping a close eye on the kFreeBSD-port -- I wouldn't mind getting off Linux and systemd, while remaining on Debian.
[1] https://github.com/akhilvij/systemd-to-sysvinit-converter
I remember that for a while, the primary criticism I heard of systemd was that it would make software linux-only because of systemd dependencies (gnome was the primary example given) and that it was impossible to write a compatibility wrapper. I guess the debian guys busted that myth.
Nope, they haven't. systemd-shim is a fundamentally unsustainable idea: http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...
I'm not sure I agree that it's an unsustainable idea to keep a wrapper updated. If people really are interested in it, surely they will keep it updated. Lots of open source projects bitrot, and the general reason is lack of interest in keeping them working. Given the number of times I've seen the non-portability complaint, it's especially surprising that noone but Steve Langesek (according to your link) has seen fit to contribute code.
I do agree though that it would be better if systemd standardised those interfaces that people want to use, such as the logind interface.
Steve Langasek was an Upstart project leader, and systemd-shim was never intended to be more than a temporary workaround, from what I know. Fact is, targeting the internal D-Bus interfaces is an exercise in perpetually playing catch-up.
edit-grammar
[1] - http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...
Ian Sutton, who embarked on a project to emulate some of the systemd D-Bus daemons, also attests to the "standardization" being largely a red herring: http://darknedgy.net/files/systembsd.pdf
I'm not sure I get how those slides indicate that the systemd interfaces are not standardized (with the possible exception of timedated, although the slides were kind of vague). Most of the problems seemed to be due to the fact that OpenBSD doesn't support PAM. Was there a particular section you were referring to?
More info http://undeadly.org/cgi?action=article&sid=20140915064856 it provides hostnamed, localed, timedated, and logind to packages that have this as a hard dependency.
I wrote a replacement for the systemd-timedated service for Fedora. The reason was simple, it could no longer control other NTP clients than systemd-timesyncd (which technically is just an SNTP client). With timedatex, users can now enable and disable with the "NTP sync" checkbox in GNOME any NTP client as was originally supported by systemd-timedated.
There are a bunch of people who submit articles from LWN. If you suspect shenanigans it's probably more useful to email HN. (I'm only guessing that though).
SystemD is cargo-culting Windows.
You don't specify which update tool you are using, but if it hasn't shown you that screen before that sounds like a bug.
EDIT: replying to digi_owl, as HN won't allow me to reply at a deeper nesting level.
> 1. you can actually do a kernel update without a reboot now, using certain tools.
To my knowledge, none of them are supported by debian, which was what the OP was talking about. Maybe he's using them, but then, it seems weird to complain about debian requiring reboots if he's gone to such lengths to prevent that problem in the past.
> 2. dbus was a reimplementation in C of dcop, the KDE IPC system. It was aimed at allowing desktop programs to talk to each other, not carry the whole OS on its back.
I'm not sure what that has to do with anything in my post.
> 3. drop the attitude. Or are you deliberately trying to derail the topic?
I'm not sure what attitude you refer to, it was not my intention to come off as hostile. Apologies to the GGP if that's how it sounded. I was merely pointing out that reboots for upgrades are not a new thing in debian, as the GGP seemed to be implying.
2. dbus was a reimplementation in C of dcop, the KDE IPC system. It was aimed at allowing desktop programs to talk to each other, not carry the whole OS on its back.
3. drop the attitude. Or are you deliberately trying to derail the topic?
Which Debian doesn't officially support, so they can't be expected to write update scripts for that use case.
Click on the timestamp of a post to get an immediate reply area.
[1] http://www.minix3.org/theses/Cristiano_Giuffrida_PhD_thesis....
[2] http://www.minix3.org/theses/Calin_Iorgulescu_Master_Thesis....
Systemd seems to handle updates fine. My only complaint is that it spams 1000+ lines to syslog when updating because every little change seems to cause it to (very verbosely) reinitialize its dependency tree.
* http://freedesktop.org/wiki/Software/systemd/SystemUpdates/
* http://www.freedesktop.org/software/systemd/man/systemd-syst...
* https://lists.debian.org/debian-devel/2015/08/thrd2.html#004...
I look at the above; I look at what was said by the person that you're replying to; and the conclusion as to whether that person knows what xe is talking about comes out rather differently.
edit: Look how Arch dev says they won't probably ever use it: https://bbs.archlinux.org/viewtopic.php?id=145265, just because systemd gives you an ability to do something people actually want, you can't blame systemd for a distro that uses that feature.