Tag Archives: systemd

Debian init Decision

The Debian ctte init discussion, which has been the drama that keeps on giving, appears to have finally had a decisive vote for systemd [EDIT: I was over-ambitious about decisive. The drama continues.] as the jessie init. Some notes:

  1. I found out that the FLOS neologism that is my fault is being used in the discussion. I’m not sure that I’m entirely happy about that, but I do think that we should be self-aware about building something very different from the Unix tradition.
  2. Even with my well-documented distaste for some of the philosophy (and rider components) in systemd, my experience and taste is that Upstart is the worst possible choice, and nothing else seems to have a chance. Letting the Canonical folks continue to act like Upstart isn’t universally technologically and philosophically unsatisfying to is wasting everyone’s time.
  3. The FDO agenda has largely succeeded, a bunch of the upper layers of the ecosystem are developing dependencies on systemd-coupled interfaces. This is largely because the previous interfaces being used for much of that functionality were the same developers’ now-abandoned earlier projects, which turned out to be disasters. This would be fine if there were even signs of competing implementations of those interfaces, or if the design of those interfaces weren’t such that it would be almost meaningless to attempt one, because the parts were designed as part of an integrated stack. I don’t see, for example, a clean standalone logind implementation (since it assumes things that only sysmted does further down the stack) or a nice healthy syslog-ng/rsyslog arrangement for journald. The FDO folks made an end-run around any kind of discussion of the merits of their plans by implementing quickly, getting a few of them widely adopted (initially by sheer political blustering), then coupling the rest of their design to the parts others were on board with. I’m pretty sure they consider that some kind of virtue.
  4. Related to (3) the integrated service manager over rcconf system discussion seems to have been decided on Linux up and down the ecosystem. I may not like the decision, but we should probably make the best of it and start working on/around the most annoying things about systemd. They seem willing to accommodate at least on cosmetic things like ISO dates.
  5. With that in mind, my preference would have been “We will adopt systemd iff a series of ecosystem assurances/development projects happen,” but that is unrealistic and (AFIK) forbidden by the Debian process. Especially a move from putting dist configs in half a dozen cryptic paths in /usr (which offend me in a variety of ways) to, giving credit to the merits of the “/usr belongs to the package manager” retcon, /usr/etc the way some of the BSDs use /etc/defaults.
    While we’re dreaming, forcing an interface/adapter to use a syslog in place of journald, or at least an alternative journald implementation with a simpler back-end (graceful feature degradation acceptable) would be great. I’m not even necessarily advocating using it, just that I don’t tend to take software without competing implementations as credible. Perhaps pressure from the volume of the Debian community will make some of this happen.

  6. I will agree with their vote in the “Fuck it, go with systemd, get the uniformity and feature advantages, try to mitigate the misfeatures, and leave as much room for coming back to the decision later if someone succeeds in writing and agitating for something more satisfying” sense.

Even with all that said, I’m a little surprised OpenRC wasn’t taken more seriously, since it is the conservative incremental progress choice – objectively, it is currently more featured than Upstart by most metrics – but the developers haven’t been politicking the way the Upstart and systemd folks have, and their incidentally combined efforts managed to discredit it. It has better portability (already runs on Hurd and FreeBSD) than the other options, and is one of two with a (admittedly, less featured) cgroups mechanism. The latter one is interesting because via some impressive politicking the cgroups discussion was at some point re-framed from “makes use of cgroups” to “uses cgroups in exactly the same way as systemd.”

I’m curious how the procd/ubus/hotplug2 stack coming out of OpenWRT is going to interact with the rest of the ecosystem, I suspect we’re going to see that stack meet midway with systed/dbus/udev and some of the light distros using it and shims even for PC-like applications, which will likely be the next time things get really interesting, barring a couple skirmishes where user-level software dictates the stack to the metal.

Posted in Computers, General | Tagged , , | Leave a comment

I got into another discussion about Linux init systems. Since I still get a lot of hits about that, I figure I should put a link, as the long two-part post is a reasonably clean and complete explanation of my … Continue reading

Posted on by pappp | Leave a comment

I want my UNIX groups back

The breakage of permissions under recent PolKit/logind is flabbergasting. They have completely subverted UNIX groups/permissions in a difficult-to-unbreak way. And I get cheerful little update messages saying things like “You no longer need to be in the camera group to use cameras” like it’s a fucking feature (and they’re lying; they mean users logged in locally no longer need to be in the camera group – remote users still need it). If I want a user to have access to some hardware on a machine, I’ll give it permissions. If I don’t, I probably don’t for a reason. Let’s talk use cases: perhaps you would like to hide the camera from a kid’s user. Or you would like to check on something with the camera attached to your remote machine. Or work a music player via SSH. Or generally use the resources on the machine you bothered to log into remotely because why the fuck else would you have logged in there? Every one of those is now more complicated to accomplish. Adding a facility to enable/disable permissions for remote or local users might be reasonable, but just fucking breaking groups for a couple use cases no one uses is moronic. (Seriously, Fast User Switching keeps coming up as a rationale for breaking things. Has anyone, ever used fast user switching on one of the platforms that supports it? There are usually more computer-like-devices than people in a household now, it isn’t relevant.)

Can someone please come up with a straightforward way to just noop all the PolKit bullshit so I can have my UNIX box back from the FreeDesktop assholes?

Posted in Computers, General | Tagged , , , | 10 Comments

I just wanted to make a pointer to this /r/archlinux thread about dropping ConsoleKit support for a systemd-specific replacement, because I think the discussion (that I waded in to) is revealing about how the current “Linux is increasingly un-UNIX-like, and … Continue reading

Posted on by pappp | 1 Comment