How Debian managed the systemd transition
Debian's decision to move to systemd as the default init system was a famously contentious (and rather public) debate. Once all the chaos regarding the decision itself had died down, however, it was left to project members to implement the change. At DebConf 2015 in Heidelberg, Martin Pitt and Michael Biebl gave a down-to-earth talk about how that implementation work had gone and what was still ahead.
Pitt and Biebl are the current maintainers of the systemd package in Debian, with Pitt also maintaining the corresponding Ubuntu package. The pair began with a brief recap of the init-replacement story, albeit one that steered mercifully clear of the quarrels and stuck to the technical side. Initial discussions for replacing the System V init system began as far back as 2007, but pressure grew in recent years, included considerable demand from system administrators and upstream projects (typically wanting specific features like support for logind or journald). Once the Technical Committee had made its decision to adopt systemd as the default, Pitt said, "the real work" began.
The jessie release
Only a few months remained between the decision (in February of 2014) and the first freeze for "jessie" that November. Nevertheless, the migration was completed and jessie shipped with systemd 215. In the end, Biebl said, getting systemd into shape turned out not to be as big of a deal as had been feared—the systemd package in "wheezy" was well-tested. On the other hand, the requirement that administrators would be able swap in one of the other init-system packages added quite a bit of complexity. First, the old init system had long been marked as "essential," which meant that removing it required the user to fight quite a few warnings and protests from the package manager and other software. And, just as importantly, the idea of easily swapping init systems in and out was a new one for Debian.
Eventually, the systemd team split the existing sysvinit into several packages, which made it easier to cope with dependent packages that assumed some part of sysvinit would be available. The team also created a new init meta-package, which allowed them to ensure that users would not accidentally remove all of the init-system packages from their system.
Supporting init-system swapping is not merely a package-management problem, however: users are likely to expect some system state to be preserved between any two init systems. For example, if a service is started at boot time by one init system, the user likely expects that service to be started in a comparable fashion under the other init system, too. To ensure this preservation of state, the team re-implemented a subset of systemd's systemctl interfaces in a new package called init-system-helpers.
![[Michael Biebl]](https://static.lwn.net/images/2015/09-debconf-biebl-sm.jpg "Michael
Biebl")
Along the way, team members also created a package called dh-systemd, which lets Debian package maintainers ensure that their package will be properly configured regardless of which init system the user employs. Finally, they created the systemd-shim package, which supports certain downstream projects like GNOME that have hard-coded dependencies on individual systemd components.
Although the team worked to develop these interface and compatibility packages, it took a different approach when considering what to do with sysvinit's collection of configuration files—such as those in /etc/default or /etc/rcS.d. "The major reason was that we would have to carry a patch for that for all eternity," Biebl said. So they performed a one-time migration of several such settings files.
The integration work consisted of a lot of small changes, Biebl said, "but I think we succeeded. I think that people don't realize that they are using systemd." He noted that people have actually approached him asking how they can start using systemd and been surprised when he told them that they already are.
Along those same lines, he noted that users who upgrade an older Debian system configured with sysvinit to the jessie release are automatically migrated to systemd, and few have noticed. The goal in undertaking this "scary" change, he said, was to have jessie systems be the same regardless of whether they are new installations or updated ones. For upgraded systems, though, there is a fallback sysvinit init binary installed, complete with a bootloader option to boot the system with it if the user encounters a problem with systemd.
There are bugs in every software package, of course. Biebl said that the team braced for a flood of bug reports when jessie was released, but that flood never came. Most of the bugs that have been reported have stemmed from the fact that systemd is stricter in situations where sysvinit tries to hide errors. For example, Pitt said, Debian had a longstanding bug in its ecryptfs-setup-swap package; systems ended up getting configured with unencrypted swap or no swap at all, and thanks to sysvinit, no one noticed for several years. But systemd complained, and now the bug has been fixed.
Looking forward to stretch
Pitt then turned the discussion to the changes that are in store for the next Debian release, "stretch." The first change is to udev, which will begin assigning predictable, stable names for network interfaces (in place of names using the ambiguous "eth0" form). This change has already landed, he said, and should fix problems that many users have encountered in the past. But there are some wrinkles involved: interface names cannot be migrated to the new format automatically when upgrading to stretch, because doing so could break (for example) firewall rules written with the old names in mind.
![[Martin Pitt]](https://static.lwn.net/images/2015/09-debconf-pitt-sm.jpg "Martin Pitt")
Another upcoming change is support for networkd, a lean interface for bringing up and taking down network interfaces. Pitt noted that there have been a lot of questions about whether networkd is meant to replace NetworkManager. It is not, he explained; rather, it is akin to ifupdown in its scope. But Debian users will benefit from it because it better handles virtual interfaces and hot-plugging.
Biebl explained another change that is still in the works: the ongoing process of removing sysvinit's rcS.d scripts. There is a wiki page detailing the current status and the roadmap of the process. Because these scripts are executed early in the boot process, they can be difficult to remove, and the removals can trigger dependency cycles. He noted that Felipe Sateler has started working on this task, and in doing so has located quite a few packages that need attention from their maintainers.
Other systemd-related changes that may or may not land in time for stretch include the addition of kdbus support. The Debian systemd team regards kdbus as a beneficial addition, since it would be available at the earliest stages of the boot process, but whether Debian includes it will depend on its inclusion in the kernel. There is, of course, an out-of-tree kdbus module, and Debian users interested in testing it out can do so using the systemd tools packaged for Debian unstable.
There are plenty of opportunities for new volunteers to help out, Pitt and Biebl said. But, just as importantly, Debian developers and package maintainers could start taking advantage of systemd's "shiny new features," including timers, socket activation, or security confinement. Where things go from here, in other words, depends at least as much on how Debian as a whole chooses to use its init system as it does on the team that maintains the init-system packages.
[The author would like to thank the Debian project for travel assistance to attend DebConf 2015.]
| Index entries for this article | |
|---|---|
| Conference | DebConf/2015 |
Posted Sep 16, 2015 21:48 UTC (Wed)
by luto (guest, #39314)
[Link] (43 responses)
Sure, you don't easily get to switch it to something running from /usr, but the kernel works like that as well.
Posted Sep 16, 2015 22:03 UTC (Wed)
by airlied (subscriber, #9104)
[Link] (42 responses)
Posted Sep 16, 2015 22:11 UTC (Wed)
by luto (guest, #39314)
[Link] (41 responses)
#!/bin/sh
It may be traditional for initramfs code to delete itself and make sure that no references to the old initramfs are left before execing the real init, but it's certainly not a requirement.
Posted Sep 16, 2015 22:19 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
Posted Sep 16, 2015 22:28 UTC (Wed)
by luto (guest, #39314)
[Link] (8 responses)
Similarly, if systemd is killed or fails to start, you panic.
Posted Sep 17, 2015 1:33 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted Sep 17, 2015 1:36 UTC (Thu)
by luto (guest, #39314)
[Link] (5 responses)
Posted Sep 17, 2015 4:25 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted Sep 17, 2015 5:59 UTC (Thu)
by luto (guest, #39314)
[Link] (1 responses)
The kernel promises not to die unless PID 1 dies (or a bug happens or your block device dies or...). But unless your distro promises to survive a SIGKILL to all processes, I think you're on your own if you try that.
Posted Sep 17, 2015 7:39 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Sep 19, 2015 14:13 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (1 responses)
Posted Sep 19, 2015 21:00 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Sep 17, 2015 8:02 UTC (Thu)
by fishface60 (subscriber, #88700)
[Link]
If you do an exec() and it fails from some corruption of the page tables, or the executable at the wrong time without going through the file system (since you get -ETXTBUSY when trying to do anything with an executable file while a process is mid-exec on it), then the process is killed with an inescapable SIGKILL.
This is relevant for systemd, as there's a few circumstances where systemd will exec.
1. When shutting down it exec's systemd-shutdown, which primarily exists so that PID1 isn't holding files open and preventing a clean unmount.
Posted Sep 16, 2015 22:29 UTC (Wed)
by josh (subscriber, #17465)
[Link] (30 responses)
Posted Sep 16, 2015 22:33 UTC (Wed)
by luto (guest, #39314)
[Link] (29 responses)
Also, note that kdbus already requires that systemd, as its very first act (or really quite early, anyway) mounts kdbus and connects to it. This isn't very different. Kdbus would certainly not be monitored the way every other daemon is.
Posted Sep 16, 2015 22:41 UTC (Wed)
by josh (subscriber, #17465)
[Link] (28 responses)
kdbus came about partly because of the need for such special handling, partly because that handling gets more complicated when an initramfs gets involved, and partly because dbus-daemon had such issues like "cannot be restarted or everything goes pear-shaped", which a robust system shouldn't have.
What's the *advantage* of trying to launch dbus-daemon from the initramfs?
Posted Sep 16, 2015 22:54 UTC (Wed)
by luto (guest, #39314)
[Link] (27 responses)
It has a big advantage over the current scheme: you can start it early and still don't need to worry about restarting it. It has no advantage over kdbus in terms of where the code is loaded from or ease of initialization, but I don't think it has a disadvantage either.
AIUI, the current scheme comes from the idea that all userspace code running after startup must reside on a non-initramfs mount. I've heard people say that it's not even possible to keep an initramfs program running after pivot_root. This is simply incorrect. Back when initramfs was actually ramfs, it wasted unpageable memory (just like kernel code), but initramfs is tmpfs nowadays.
Heck, there's no fundamental need for systemd to re-exec itself after pivot_root either, although, given that daemon-reexec is well-supported, it's probably a good idea from a forced testing and memory conservation perspective.
As a concrete, if dubious, benefit, udevd really could depend on dbus even without kdbus. Just require that dbus-daemon be started before udevd. (If this happened, I would drop udevd as part of the virtme minimal guest and I'd seriously consider busybox's udev as an alternative, but that a bit off-topic.)
Posted Sep 16, 2015 23:08 UTC (Wed)
by josh (subscriber, #17465)
[Link] (26 responses)
It does have at least two disadvantages there. First, getting dbus-daemon and all of its dependencies into the initramfs would prove rather annoying. Statically linking it isn't a solution (distros, dependency management, and static linking don't mix well), and adding a pile of libraries to the initramfs doesn't appeal. But even after doing that, which is certainly doable, "don't need to worry about restarting it" is a bug, not a feature; dbus-daemon is apparently utterly incapable of handling a restart, but it needs to restart on upgrade. kdbus doesn't have that problem, because it doesn't need a userspace daemon. (It needs some initial setup, but systemd does that, and systemd handles upgrades just fine.)
Posted Sep 16, 2015 23:24 UTC (Wed)
by luto (guest, #39314)
[Link] (25 responses)
I think your argument here is a bit confused. dbus-daemon is indeed apparently utterly incapable of handling a restart, so you can't upgrade it without rebooting (or blowing up everything that depends on it). But the kernel and, hence, kdbus, is utterly and completely incapable of being upgraded without rebooting, so the behavior is similar.
I would argue that the real issue with current distros is that they might actually try to upgrade dbus-daemon on disk *and restart it without rebooting*, which is doomed unless a *userspace* dbus daemon gets a major rewrite.
So I still don't see how kdbus is any better at all in this regard, aside from the fact that distros have already figured out how to build the kernel as a self-contained thing but might have trouble building a minimal static dbus-daemon. (It would work fine as a dynamic library with eager binding, too, but that's ugly.)
I'll grant that kdbus is probably a much more streamlined, self-contained piece of code than dbus-daemon, but that's more or less irrelevant wrt this issue.
Also, the userspace approach has a huge advantage here: you can run different versions of it in different containers.
Posted Sep 17, 2015 0:27 UTC (Thu)
by einstein (guest, #2052)
[Link] (3 responses)
Actually, the kernel can be upgraded without a reboot. I was using ksplice for that back in 2009 or so, and the feature is coming together in mainline.
Posted Sep 17, 2015 0:32 UTC (Thu)
by luto (guest, #39314)
[Link] (2 responses)
I've gotten emails from the ksplice team asking me how the heck they're supposed to handle a small number of individual entry changes I've made, and those are tiny compared to replacing the whole kernel.
* Within some reasonable limits.
Posted Sep 17, 2015 0:47 UTC (Thu)
by josh (subscriber, #17465)
[Link]
I'd argue that if you can successfully save userspace, kexec a new kernel, and seamlessly reload userspace, that's a huge accomplishment that counts as a "live" kernel upgrade.
Posted Sep 22, 2015 16:20 UTC (Tue)
by jejb (subscriber, #6654)
[Link]
Hey, that's not fair: to go from n to n+1 you know the only way is to save and restore the kernel state in a version independent manner, so you're trying to define the only possible method out of your challenge. The problem with the method is the time it takes, but there are people working on it
Posted Sep 17, 2015 1:07 UTC (Thu)
by josh (subscriber, #17465)
[Link] (20 responses)
(I'm going to ignore the case of unloading and reloading kdbus.ko, here, because I doubt you can do that without stopping all dbus users, so that doesn't count either. It does mean you could upgrade kdbus without upgrading the kernel, but that won't make sense once kdbus gets merged into the kernel. It also doesn't address your point.)
So, my contention is that if you ran dbus-daemon from the initramfs, then in addition to the pain of building a dbus-daemon that can run from the initramfs, while handling services and configuration files both from the initramfs *and* from the root filesystem, you'd also have cases where you need to reboot to upgrade dbus-daemon, because you want to upgrade the corresponding userspace and your userspace can't cope with an old dbus-daemon. (It *especially* can't cope with the dbus package getting upgraded on the filesystem but the running version being older than the installed package.)
Posted Sep 17, 2015 1:32 UTC (Thu)
by luto (guest, #39314)
[Link] (19 responses)
Sure, kdbus doesn't read config files, but there is no reason whatsoever that a userspace dbus daemon should need to read config files, especially if it's aiming for feature parity with kdbus. Similarly, kdbus claims ABI compatibility, but a userspace dbus daemon really ought to do the same.
I get kind of annoyed when kdbus gets compared to dbus-daemon-as-it-exists and the favorable comparisons are used as an argument for why kdbus is a good idea. Dbus-daemon has all kinds of problems, but, after reading far too many emails about it and thinking about it for far too long, I'm having trouble believing that there is a single respect in which kdbus solves a problem that a simple, streamlined userspace daemon can't easily solve.
If current dbus-daemon barfs when its package is upgraded under it, that's *pathetic*, but it's still not a good reason why distros should be excited about kdbus.
(The streamlined userspace daemon would need help from an improved AF_UNIX credential mechanism, but that's easy.)
Posted Sep 17, 2015 2:07 UTC (Thu)
by josh (subscriber, #17465)
[Link] (15 responses)
That hypothetical non-crufty daemon would almost never need upgrading, sure. And neither does kdbus, so the comparison works. But the dbus-daemon we have *today* doesn't belong in an initramfs, and that's where this discussion started. And I see a distinct lack of people working on a hypothetical non-crufty dbus-daemon, hence why it remains hypothetical.
Apart from that, I can think of several things kdbus can do that an arbitrarily lightweight dbus-daemon can't, which explains part of why nobody seems to want to work on a hypothetical non-crufty dbus-daemon. Most notably, it eliminates a context switch from every message passed (two from every round-trip). If you had a "non-crufty" dbus-daemon that didn't need to touch the actual messages, what remaining non-cruft purpose does the daemon serve? Even having dbus-daemon involved in setup or broadcasts represents unnecessary overhead.
Posted Sep 17, 2015 2:32 UTC (Thu)
by josh (subscriber, #17465)
[Link] (1 responses)
Posted Sep 17, 2015 5:55 UTC (Thu)
by luto (guest, #39314)
[Link]
Dbus is a nasty model for things like filesystems, though. Some kind of fast capability-based transport would be much better suited, especially since a file descriptor (or directory reference or whatever) maps quite nicely to a capability.
Posted Sep 17, 2015 5:52 UTC (Thu)
by luto (guest, #39314)
[Link] (12 responses)
But context switches should be decently under 2 µs on a modern system. (The atrocious performance of libgdbus + dbus-daemon has *nothing* do with with the extra context switch.) With some optimization, which certainly could be done, I bet we can significantly improve context switches performance.
In any event, for applications that care about throughput, the extra context switch is a red herring. Under load, a good central daemon will process many messages per time slice, so the throughput bottleneck is much more likely to be message routing and such rather than context switches. Under that type of load, having a central daemon shouldn't by much slower than doing everything in the kernel. Kdbus is IMO unlikely to be particularly fast in terms of CPU time used per message because the per-message processing is rather complex.
With a userspace mechanism built on top of a serious IPC primitive, the extra context switch goes away because the central daemon can easily introduce parties for direct communication. Linux has no such mechanism (other than SCM_RIGHTS). seL4 does, and I suspect (although I don't know for sure) that the other L4 systems do as well. Binder also looks reasonable for such uses, even though it's rather crufty in other respects.
For dbus in particular (userspace or kernel), I think that good performance under load will be tough, because dbus has a reliable in-order broadcast model. If everyone can broadcast to everyone in order, then the overall system needs to buffer each message until every receiver has read it. Since the senders and receivers are all asynchronous, that can be a lot of buffering. For kdbus in particular, the fancy "pool" model means (AFAICT) that all of the broadcast messages need to be buffered *separately* for each receiver. IMO this will work considerably worse than just doing it with a lightweight userspace daemon. Realistically, though, the fully-ordered broadcast model seems unlikely to hold up under load with *any* implementation whatsoever.
Posted Sep 23, 2015 9:33 UTC (Wed)
by paulj (subscriber, #341)
[Link] (10 responses)
That pressure will be hard to deflect by pointing out the correct solution to an inefficient user-space implementation is not a very $FAVOURED_IPC_OF_THIS_DECADE-specific kernel implementation, but instead to implement an efficient user-space implementation + whatever generalised kernel services are needed for IPC problems in the abstract. To deflect that pressure for good requires coming up with that efficient user-space implementation really.
Posted Sep 23, 2015 9:47 UTC (Wed)
by lgeorget (guest, #99972)
[Link] (2 responses)
Actually, if I recall correctly the discussions on that matter, the main advantage of the in-kernel implementation of dbus was not that it reduces the number of context switches but that it reduces the number of memory copies because for the kernel, unlike a user-space daemon, copying memory can be as simple as mapping the same pages in two processes.
> those people (like any others) aren't keen to have their work wasted, there will now be pressure to integrate it.
As far as I can tell from reading the mails on the Linux mailing list, Greg Kroah-Hartmann has shown to be very professional. He would surely be pleased to see his work in the mainline kernel, but not to the point to "pressure" anyone.
Posted Sep 23, 2015 15:06 UTC (Wed)
by luto (guest, #39314)
[Link]
For small messages, this barely matters, and for large messages, both kdbus and AF_UNIX users can use memfds, which does even less copying.
Actually, for small messages, I'll only believe that the kdbus approach is faster if someone benchmarks it cleanly. The saved copy is only possible because the kernel writes to the receiver's pool when the message is sent, and that means that the kernel has to map the receiver's pool, and that's not free. (In fact it can be very slow -- modern CPUs are very good at mapping things, but at least x86 makes *unmapping* extremely expensive.)
Posted Sep 23, 2015 15:51 UTC (Wed)
by dlang (guest, #313)
[Link]
So the 'official' justification for kdbus is no longer performance, but rather security and/or reliability
Posted Sep 23, 2015 16:29 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (6 responses)
I've been on the sidelines, following development on LWN, but that doesn't seem representative of the people involved or the effort which has gone into this, so I wouldn't presume that at all.
> not having questioned the notion that the performance problems with dbus-daemon were to do with kernel-userspace transitions
I believe there was awareness that the existing dbus-daemon implementation was not performant but also awareness that even a perfectly implemented userspace daemon has an upper limit on what it can do because of serializing, memory copying and context switches. Experience with the X Window protocol is instructive here as it sits in a very similar place in the software stack and there was a desire for dbus to be able to scale to the point of handling graphics data, which has already been demonstrated with X that a userspace daemon cannot do this without kernel support. Less copying and less context switches are also a boon for power usage which is becoming more important every year, both for battery powered and datacenter devices.
> efficient user-space implementation + whatever generalised kernel services are needed for IPC problems in the abstract.
This was the original goal and implementation many years ago but was flatly rejected by the kernel developers who would have needed to approve it which is why we have the kdbus implementation we have today as opposed to some other design. The original thought would be for a multicast AF_UNIX type socket that a userspace daemon could control which would be capable of zero-copy message delivery but the network subsystem maintainers refused to entertain the changes required to make something like that work and be supportable, so a different design which is much more self-contained is being proposed instead.
Posted Oct 9, 2015 23:29 UTC (Fri)
by nix (subscriber, #2304)
[Link] (5 responses)
You don't need to be the kernel to share memory... and with memfds, you don't even need to be the kernel to share memory with untrusted partners.
Posted Oct 10, 2015 1:24 UTC (Sat)
by raven667 (subscriber, #5198)
[Link] (4 responses)
Posted Oct 13, 2015 13:50 UTC (Tue)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted Oct 13, 2015 14:45 UTC (Tue)
by nybble41 (subscriber, #55106)
[Link] (2 responses)
I think one could argue that being given direct access to the graphics hardware, and thus effectively unlimited access to the entire system, should count as "kernel support". Sure, the driver code was inside the X server rather than compiled into the kernel or a loadable module, but it still required special interfaces used primarily by X, and it wasn't possible to run the X server as an ordinary, non-root user process.
Posted Oct 13, 2015 15:09 UTC (Tue)
by raven667 (subscriber, #5198)
[Link] (1 responses)
We've already gone down the route of adding dedicated IPC APIs for SysV, for Netlink, for X/Wayland and now for DBUS, which I see as following the evolution of OS design and the needs of the applications of the era when these interfaces were designed.
Posted Oct 13, 2015 22:49 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Sep 25, 2015 22:24 UTC (Fri)
by oak (guest, #2786)
[Link]
Result is that daemon message buffers grow until they take all your memory, your system message transport goes to swap (with everything else) and things become *really* slow until the problematic client is killed. If the client is woken up, daemon and client can spend many minutes (or hours depending on how much swap & buffering you have) during which bus isn't very responsive. If allocations were mixed well enough, emptying the message buffer on daemon doesn't actually free its dirtied memory because it's gotten fragmented.
This is D-BUS experience from 5-10 years ago on semi-embedded device. Even worse, the user-space daemon gets it's memory fragmented very easily and doesn't return to system memory it's once allocated. So, local DOS is trivial to do with any client that can connect to bus.
Some of the things where kernel *might* be able to improve on this are:
Posted Sep 17, 2015 6:11 UTC (Thu)
by alison (subscriber, #63752)
[Link] (2 responses)
Performance of Dbus-daemon aside, what about the more abstract question of whether a new message-passing API inside the kernel makes sense? From the shear design point of view, why does the kernel provide 3 notification services for userspace via fanotify, dnotify and inotify? Presumably the rationale for adding fanotify to dnotify and inotify was that fanotify was superior. Why does that rationale not apply to kdbus?
Both kdbus and Dbus-daemon will continue to evolve. The issue of whether the kernel should have a new feature would logically be decided on the basis of what the kernel's rightful role is. Mostly the kernel's job is to abstract away the details of hardware and to provide userspace with services (e.g. boot) that it would have difficulty managing itself. Is IPC like that provided by kdbus such a service, or no? If not, why is it fundamentally different from notification, to which it seems logically related?
Posted Sep 17, 2015 11:46 UTC (Thu)
by lsl (subscriber, #86508)
[Link] (1 responses)
Wasn't the "rationale" more like "we hope it makes snake oil vendors stop torturing our enterprise kernels with horrible out-of-tree modules"? At least that's what I remember from it. It wasn't any less drama than kdbus. Also, it didn't get merged until attempts were made to rework it to be more generally useful, for tasks other than implementing snake oil products.
Posted Sep 23, 2015 20:35 UTC (Wed)
by foom (subscriber, #14868)
[Link]
Posted Sep 17, 2015 2:11 UTC (Thu)
by dskoll (subscriber, #1630)
[Link] (25 responses)
I've upgraded a number of systems from Wheezy to Jessie and it really was quite painless. The only real difference I've noticed is that the systemd-enabled Jessie machines boot a whole lot faster than they did when they were Wheezy.
Posted Sep 17, 2015 5:48 UTC (Thu)
by alison (subscriber, #63752)
[Link] (2 responses)
Posted Sep 17, 2015 9:12 UTC (Thu)
by salimma (subscriber, #34460)
[Link] (1 responses)
Posted Sep 17, 2015 22:54 UTC (Thu)
by zlynx (guest, #2285)
[Link]
I've been using btrfs on my Fedora laptop and a small home file, backup and email server since F20. No problems.
Posted Sep 17, 2015 15:46 UTC (Thu)
by deater (subscriber, #11746)
[Link] (21 responses)
For example, on my headless network gateway, the drive with the /home partition failed ( / was fine).
Instead of just booting with the /home drive removed, it instead sat there on the console with a fancy and colorful display letting me know that a partition was missing, counting down for a few minutes before in the end just totally giving up and dropping to single-user mode. Without bothering to start packet forwarding first. This was a headless machine, so my network was down until I could drag a monitor and keyboard over to figure out what was going on.
I've had a few other surprises like this. And I guess that's par for the course when transitioning such a big system component over, but I find myself spending a lot of time fighting against systemd in cases where things used to "just work".
Posted Sep 17, 2015 16:30 UTC (Thu)
by MarcB (subscriber, #101804)
[Link] (18 responses)
Before Systemd the "nofail" flag was the default (more or less - errors were reported on the console but they did not block anything). Now, users have to explicitly set the flag if they think that it is OK if a specific automatic mount fails.
I *very* strongly prefer the new behaviour.
The old behaviour could lead to undefined system behaviour, especially when combined with the fact that folders do not need to be empty when mounting something into them.
We once had long deprecated software versions running on a system when a network mount failed silently. Fortunately, the input format had changed in the meantime, so that the old software failed completely - and complained loudly - instead of just producing formally correct but logically wrong output. The latter could have gone unnoticed for months and would have cost a lot of money. (Of course, it was a mistake to just mount a network filesystem over the previously local installation in the first place, but stuff like that happens.)
Posted Sep 17, 2015 21:15 UTC (Thu)
by deater (subscriber, #11746)
[Link]
Documented in the basement behind a sign saying "beware of leopard"?
I still think it's a fairly major and surprising change, though I can grudgingly see why an upgrade to systemd wouldn't want to update the fstab file to make all mounts nofail for backward compatability reasons.
Posted Sep 18, 2015 1:11 UTC (Fri)
by mchapman (subscriber, #66589)
[Link] (11 responses)
To add to this, it could be argued that the default hasn't changed, and that the old behaviour was just plain wrong. The mount(8) manpage documents a "nofail" option, but there is no corresponding "fail" option. This seems to imply that "fail on error" was always intended to be the default behaviour, and that the old pre-systemd initscripts had simply got it wrong.
I don't actually agree with this view -- if the old behaviour is what distros used then the documentation should have been written to say that -- but I can certainly see the logic in it. I do prefer systemd's stricter handling of mount points during boot though.
Posted Sep 18, 2015 2:15 UTC (Fri)
by dlang (guest, #313)
[Link] (10 responses)
it's worth going and reading his full post.
This attitude of "well, if we broke it, it was wrong anyway" is part of the reason people distrust the systemd folks so much.
Posted Sep 18, 2015 4:17 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
I said it was "logical", not that it was right. :-)
Posted Sep 18, 2015 10:41 UTC (Fri)
by MarcB (subscriber, #101804)
[Link]
There explicitly is no stability guarantee in the latter case (as evidenced by every major distribution's release notes). If you do a major upgrade - if your distribution supports that at all - you have to read the release notes, understand them and perform any extra steps that apply to your system. This has always been the deal.
Of course, individual users might have gotten away without doing that in the past. They were lucky.
Just to make this clear: Had Debian made such a change within the life-cycle of a distribution, I would have been really annoyed.
Posted Sep 18, 2015 14:01 UTC (Fri)
by deater (subscriber, #11746)
[Link]
I thought that qotw was posted ironically due to the number of times his projects have broken various ABIs.
Posted Sep 18, 2015 19:08 UTC (Fri)
by davidstrauss (guest, #85867)
[Link] (6 responses)
systemd may have a default and an opinion, but it was Debian's prior, unusual default that created this divergence. If you're Saab -- with a long history of having the ignition in the center console -- and switch to stock parts, it is not the fault of the stock steering column manufacturer that ignition is now in a different place than you had put it before.
Also, Debian could have chosen to configure the post-upgrade system to carry over "nofail," but they didn't. It's not like systemd forces you to have mounts fail hard. Complain to the Debian maintainers if you don't like the way they're choosing to configure systemd.
Posted Sep 26, 2015 10:22 UTC (Sat)
by rleigh (guest, #14622)
[Link] (5 responses)
Posted Sep 26, 2015 11:16 UTC (Sat)
by zdzichu (subscriber, #17118)
[Link] (4 responses)
Posted Oct 9, 2015 22:49 UTC (Fri)
by nix (subscriber, #2304)
[Link] (3 responses)
This is a very legalistic (read, unhelpful) way to make a system. It's a way to make a system that, to be blunt, doesn't work very well.
Posted Oct 10, 2015 9:24 UTC (Sat)
by zdzichu (subscriber, #17118)
[Link] (2 responses)
Posted Oct 10, 2015 9:49 UTC (Sat)
by cebewee (guest, #94775)
[Link] (1 responses)
> you should read Ingo's comments from the kernel qotw http://lwn.net/Articles/657428/
Now, there are of course cases where breaking changes are justified (and I won't judge whether this was the case here), but you cannot blame people for being upset when said changes break their system.
Posted Oct 11, 2015 0:15 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted Sep 19, 2015 14:21 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (4 responses)
Posted Sep 19, 2015 15:16 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Posted Sep 19, 2015 18:36 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (2 responses)
Posted Sep 19, 2015 21:52 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
Posted Sep 19, 2015 22:04 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
> Lack of security support for the ecosystem around libv8 and Node.js
I wonder how many will ignore this :( .
Posted Sep 18, 2015 14:00 UTC (Fri)
by drag (guest, #31333)
[Link] (1 responses)
How is this different then what was life was like before systemd?
This sort of crap is why 'enterprise' machines have things like ILOM and iDrac and before that serial terminal servers.
Posted Sep 19, 2015 0:55 UTC (Sat)
by deater (subscriber, #11746)
[Link]
For the previous 20 years I've run Linux/UNIX, if /home was unable to mount, the system would continue anyway and just do without. You could still log in, but obviously your files wouldn't be there and ssh and login might complain loudly. Then you could remotely do whatever was needed to get /home fixed/restored.
The new behavior unhelpfully just dumps you to a prompt, which is bad if you are headless and depending on being able to ssh in (or even worse, the machine is your network gateway so all of your other systems drop off the net because packet forwarding never gets started).
The machine doesn't have iLOM. A serial console would have helped in this situation but I have a lot of machines and it would be a wiring nightmare for all of them to have serial consoles.
So anyway yes, this is a distribution issue not necessarily an init issue. It's just hard when your 20-year old mental model of how a Linux server behaves is majorly changed without much warning. I'm used to other major OSes playing this game but I've been spoiled by Debian being a bit more sane over the years.
Posted Sep 18, 2015 2:19 UTC (Fri)
by flussence (guest, #85566)
[Link] (22 responses)
I hope, for all Debian users' sake, that they've gone an extra mile flushing out all the bugs in that.
I've seen quite a few instances (in Gentoo, which adopted it years ago) where someone's network setup was broken due to it: bus enumeration races causing a USB wifi dongle to change names every boot, the rules flip-flopping between bus and MAC naming patterns between udev versions, the "en"/"wl" prefix sometimes going missing entirely, and even multiple of these problems striking at once during the jump from install media to finished system.
In ten years of using it and participating in their help forums, I've yet to come across a *single* complaint that eth0 unexpectedly became eth1. Maybe Gentoo users simply lack sufficiently insane hardware?
Posted Sep 18, 2015 3:02 UTC (Fri)
by dlang (guest, #313)
[Link] (17 responses)
If my laptop only has one ethernet interface, "eth0" is predictable and stable.
enx00249b0e398f is neither (and yes, this is exactly what the new udev gave me for my laptop)
Now, I have managed a lot of systems with lots of interfaces over the years (22 gig-e interfaces on one system was one of my 'standard' configs).
I have had a couple cases where interface names have changed during kernel upgrades.
In one case it was because a new driver enabled an interface that previously had been unsupported
In the other case, it was because a different driver was used to support one card and it got sorted ahead of the other driver supporting other cards.
I can understand that people who do everything with modules loaded at runtime can run into grief by loading the modules in a different order, but this falls under the category of 'it hurts when I do that, so stop doing that'
Debian has for years supported pinning the interface names to the MAC addresses based on the detection order the first time the OS booted. This has actually caused me more grief than anything else, because when I replaced the card that held eth0-eth3 with an identical card, now I had eth22-eth25 and no eth0-eth3 (until I removed the udev rule that did this)
If you can't tell, I think the new udev 'solution' is far worse than any problem it may solve.
the good news is that it's fairly easy to disable
# ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
unfortunately this doesn't give me eth0 back, it's now usb0, but at least I don't have to remember the 12 digit hex id!
Posted Sep 18, 2015 13:31 UTC (Fri)
by epa (subscriber, #39769)
[Link] (12 responses)
Posted Sep 18, 2015 17:26 UTC (Fri)
by kreijack (guest, #43513)
[Link] (11 responses)
BTW I never seen a swap of the ethernet cards; may be that I use only PVI ones ?
Posted Sep 18, 2015 18:13 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Posted Sep 19, 2015 14:34 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (3 responses)
Then we could have /dev/net/by-{index,slot,path,mac} symlinks pointing to the original /dev/eth0 and friends. Both the original names and the predictable names would be there for those who use them, and all names would be usable simultaneously.
That way, so you no longer have to worry about a network interface having its name changed from eth0 to enp0s3 when you reboot with a newer version of udev, as happened to me last week.
You would also be able to pick and choose which name you want to use depending on your use case, just as how, with disks, it's sometimes useful to use the symlink in /dev/disk/by-path for a disk that is commonly hot-swapped (such as a backup disk you change every week) but at the same time it is useful to use /dev/disk/by-uuid for a permanently-mounted filesystem, such as / or /home.
Posted Sep 19, 2015 20:40 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Adding new functions that work with regular device nodes is certainly possible, but probably nobody cares too much about it.
Posted Sep 20, 2015 0:02 UTC (Sun)
by dlang (guest, #313)
[Link] (1 responses)
Posted Sep 20, 2015 7:37 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
And the second problem is that you don't actually _need_ your devices to be mounted at '/dev'. A device node can be anywhere on the system.
It doesn't even require anything exotic - a host might simply with to get info about a TAP/TUN device in a container.
The correct way to fix it would be by creating a new API that uses file descriptors instead of interface names.
Posted Sep 20, 2015 10:29 UTC (Sun)
by kreijack (guest, #43513)
[Link]
May be that *now* doesn't exist a technical solution for doing that. But I don't see any reason which prevent us to implement it.
Posted Sep 19, 2015 1:34 UTC (Sat)
by dlang (guest, #313)
[Link] (4 responses)
a swap can happen if you have cards that use different drivers and the driver load order changes (either from driver renaming if the drivers are statically linked, or the device discovery order if they are modules)
a swap can also happen if the bus the cards are on does not have an order and orders based on the order devices respond. I'm told that USB can detect the physical location of a device, but asaik, all the drivers ignore this and rely on which device responds first to device probing.
But if the device has a MAC address as part of the device, the existing tools can keep the ordering consistant.
If there is no such identifier built into the card, I don't believe that the new process is really any more reliable.
Posted Sep 20, 2015 10:22 UTC (Sun)
by kreijack (guest, #43513)
[Link] (3 responses)
What I mean is that linking the ethernet name to the hardware is useful in some contexts, but in others not; and I suspect that these "others" are more common than the former...
Posted Sep 20, 2015 10:52 UTC (Sun)
by dlang (guest, #313)
[Link]
Posted Sep 25, 2015 20:16 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
You mean, like in a firewall, for instance ...
I saw a comment somewhere where eth0 and eth1 got swapped. In other words, until someone noticed, the firewall's soft, unprotected, meant for the internal network, interface was the interface to the hostile outside world ...
Cue major panic, lan disconnected from the internet, rebuild the firewall from scratch, ...
At the end of the day, unpredictable behaviour is a security risk. What I think happened was that the system had always been booted from cold, and had always been predictable. Then for some reason, one day it did a warm-start, and came back with the interfaces swapped over ... oops ...
Cheers,
Posted Sep 25, 2015 20:36 UTC (Fri)
by dlang (guest, #313)
[Link]
Yes, it is possible to configure a system so that it's IPs and routes will swap with the interface changes, but the firewall rules won't, but that's getting into rather contrived territory.
Posted Sep 18, 2015 16:42 UTC (Fri)
by HenrikH (subscriber, #31152)
[Link] (3 responses)
Posted Sep 19, 2015 18:08 UTC (Sat)
by cortana (subscriber, #24596)
[Link] (2 responses)
Posted Sep 20, 2015 0:04 UTC (Sun)
by dlang (guest, #313)
[Link] (1 responses)
It may be that I got bit by the rename due to card changes and disabled it entirely before the odds caught up with me.
Posted Sep 20, 2015 13:14 UTC (Sun)
by cortana (subscriber, #24596)
[Link]
Posted Sep 18, 2015 15:59 UTC (Fri)
by lsl (subscriber, #86508)
[Link] (1 responses)
Posted Sep 18, 2015 19:12 UTC (Fri)
by lsl (subscriber, #86508)
[Link]
Posted Sep 20, 2015 12:09 UTC (Sun)
by patrakov (subscriber, #97174)
[Link]
Posted Oct 5, 2015 14:22 UTC (Mon)
by Creideiki (subscriber, #38747)
[Link]
I've had a batch of computers, all the same nominal model from the same (big) manufacturer, all installed from the same netboot image, half calling their only Ethernet interface one thing and half calling it another. System administration scripting was so much easier when all machines had an eth0 connecting to the main network.
Posted Sep 24, 2015 4:09 UTC (Thu)
by jb.1234abcd (guest, #95827)
[Link] (5 responses)
The plot:
Recently a poster presented a view of systemD(efeat) - mostly pro, with
His packaging proposal was brushed off as wrong.
http://lists.freedesktop.org/archives/systemd-devel/2015-...
There is a darker side behind the facade.
http://ewontfix.com/14/
An0nym0usC0ward
The plot thickens:
http://lists.freedesktop.org/archives/systemd-devel/2015-...
The plot thickens more:
http://lists.freedesktop.org/archives/systemd-devel/2015-...
Ouch !
The plot thickens even more:
Reason got an upper hand over vanity and a proposal of a prospect of
I hope the above topic and the following one will be discussed during their
Btw, this is Pieter Bruegel's take on it:
jb
Posted Sep 24, 2015 13:33 UTC (Thu)
by corbet (editor, #1)
[Link] (4 responses)
Posted Sep 24, 2015 22:42 UTC (Thu)
by alvherre (subscriber, #18730)
[Link] (1 responses)
Posted Sep 25, 2015 4:08 UTC (Fri)
by bronson (subscriber, #4806)
[Link]
Posted Sep 25, 2015 1:12 UTC (Fri)
by mgb (guest, #3226)
[Link] (1 responses)
But you clearly disagree with his opinion while I share it.
Posted Sep 25, 2015 2:11 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
I don't really see anything interesting in the original post other than a "see how much of am asshat I can be" link to a proposal for systemd.conf akin to asking to present a "90% of the world doesn't want to run Debian, nevermind know what it even is" poll done (based on results at a university computer lab) at a Debian conference asking them to give up and go back home.
The rest, I'm going to assume is cherry picking quotes because he has earned that reputation at least (and having read the source of one, yeah, there's no need to reconsider it right now).
[1]And the majority of the time it's "oh, that's much nicer", the rest being "hmm, that's different, but OK". But I'm going to assume you'll just deny their existence.
Posted Sep 27, 2015 21:50 UTC (Sun)
by sbergman27 (guest, #10767)
[Link] (2 responses)
Posted Sep 28, 2015 17:30 UTC (Mon)
by flussence (guest, #85566)
[Link]
Posted Sep 28, 2015 18:44 UTC (Mon)
by bronson (subscriber, #4806)
[Link]
Still waiting for the other shoe to drop.. but it's been excellent so far.
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
/path/to/dbus-daemon --fork
exec /usr/lib/systemd/systemd
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
Though a failure here is unlikely to ruin anyone's day too badly, since they were already shutting the box down, they just get a mystifying kernel stack trace on shutdown in the rare case where exec fails.
2. A suitably privileged user invokes `systemctl daemon-reexec`, which instructs systemd that it should serialise its state and exec itself again.
This is so that after a software update, systemd can use the new versions of dependent libraries, rather than the old ones that may have been removed, but systemd would still be holding open.
3. Privileged users may also request a `systemctl switch-root`, which is primarily intended for the initramfs transition, but could be used to move your rootfs to different storage (so long as you don't mind that most of your processes are killed).
In this case there's few processes hanging around to be able to break the executable mid-exec, but systemd supports the notion of "storage daemons", which are processes explicitly out of systemd's control, and are expected to have been exec'd from the initramfs.
If you are using a storage daemon to run a fuse-based rootfs then it could easily corrupt the executable mid-exec.
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
Experience with the X Window protocol is instructive here as it sits in a very similar place in the software stack and there was a desire for dbus to be able to scale to the point of handling graphics data, which has already been demonstrated with X that a userspace daemon cannot do this without kernel support.
X was doing just that without kernel support for nearly two decades. The MIT-SHM extension is worth noting.
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
* Assigning message buffers memory cost to corresponding client, so that admin can identify who's the culprit
* Better allocator that guarantees that after processing the messages, the emptied buffer can actually be freed for other purposes (i.e. allocation blocks don't mix data with unrelated life-times, e.g. send and receive messages or messages from/to different clients)
* If message is status broadcast, maybe having some mechanism where only last status update is buffered
* Suspending message sending if receiver isn't processing the messages
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
They did a good job
They did a good job
They did a good job
They did a good job
They did a good job
They did a good job
They did a good job
Oh, I found it, section 5.6.1 of this document: https://www.debian.org/releases/stable/i386/release-notes... which I apparently missed at the time.
They did a good job
They did a good job
They did a good job
They did a good job
(And not only that, you also have to read the changelog of every major library you use out of the distribution's repo, or have very good testing in place - that is the real effort.)
But during a major upgrade I expect things like that. And for me, this particular change is more than welcome. Aborting the boot on errors is the only sane thing to do. The init system cannot know and understand the filesystems and simply ignoring the errors can lead to anything, while erroring out always leads to the same thing: A very clear and very visible error that should be caught by even the most simple monitoring.
They did a good job
They did a good job
They did a good job
They did a good job
They did a good job
They did a good job
They did a good job
They did a good job
They did a good job
They did a good job
They did a good job
They did a good job
They did a good job
"Don't use Debian's packages for deploying node.js-based services."
They did a good job
They did a good job
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
Network code doesn't support it and network devices have always been a 'special case' in Linux. Notice how there are no '/dev/ethX' files.
How Debian managed the systemd transition
How Debian managed the systemd transition
As usual - legacy. The interface name is limited by IFNAMSIZ value which is used in multiple contexts, so you can not use long strings like '/dev/ethN' for interface names. And also there are no provisions for multiple interface names in getifaddrs() calls or similar functions.
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
> Network code doesn't support it and network devices have always been a 'special case' in Linux.
> Notice how there are no '/dev/ethX' files.
Let me to rephrase my sentence: my suggestion could be cause of some problem, or today it is impossible because nobody had coded that solution.
The former may/is a stop, the latter could be solved by some hours of coding (and several days of testing :-) )
How Debian managed the systemd transition
How Debian managed the systemd transition
What you are saying is correct.... But I repeat in my (very limited) experience I never seen that.
What I see is that the ethernet name change from eth0 to eth1 when I moved from a disk image from one host to another, and that cause me more headache then the fact that I have more ethernet device of different hardware...
How Debian managed the systemd transition
How Debian managed the systemd transition
Wol
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
the exception of its packaging.
http://lists.freedesktop.org/archives/systemd-devel/2015-...
"It's 119 executables now, btw."
"It's a set of basic building blocks distributions can build an OS from."
"We provide people with sources, with a git tree, and it's up to them how they
decide to package that."
"(...) we keep all components of our system together in one repo, under
a single release schedule and without stable, internal APIs."
"(...) We need to keep things maintainable. And you don't make things
maintainable (...) by forcing us to stabilize internal APIs (...)".
"(...) the only folks who should care about our updates are those who
are technically versed enough to not need version numbers, but who can
read our NEWS files."
"Well, it's supposed to be a steady stream of smaller additions instead
of major feature additions in long intervals."
"We can drop things from our git tree from time to time, (...)".
"... an aggressive, dictatorial marketing strategy including elements such as:
Engulfing other "essential" system components like udev and making them difficult or impossible to use without systemd (but see eudev).
Setting up for API lock-in (having the DBus interfaces provided by systemd become a necessary API that user-level programs depend on).
Dictating policy rather than being scoped such that the user, administrator, or systems integrator (distribution) has to provide glue. This eliminates bikesheds and thereby fast-tracks adoption at the expense of flexibility and diversity.
"
"True, systemd consists of 69 [edit: 119] binaries. But they are so tightly coupled that to my knowledge nobody so far was able to provide a fully compatible alternative implementation for any of them. Besides, since the APIs internal to those systemd binaries are not only undocumented but also constantly changing, providing a compatible alternative implementation means aiming for a moving target.
Even if LP holds the 69 [edit: 119] binaries as proof that systemd isn't monolithic, to me that's BS. The strong coupling is what makes for a monolith."
"systemd is a core port of Linux ecosystems these days, just like
the kernel. It's a foundation layer that finally brings some much
needed order, coherency, and vertical integration to the mess that
is Linux userspace."
"To further resonate that. Just like with kernel, every vendor make
their own longterm maintenance thing of systemd.
Look at Centos vs Debian kernel, they are widely different, even if
released from same series or at the same time.
Ditto systemd, integration done in Debian, Ubuntu, openSUSE, Fedora
are all different as well."
systemD(efeat) becoming a "Linux-based Init and Service Management System
Standard":
"Yeah, but no. I doubt writing standards like that makes any sense at all...
Sorry,
...
Lennart Poettering, Red Hat"
upcoming systemD(efeat) conference:
http://lists.freedesktop.org/archives/systemd-devel/2015-...
https://en.wikipedia.org/wiki/Satire#/media/File:Pieter_B...
So I was really hoping we would get through this one without somebody trying to restart the whole systemd flamewar. No such luck. The last time you did this, just over a month ago, you were warned that your troll bit would be set the next time. This is the next time.
Sigh
Sigh
Sigh
Sigh
Sigh
How Debian managed the systemd transition
How Debian managed the systemd transition
How Debian managed the systemd transition
