8 ms·

Systemd is not portable and what this means for our ports

117 points by tshepang 13y ago

_delirium 13y ago
Especially considering that Debian/kFreeBSD and Debian/HURD are closer to interesting experiments than systems used for real work, holding back the init system solely for the non-Linux Debian variants doesn't seem justified. So this roadmap seems pretty sane.
- deleted 13y ago
  [deleted]
  - redbad 13y ago
    _delirium is saying Debian on {kFreeBSD,HURD} are near-experimental, not that Debian itself is.
  - deleted 13y ago
    [deleted]
- asveikau 13y ago
  But what exactly is "holding back"? I feel like Linux distros today come with too many crappy, overthought, over-engineered daemons that don't really offer much over the previously available interfaces. I guess parallelizing init scripts or making dependencies more explicit is a good thing in some sense, but I have to say, it's a breath of fresh air to see something like a *BSD system, which has an /etc/rc shell script that is easy to follow. Unlike Linux which frequently seeks out complex solutions from simple problem spaces.
  - Jasper_ 13y ago
    Process and service management is not a simple problem space, especially with POSIX semantics. Try doing something like "stop apache". It turns out that trying to simply kill the Apache processes isn't going to work right, as Apache forks out lots of worker processes that won't be guaranteed to be killed when the Apache process stops. And now since the parent has gone away, they're reparented to PID1, so there's all these worker processes littering your system. systemd uses cgroups to tag every single forked out process with a service file, so that all of the processes associated with a service can be stopped at once.
    - regularfry 13y ago
      Right, but is systemd necessary for that, or can you use a cgroup from within a conventional sysvinit script?
      - bkor 13y ago
        systemd also logs stderr + stdout, so if some daemon fails to start up, you can easily see it in 'service $SERVICE status'. A lot of things could theoretically be done by putting that all in a sysvinit script. That means duplicating that in every sysvinit script. Bugs galore :P
        thwarted 13y ago
        initscripts have used libraries of routines since like forever. Good programming methodology applies equally to shell programming and initscripts as it does to programming anything else.
        bkor 13y ago
        Initscripts are specific to one distribution. A bug in an initscript in one distribution is not fixed in another distribution. This is practical real life example that has happened for 10+ years. With systemd, there is just a configuration file that is used. The logic is within the daemon and bugs are fixed in one place, then shared across distributions (+ embedded world and others). Maybe you could redo what systemd does by changing those libraries. I very much doubt it though, I also do not see the point of reimplementing this. Systemd way guarantees consistensy, you're proposing something which may or may not work, depending on the init script. Does not seem like a good practice, nor a good alternative to propose. But all means, go for it.
        thwarted 13y ago
        Many initscripts are provided by the software and distributions replace them with their own. The distributions themselves are at fault for not using an upstream initscript. There is also nothing stopping a distribution from replacing the software provided systemd config file, which themselves can contain snippets of executable shell code and thus not reap the benefits of upstream fixed bugs.
  - qwerta 13y ago
    This 'simplicity' changes quickly into hairball of scripts if anything non-trivial is requested.
    - asveikau 13y ago
      So you'd like to trade one hairball (shell script) for another (systemd).
      - _delirium 13y ago
        To me the new hairball does seem much cleaner and better thought out. Sysvinit scripts are copy/paste programming at its worst, every one doing a half-assed, buggy reimplementation of an init system copy/pasted from another package and then tweaked until it sort of worked.
      - jfb 13y ago
        There's value in declaring hairball bankruptcy, though. The world changes. Complexity can grow non-linearly, and assumptions valid in one context can rapidly change.
- unethical_ban 13y ago
  They'll stay experiments if barriers are intentionally put up to prevent package compatibility. Debian/kFreeBSD is an awesome idea, especially since FreeBSD's package system sucks and ZFS is unparalleled. However, I don't think that's the only reason to avoid Systemd.
  - bkor 13y ago
    systemd is not something that is intentionally put up to prevent Hurd or FreeBSD from being popular. When I asked about the Hurd of FreeBSD versions of Debian, it seems that stuff has to compile against it. Every Debian maintainer has to already spend a lot of time on it, while the usage is pretty low. Furthermore, it seems rarely useful. At most in the 'it compiles, but does not run, ship it anyway!' stage. If people want Hurd or FreeBSD, then why not have them put in a bit more effort? Not like sysvinit will be completely broken.
sherr 13y ago
I sympathise with the fact that Debian considers itself the "universal operating system" but there are limits and the Debian developers have to consider the impact of their support decisions on their major consumer: the Linux OS. The Linux OS is the first and primary OS they should support. And as Michael says, to stay relevant, Debian needs to meet the needs of a modern and dynamic OS. That's why I want to see systemd supported and considered first-class in Debian, my OS of choice.
- ealexhudson 13y ago
  Exactly the same here. I like the idea that startup semantics will be much more unified across a range of distributions and that more sysadmin knowledge will be common - particularly in terms of writing good 'init scripts' for custom services.
- mattengi 13y ago
  +1
jmillikin 13y ago
> This blog post is the third of a series of posts > dealing with the results of the Debian systemd survey Previous posts in the series http://people.debian.org/~stapelberg//2013/06/09/systemd-bloat.html http://people.debian.org/~stapelberg//2013/06/09/systemd-blo... http://people.debian.org/~stapelberg//2013/07/01/systemd-transition.html http://people.debian.org/~stapelberg//2013/07/01/systemd-tra...
mcclung 13y ago
It's getting harder and harder to find a distro where systemd isn't a hard requirement. I am hoping Debian will keep the choice of sysvinit available.
- crististm 13y ago
  All of a sudden everybody and his dog requires systemd or upstart or whatever flavor of rebranded and upgraded and extended and whatnot initd of the day. I failed to see a reason behind this movement except of the "you're an old fart and this is how we're doing it today" explanation. And when BSD comes up and say this is not portable, everybody say we're on Linux and we don't care and you should jump the shark as we do. What?!
  - sanderjd 13y ago
    I think the newer alternatives are more standard, easier to understand, easier to write for my own services, and less error prone than sysvinit scripts. You may disagree with all of those points, but it really isn't a "you're an old fart and this is how we're doing it today" explanation. By all means, argue against the specific reasoning, but claiming there is none and it is just progress for its own sake is spurious.
    - crististm 13y ago
      > argue against the specific reasoning What's with the /usr that should be mounted at start? What was wrong with /? And why should initd depend on the kernel?
      - VLM 13y ago
        I may be misreading you, but I think you're trying to ask why the survey was making technical decision justifications based on purely subjective opinions rather than a survey based on objective facts, balancing the cost to humanity of the few remaining /usr splitters having to reconfigure, vs the slightly increased effort of the very small number of people who write initscripts having to continue to use the old system plus or minus the increased effort by the existing stock of programmers having to learn systemd which the other distros having switched has been forced on everyone anyway. I think both sides of the balance have pretty small numbers. A la the famous Landley rant from about 4 years ago, I had a NFS mounted /usr... back in 97 as an experiment which I rapidly terminated. Shared and RO /usr is an interesting hack, but probably not worth holding init development back, especially since so many other boot time things demand /usr anyway now (like the pulseaudio, like the networkmanager thing) If you were aiming more at why systemd needs different stuff, you can google for Landley's email around 2010 on the topic and on the other side google for read only /usr and NFS /usr. Also google for cgroups, especially systemd and cgroups.
bbanyc 13y ago
Previously the non-portability of upstart was seen as a reason for Debian not to switch to upstart. Now the non-portability of systemd is seen as a reason for Debian to drop the ports.
- rquirk 13y ago
  Debian isn't going to drop the ports! The blog post seems a sane roadmap for eventually switching to systemd on Linux and maintain a more traditional init process on the BSD ports. The fact that scripts and systemd can work in tandem on Linux makes this possible. Seems pretty reasonable to me. The only downer is that now there'd be 2 init setups/configs to maintain. But that would be the case even if systemd were not the default, just available as a choice.
- ldng 13y ago
  I did not read that they were going to drop the port.
simonz05 13y ago
I recently switched from Arch Linux to Debian mainly due to the hard systemd requirement. I hope the Debian transition will be better than what Arch Linux did.
- mateuszf 13y ago
  Haven't heard about lot of users complaining about the way Arch developers did it. In fact I think it works flawlessly.
  - alecthomas 13y ago
    It hosed my machine. The problem was I hadn't upgraded in a while, so when I did upgrade some of the hacks they had in place to upgrade seamlessly no longer worked due to library incompatibilities. Even the Arch IRC channel couldn't help :(
    - mateuszf 13y ago
      I understand. Well, at least they did it early. It shouldn't happen once again.
drill_sarge 13y ago
I could not care less about systemd because sysvinit is working fine here. I hate that you are forced in most distros to choose systemd without any alternative. I want my own initscripts, if a distro doesn't allow me that I won't use that distro.
- cnvogel 13y ago
  Using systemd still allows you to have custom scripts run on boot up. Given a shell script you want to have running on boot you'd have linked that script to /etc/rc3.d on sysvinit. With systemd the proper way to activate it is a service file in /etc/systemd/… or /lib/systemd/… . It's different but I wouldn't call it more or less complicated than sysvinit. There are a lot of example/skeleton files floating around, especially archlinux's collection is useful. Of course, systemd allows for much more configuration than simple running of scripts on boot, but you can fine tune later.
- oblio 13y ago
  I think they're written dozens of times that systemd can run sysvinit scripts. In your experience is that feature not good enough?
- Jasper_ 13y ago
  As the article mentions, systemd has a full sysv init script compatibility mode, with some (trivial) incompatibilities: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ http://www.freedesktop.org/wiki/Software/systemd/Incompatibi...
- 0x006A 13y ago
  i could not care less about sysvinit because systemd is working fine here.
peterwwillis 13y ago
If there ever was a "red herring" in a discussion of Linux distributions, it's the init system. The distro maintainers package the software for their system. It's therefore also their responsibility to make sure a service can be started/stopped and have its status checked. It does not matter what kind of init system a distro has. A single Linux distribution is an Operating System independent of all others. There is no one true portable Linux way, much less for non-Linux-based Operating Systems. You have to treat them all as separate because to do otherwise would not only add complexity to a monolithic "portability" system, it would eventually get so complex you'd have to split it up anyway. Portable software makes 3rd-party software developers' lives easier. But the init system is not managed by 3rd-party developers. It is managed by the OS maintainers. So it does not matter what method they use. Furthermore, it's fucking Debian, the second-oldest distribution still in release. The oldest (Slackware) holds onto the old ways for as long as technically possible, and they're still going strong. So why the hell they care about being "modern" and "remaining relevant" is anyone's guess. (disclaimer: I wrote my own init system for my own Linux distribution, and have modified most others)
- makomk 13y ago
  All that's true of init systems that follow the traditional Unix approach, where each part of the system has one task to do and does it well. The point of systemd is to break from that approach. So systemd isn't just an init system, it also creates device nodes, handles system-wide logging, manages both desktop and console login sessions, replaces inetd (but with support for Unix sockets and DBus), provides resource management functionality for virtualised containers, and a bunch of other stuff I've forgotten. Making full use of these features requires changes to a large number of other applications.
  - bkor 13y ago
    systemd contains a lot of different bits, each with a different task. Much like e.g. coreutils. Coreutils contains a lot of different utilities. If systemd is somehow bad for Linux, coreutils is as well.
  - peterwwillis 13y ago
cmccabe 13y ago
This is great. It will give Debian access to features like a faster startup, a sane way of restarting daemons that die, better power management and process management.
- sciurus 13y ago
  What is great? Debian hasn't decided to switch to systemd.
  - shmerl 13y ago
    But systemd already works in Debian. Though it's optional: http://wiki.debian.org/systemd http://wiki.debian.org/systemd
    - asb 13y ago
      But the latest systemd even in sid is version 44, which is ancient.
  - cmccabe 13y ago
    This seems pretty clear: How will this work? In the short-term future, maintainers add systemd support to their packages. This does not imply dropping sysvinit support. As outlined in my post about the transition, systemd service files can coexist with sysvinit scripts. In the mid-term future, both sysvinit and systemd are supported — this is the only way we can do a gradual transition, and Debian clearly does not want a flag day. In the long term, we could switch the default from sysvinit to systemd on Debian GNU/Linux, in case we agree that’s a reasonable decision at that time. Non-Linux ports will still use sysvinit. We can argue over the exact meaning of "switch to" (seems pretty pointless to me), but it seems fairly clear that in the near future nearly all debian users will be using systemd.
    - sciurus 13y ago
      Reread this part of your quote- "in the long term, we could switch... in case we agree that's a reasonable decision at that time" This is a blog post by a Debian developer that would like the project to switch the default init system. It includes some discussion of how Debian could make the transition. It's nothing the project has committed to, so saying "that in the near future nearly all debian users will be using systemd" is unwarranted.
VLM 13y ago
Is a cgroups emulator in the future for kFreeBSD and the HURD? I'm curious if faking cgroups (or heck, porting it) would be an easy solution. Not talking about a fake cgroups providing all the real world advantages of systemd; merely a a fake not being too much worse than existing sysvinit. Maybe rephrased actually porting THE cgroups to HURD might be impossible due to design issues or license issues. OK well how about writing a stub cgroups using the API that always gives a pleasant and completely meaningless response to all calls. What, if anything, would be the overall system wide net negative effect of systemd on HURD with a fake cgroups? I have not had much success googling for that. This would not fix the "my /usr is not on my / partition" problem which is a serious concern to a extremely small number of people.
- Jasper_ 13y ago
  I don't know why you think cgroups has anything to do with the /usr split. systemd uses cgroups to tag processes with metadata about services, and to provide resource limits. If you added a stub cgroups, then resource limits wouldn't apply, and you might run into issues with services not fully shutting down as you do right now with the POSIX service management. It's entirely possible, but you wouldn't get any of the upsides of systemd.
  - VLM 13y ago
    I don't have that belief. My interpretation of the opposition against systemd revolves primarily around: 1) /usr split 2) Can't run on kfreebsd and hurd because they don't speak cgroups so either "we" can't run systemd or need to drop ports or need to support two init forever. You can eliminate #1 with some sysadmin work. A stub cgroups compatible API emulator type thing for kfreebsd and hurd would eliminate complaint #2 if the overall result were not much worse than existing sysvinit. One interesting solution is there is no particular reason to flick the power switch on kfreebsd over and over as quickly as possible. So one incredibly non-optimized way to "fake" cgroups process monitoring on kfreebsd would be to replace actual cgroup process monitoring with something ridiculous like "sleep 30". In 30 seconds, anything will have started or stopped, correct? Obviously a dev roadmap would be to replace/emulate/port real cgroup-like support, once people get tired of all cgroups api calls being replaced with "sleep 30". I can't be the first one to come up with this "great" idea.
Qantourisc 13y ago
Wasn't looking forward to this "upgrade" ... The fact that it's from the same dude as PulseAudio is enough to make me anxious, the pulseaudio stuff didn't go smooth. (I'm still of ALSA, yes also is a mess to.) So I hope I won't be forced, to a more crappy system ! The fact that it will be handling a lot of stuff more, sounds like a major pita ...
- pyre 13y ago
  | the pulseaudio stuff didn't go smooth That wasn't the fault of the developer so much as it was the fault of the distributions for jumping on the bandwagon (making it the default audio system) too early.
  - nieve 13y ago
    Poettering oversold its state of stability and then seems to have largely lost interest during the most critical period of adoption. The distributions are responsible for believing the hype and shipping too early, but that doesn't change the fact that the developers were hyping it well beyond what was justified. PulseAudio has a lot of nice features, but it's still less stable and has more bizarre failure modes for me _9 years_ after its initial release than plain old ALSA. I literally know no other linux users who have ever had anything good to say about PulseAudio. Entirely anecdotal, but when it comes to trusting developers to do a good job in the first place, much less help with a major transition I'm not inclined to discount that.
    - pyre 13y ago
      After the initial transition period, I have not had any PulseAudio issues other than on maybe 2 occasions where the pulseaudio daemon ran amok, consuming 99% CPU for some reason, until it was killed. I'll admit that I'm not running any exotic configurations though, but built-in audio works just fine, and plugging my USB camera/microphone[1] has worked without issue for a long time too. At one point I was also able to stream audio from my HTPC to my laptop, so that I could use my headphones when everyone else was sleeping. Though I'll admit configuration was a pain in the ass, I don't recall being able to do that with ALSA (though I recall someone creating a shell script a while back that read from /dev/dsp and piped to a socket). Prior to PulseAudio, sound on Linux was always an uphill battle for me (don't get me started on regressions in the PowerBook audio driver that no one cared about since "it works on the newer PowerMacs"). It was a crap-shoot which audio system an application would use. OSS? Alsa? eSound? KDE's sound daemon? Do they all use the same mixer app? What happens when I write to /dev/dsp? Does all other audio block? Which applications support Jackd? etc... [1] Referring to the mic in the pulseaudio context. EDIT: > I literally know no other linux users who > have ever had anything good to say about > PulseAudio. I'll mention that the same could be said of OSS or ALSA too. They may have worked better for you, but I doubt that prior to PulseAudio, you were singing their praises from the rooftops.
synchronise 13y ago
I wonder why Debian didn't go with OpenRC (https://en.wikipedia.org/wiki/OpenRC https://en.wikipedia.org/wiki/OpenRC) as it is compatible with both Linux and *BSD, which also offers 'Process segregation through cgroups'.
- kaeso 13y ago
  The OpenRC port effort is currently ongoing and been sponsored by this year GSoC: http://wiki.debian.org/SummerOfCode2013/StudentApplications/LeiWang http://wiki.debian.org/SummerOfCode2013/StudentApplications/...
- bkor 13y ago
  Change happens by people doing work. There are at least 3 people actively working on systemd support. Meaning: they help out other packagers, file bugs, look at bugreports, coordinate with upstream, etc. For OpenRC, there is just one person advocating it. There is a summer of code thing, but seems not much work is done. Furthermore, OpenRC seems nice, but parallel starting of services is actually experimental/buggy (just ask one of the OpenRC maintainers!). So although you can have a similar boottime, one init system (systemd) will be running in a supported configuration, the other (OpenRC) in something that is known to have issues. That all said, I don't think Debian really makes decisions. What is being proposed is maintaining two. Aside from above, there is also the practical bit in that systemd provides something to replace the unmaintained and deprecated ConsoleKit with. This bit can be used on another init system (Canonical is using or will use it on Upstart), but at one point seems easier to rely on the existing systemd supporters in Debian to get things working correctly.
  - synchronise 13y ago
    Surely the Debian Foundation can see that an init project that can support more than one kernel/OS, pretty much as Debian does with Hurd and kFreeBSD, would be a better platform to support through the long term.
bch 13y ago
"Maintaining portable code increases complexity Since systemd is written in C, the canonical way to write portable code is by using conditional compilation, for example with ifdef statements. That makes the code harder to understand and reason about, but more importantly it blows up the test matrix." Take a page from NetBSDs effort... http://www.netbsd.org/about/portability.html http://www.netbsd.org/about/portability.html
dschiptsov 13y ago
systemd is, in some sense, a very modern-day product - a mess of different "alien" concepts and functionality stuck together into one project with an intention to show other the only true way of doing things. It like some (freedesktop guys, perhaps) will come to Plan9 and would say that all they need is gconf* -like registry to have a uniform configuration, or something of the same level of absurdity. The movement out of shell-based initscripts for non-specialized (non-mobile/embedded) distributions is a cancer.) Remaining BSD guys are much more sane and "conservative" in this respect. There is absolutely no necessity to break what is good-enough and well-balanced - having a standard shell scripts to do the job they were designed to. FreeBSD's rc.d system is a very good example.
- Jasper_ 13y ago
  systemd has one purpose: to be about system and service management. It will replace everything that deals with services: starting them (whether based on traditional init, scheduling, socket activation, or from a desktop user session), logging the stdout/stderr in a consistent and well-defined location, and about giving you flexible tools to manage, debug, and inspect system services. Besides that, yes, it does have a few things (hostnamed, timedated), which are mostly about some POSIX infrastructure that wasn't there already: notification when the system hostname or timedate changes (yes, it happens quite often on desktop systems, due to NTP, user setting, and VPN). They're just utilities they needed along the way, and systemd can be built without them. If the system or service fails to start, instead of hunting around in /var/log/, syslog, dmesg, etc. for anything that looks relevant, you simply use the journal which aggregates most everything. It's already a very good breakthrough. I've debugged countless bad Debian service scripts (which usually comes down to bash's terrible whitespace and quote management), and inserted echo statements into my Arch Linux to debug why it wouldn't boot when I upgraded, hacking out clear statements here and there designed to make the boot pretty. Shell scripts aren't a good solution for robust system and service management.
  - dschiptsov 13y ago
    We have no services in UNIX-like systems, we have daemons and it is perfectly OK to use a templated shell script to start/stop restart it, modified according to the nature of a daemon, as needed. That other operating system from which the concept of a "service" came from (along with lots of other crap) have different philosophy and founded on different design decisions, so blindly trying to bring stuff from it here is not always reasonable. And, of course, shell scripts are OK when well-written - there are other UNIX-like systems beside Linux.)
16s 13y ago
When higher-level software begins requiring systemd (Gnome, KDE, etc.), the BSDs and other non-Linux, but Unix-like operating systems will no longer be able to use that software.

117 points by tshepang 13y ago

Especially considering that Debian/kFreeBSD and Debian/HURD are closer to interesting experiments than systems used for real work, holding back the init system solely for the non-Linux Debian variants doesn't seem justified. So this roadmap seems pretty sane.

deleted 13y ago
[deleted]
- redbad 13y ago
  _delirium is saying Debian on {kFreeBSD,HURD} are near-experimental, not that Debian itself is.
- deleted 13y ago
  [deleted]
asveikau 13y ago
But what exactly is "holding back"? I feel like Linux distros today come with too many crappy, overthought, over-engineered daemons that don't really offer much over the previously available interfaces. I guess parallelizing init scripts or making dependencies more explicit is a good thing in some sense, but I have to say, it's a breath of fresh air to see something like a *BSD system, which has an /etc/rc shell script that is easy to follow. Unlike Linux which frequently seeks out complex solutions from simple problem spaces.
- Jasper_ 13y ago
  Process and service management is not a simple problem space, especially with POSIX semantics. Try doing something like "stop apache". It turns out that trying to simply kill the Apache processes isn't going to work right, as Apache forks out lots of worker processes that won't be guaranteed to be killed when the Apache process stops. And now since the parent has gone away, they're reparented to PID1, so there's all these worker processes littering your system. systemd uses cgroups to tag every single forked out process with a service file, so that all of the processes associated with a service can be stopped at once.
  - regularfry 13y ago
    Right, but is systemd necessary for that, or can you use a cgroup from within a conventional sysvinit script?
    - bkor 13y ago
      systemd also logs stderr + stdout, so if some daemon fails to start up, you can easily see it in 'service $SERVICE status'. A lot of things could theoretically be done by putting that all in a sysvinit script. That means duplicating that in every sysvinit script. Bugs galore :P
      - thwarted 13y ago
        initscripts have used libraries of routines since like forever. Good programming methodology applies equally to shell programming and initscripts as it does to programming anything else.
        bkor 13y ago
        Initscripts are specific to one distribution. A bug in an initscript in one distribution is not fixed in another distribution. This is practical real life example that has happened for 10+ years. With systemd, there is just a configuration file that is used. The logic is within the daemon and bugs are fixed in one place, then shared across distributions (+ embedded world and others). Maybe you could redo what systemd does by changing those libraries. I very much doubt it though, I also do not see the point of reimplementing this. Systemd way guarantees consistensy, you're proposing something which may or may not work, depending on the init script. Does not seem like a good practice, nor a good alternative to propose. But all means, go for it.
        thwarted 13y ago
        Many initscripts are provided by the software and distributions replace them with their own. The distributions themselves are at fault for not using an upstream initscript. There is also nothing stopping a distribution from replacing the software provided systemd config file, which themselves can contain snippets of executable shell code and thus not reap the benefits of upstream fixed bugs.
- qwerta 13y ago
  This 'simplicity' changes quickly into hairball of scripts if anything non-trivial is requested.
  - asveikau 13y ago
    So you'd like to trade one hairball (shell script) for another (systemd).
    - _delirium 13y ago
      To me the new hairball does seem much cleaner and better thought out. Sysvinit scripts are copy/paste programming at its worst, every one doing a half-assed, buggy reimplementation of an init system copy/pasted from another package and then tweaked until it sort of worked.
    - jfb 13y ago
      There's value in declaring hairball bankruptcy, though. The world changes. Complexity can grow non-linearly, and assumptions valid in one context can rapidly change.
unethical_ban 13y ago
They'll stay experiments if barriers are intentionally put up to prevent package compatibility. Debian/kFreeBSD is an awesome idea, especially since FreeBSD's package system sucks and ZFS is unparalleled. However, I don't think that's the only reason to avoid Systemd.
- bkor 13y ago
  systemd is not something that is intentionally put up to prevent Hurd or FreeBSD from being popular. When I asked about the Hurd of FreeBSD versions of Debian, it seems that stuff has to compile against it. Every Debian maintainer has to already spend a lot of time on it, while the usage is pretty low. Furthermore, it seems rarely useful. At most in the 'it compiles, but does not run, ship it anyway!' stage. If people want Hurd or FreeBSD, then why not have them put in a bit more effort? Not like sysvinit will be completely broken.

sherr 13y ago

I sympathise with the fact that Debian considers itself the "universal operating system" but there are limits and the Debian developers have to consider the impact of their support decisions on their major consumer: the Linux OS. The Linux OS is the first and primary OS they should support. And as Michael says, to stay relevant, Debian needs to meet the needs of a modern and dynamic OS. That's why I want to see systemd supported and considered first-class in Debian, my OS of choice.

ealexhudson 13y ago
Exactly the same here. I like the idea that startup semantics will be much more unified across a range of distributions and that more sysadmin knowledge will be common - particularly in terms of writing good 'init scripts' for custom services.
mattengi 13y ago
+1

jmillikin 13y ago

> This blog post is the third of a series of posts > dealing with the results of the Debian systemd survey Previous posts in the series http://people.debian.org/~stapelberg//2013/06/09/systemd-bloat.html http://people.debian.org/~stapelberg//2013/06/09/systemd-blo... http://people.debian.org/~stapelberg//2013/07/01/systemd-transition.html http://people.debian.org/~stapelberg//2013/07/01/systemd-tra...

mcclung 13y ago

It's getting harder and harder to find a distro where systemd isn't a hard requirement. I am hoping Debian will keep the choice of sysvinit available.

crististm 13y ago
All of a sudden everybody and his dog requires systemd or upstart or whatever flavor of rebranded and upgraded and extended and whatnot initd of the day. I failed to see a reason behind this movement except of the "you're an old fart and this is how we're doing it today" explanation. And when BSD comes up and say this is not portable, everybody say we're on Linux and we don't care and you should jump the shark as we do. What?!
- sanderjd 13y ago
  I think the newer alternatives are more standard, easier to understand, easier to write for my own services, and less error prone than sysvinit scripts. You may disagree with all of those points, but it really isn't a "you're an old fart and this is how we're doing it today" explanation. By all means, argue against the specific reasoning, but claiming there is none and it is just progress for its own sake is spurious.
  - crististm 13y ago
    > argue against the specific reasoning What's with the /usr that should be mounted at start? What was wrong with /? And why should initd depend on the kernel?
    - VLM 13y ago
      I may be misreading you, but I think you're trying to ask why the survey was making technical decision justifications based on purely subjective opinions rather than a survey based on objective facts, balancing the cost to humanity of the few remaining /usr splitters having to reconfigure, vs the slightly increased effort of the very small number of people who write initscripts having to continue to use the old system plus or minus the increased effort by the existing stock of programmers having to learn systemd which the other distros having switched has been forced on everyone anyway. I think both sides of the balance have pretty small numbers. A la the famous Landley rant from about 4 years ago, I had a NFS mounted /usr... back in 97 as an experiment which I rapidly terminated. Shared and RO /usr is an interesting hack, but probably not worth holding init development back, especially since so many other boot time things demand /usr anyway now (like the pulseaudio, like the networkmanager thing) If you were aiming more at why systemd needs different stuff, you can google for Landley's email around 2010 on the topic and on the other side google for read only /usr and NFS /usr. Also google for cgroups, especially systemd and cgroups.

bbanyc 13y ago

Previously the non-portability of upstart was seen as a reason for Debian not to switch to upstart. Now the non-portability of systemd is seen as a reason for Debian to drop the ports.

rquirk 13y ago
Debian isn't going to drop the ports! The blog post seems a sane roadmap for eventually switching to systemd on Linux and maintain a more traditional init process on the BSD ports. The fact that scripts and systemd can work in tandem on Linux makes this possible. Seems pretty reasonable to me. The only downer is that now there'd be 2 init setups/configs to maintain. But that would be the case even if systemd were not the default, just available as a choice.
ldng 13y ago
I did not read that they were going to drop the port.

simonz05 13y ago

I recently switched from Arch Linux to Debian mainly due to the hard systemd requirement. I hope the Debian transition will be better than what Arch Linux did.

mateuszf 13y ago
Haven't heard about lot of users complaining about the way Arch developers did it. In fact I think it works flawlessly.
- alecthomas 13y ago
  It hosed my machine. The problem was I hadn't upgraded in a while, so when I did upgrade some of the hacks they had in place to upgrade seamlessly no longer worked due to library incompatibilities. Even the Arch IRC channel couldn't help :(
  - mateuszf 13y ago
    I understand. Well, at least they did it early. It shouldn't happen once again.

drill_sarge 13y ago

I could not care less about systemd because sysvinit is working fine here. I hate that you are forced in most distros to choose systemd without any alternative. I want my own initscripts, if a distro doesn't allow me that I won't use that distro.

cnvogel 13y ago
Using systemd still allows you to have custom scripts run on boot up. Given a shell script you want to have running on boot you'd have linked that script to /etc/rc3.d on sysvinit. With systemd the proper way to activate it is a service file in /etc/systemd/… or /lib/systemd/… . It's different but I wouldn't call it more or less complicated than sysvinit. There are a lot of example/skeleton files floating around, especially archlinux's collection is useful. Of course, systemd allows for much more configuration than simple running of scripts on boot, but you can fine tune later.
oblio 13y ago
I think they're written dozens of times that systemd can run sysvinit scripts. In your experience is that feature not good enough?
Jasper_ 13y ago
As the article mentions, systemd has a full sysv init script compatibility mode, with some (trivial) incompatibilities: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/ http://www.freedesktop.org/wiki/Software/systemd/Incompatibi...
0x006A 13y ago
i could not care less about sysvinit because systemd is working fine here.

peterwwillis 13y ago

If there ever was a "red herring" in a discussion of Linux distributions, it's the init system. The distro maintainers package the software for their system. It's therefore also their responsibility to make sure a service can be started/stopped and have its status checked. It does not matter what kind of init system a distro has. A single Linux distribution is an Operating System independent of all others. There is no one true portable Linux way, much less for non-Linux-based Operating Systems. You have to treat them all as separate because to do otherwise would not only add complexity to a monolithic "portability" system, it would eventually get so complex you'd have to split it up anyway. Portable software makes 3rd-party software developers' lives easier. But the init system is not managed by 3rd-party developers. It is managed by the OS maintainers. So it does not matter what method they use. Furthermore, it's fucking Debian, the second-oldest distribution still in release. The oldest (Slackware) holds onto the old ways for as long as technically possible, and they're still going strong. So why the hell they care about being "modern" and "remaining relevant" is anyone's guess. (disclaimer: I wrote my own init system for my own Linux distribution, and have modified most others)

makomk 13y ago
All that's true of init systems that follow the traditional Unix approach, where each part of the system has one task to do and does it well. The point of systemd is to break from that approach. So systemd isn't just an init system, it also creates device nodes, handles system-wide logging, manages both desktop and console login sessions, replaces inetd (but with support for Unix sockets and DBus), provides resource management functionality for virtualised containers, and a bunch of other stuff I've forgotten. Making full use of these features requires changes to a large number of other applications.
- bkor 13y ago
  systemd contains a lot of different bits, each with a different task. Much like e.g. coreutils. Coreutils contains a lot of different utilities. If systemd is somehow bad for Linux, coreutils is as well.
- peterwwillis 13y ago

cmccabe 13y ago

This is great. It will give Debian access to features like a faster startup, a sane way of restarting daemons that die, better power management and process management.

sciurus 13y ago
What is great? Debian hasn't decided to switch to systemd.
- shmerl 13y ago
  But systemd already works in Debian. Though it's optional: http://wiki.debian.org/systemd http://wiki.debian.org/systemd
  - asb 13y ago
    But the latest systemd even in sid is version 44, which is ancient.
- cmccabe 13y ago
  This seems pretty clear: How will this work? In the short-term future, maintainers add systemd support to their packages. This does not imply dropping sysvinit support. As outlined in my post about the transition, systemd service files can coexist with sysvinit scripts. In the mid-term future, both sysvinit and systemd are supported — this is the only way we can do a gradual transition, and Debian clearly does not want a flag day. In the long term, we could switch the default from sysvinit to systemd on Debian GNU/Linux, in case we agree that’s a reasonable decision at that time. Non-Linux ports will still use sysvinit. We can argue over the exact meaning of "switch to" (seems pretty pointless to me), but it seems fairly clear that in the near future nearly all debian users will be using systemd.
  - sciurus 13y ago
    Reread this part of your quote- "in the long term, we could switch... in case we agree that's a reasonable decision at that time" This is a blog post by a Debian developer that would like the project to switch the default init system. It includes some discussion of how Debian could make the transition. It's nothing the project has committed to, so saying "that in the near future nearly all debian users will be using systemd" is unwarranted.

VLM 13y ago

Is a cgroups emulator in the future for kFreeBSD and the HURD? I'm curious if faking cgroups (or heck, porting it) would be an easy solution. Not talking about a fake cgroups providing all the real world advantages of systemd; merely a a fake not being too much worse than existing sysvinit. Maybe rephrased actually porting THE cgroups to HURD might be impossible due to design issues or license issues. OK well how about writing a stub cgroups using the API that always gives a pleasant and completely meaningless response to all calls. What, if anything, would be the overall system wide net negative effect of systemd on HURD with a fake cgroups? I have not had much success googling for that. This would not fix the "my /usr is not on my / partition" problem which is a serious concern to a extremely small number of people.

Jasper_ 13y ago
I don't know why you think cgroups has anything to do with the /usr split. systemd uses cgroups to tag processes with metadata about services, and to provide resource limits. If you added a stub cgroups, then resource limits wouldn't apply, and you might run into issues with services not fully shutting down as you do right now with the POSIX service management. It's entirely possible, but you wouldn't get any of the upsides of systemd.
- VLM 13y ago
  I don't have that belief. My interpretation of the opposition against systemd revolves primarily around: 1) /usr split 2) Can't run on kfreebsd and hurd because they don't speak cgroups so either "we" can't run systemd or need to drop ports or need to support two init forever. You can eliminate #1 with some sysadmin work. A stub cgroups compatible API emulator type thing for kfreebsd and hurd would eliminate complaint #2 if the overall result were not much worse than existing sysvinit. One interesting solution is there is no particular reason to flick the power switch on kfreebsd over and over as quickly as possible. So one incredibly non-optimized way to "fake" cgroups process monitoring on kfreebsd would be to replace actual cgroup process monitoring with something ridiculous like "sleep 30". In 30 seconds, anything will have started or stopped, correct? Obviously a dev roadmap would be to replace/emulate/port real cgroup-like support, once people get tired of all cgroups api calls being replaced with "sleep 30". I can't be the first one to come up with this "great" idea.

Qantourisc 13y ago

Wasn't looking forward to this "upgrade" ... The fact that it's from the same dude as PulseAudio is enough to make me anxious, the pulseaudio stuff didn't go smooth. (I'm still of ALSA, yes also is a mess to.) So I hope I won't be forced, to a more crappy system ! The fact that it will be handling a lot of stuff more, sounds like a major pita ...

pyre 13y ago
| the pulseaudio stuff didn't go smooth That wasn't the fault of the developer so much as it was the fault of the distributions for jumping on the bandwagon (making it the default audio system) too early.
- nieve 13y ago
  Poettering oversold its state of stability and then seems to have largely lost interest during the most critical period of adoption. The distributions are responsible for believing the hype and shipping too early, but that doesn't change the fact that the developers were hyping it well beyond what was justified. PulseAudio has a lot of nice features, but it's still less stable and has more bizarre failure modes for me _9 years_ after its initial release than plain old ALSA. I literally know no other linux users who have ever had anything good to say about PulseAudio. Entirely anecdotal, but when it comes to trusting developers to do a good job in the first place, much less help with a major transition I'm not inclined to discount that.
  - pyre 13y ago
    After the initial transition period, I have not had any PulseAudio issues other than on maybe 2 occasions where the pulseaudio daemon ran amok, consuming 99% CPU for some reason, until it was killed. I'll admit that I'm not running any exotic configurations though, but built-in audio works just fine, and plugging my USB camera/microphone[1] has worked without issue for a long time too. At one point I was also able to stream audio from my HTPC to my laptop, so that I could use my headphones when everyone else was sleeping. Though I'll admit configuration was a pain in the ass, I don't recall being able to do that with ALSA (though I recall someone creating a shell script a while back that read from /dev/dsp and piped to a socket). Prior to PulseAudio, sound on Linux was always an uphill battle for me (don't get me started on regressions in the PowerBook audio driver that no one cared about since "it works on the newer PowerMacs"). It was a crap-shoot which audio system an application would use. OSS? Alsa? eSound? KDE's sound daemon? Do they all use the same mixer app? What happens when I write to /dev/dsp? Does all other audio block? Which applications support Jackd? etc... [1] Referring to the mic in the pulseaudio context. EDIT: > I literally know no other linux users who > have ever had anything good to say about > PulseAudio. I'll mention that the same could be said of OSS or ALSA too. They may have worked better for you, but I doubt that prior to PulseAudio, you were singing their praises from the rooftops.

synchronise 13y ago

I wonder why Debian didn't go with OpenRC (https://en.wikipedia.org/wiki/OpenRC https://en.wikipedia.org/wiki/OpenRC) as it is compatible with both Linux and *BSD, which also offers 'Process segregation through cgroups'.

kaeso 13y ago
The OpenRC port effort is currently ongoing and been sponsored by this year GSoC: http://wiki.debian.org/SummerOfCode2013/StudentApplications/LeiWang http://wiki.debian.org/SummerOfCode2013/StudentApplications/...
bkor 13y ago
Change happens by people doing work. There are at least 3 people actively working on systemd support. Meaning: they help out other packagers, file bugs, look at bugreports, coordinate with upstream, etc. For OpenRC, there is just one person advocating it. There is a summer of code thing, but seems not much work is done. Furthermore, OpenRC seems nice, but parallel starting of services is actually experimental/buggy (just ask one of the OpenRC maintainers!). So although you can have a similar boottime, one init system (systemd) will be running in a supported configuration, the other (OpenRC) in something that is known to have issues. That all said, I don't think Debian really makes decisions. What is being proposed is maintaining two. Aside from above, there is also the practical bit in that systemd provides something to replace the unmaintained and deprecated ConsoleKit with. This bit can be used on another init system (Canonical is using or will use it on Upstart), but at one point seems easier to rely on the existing systemd supporters in Debian to get things working correctly.
- synchronise 13y ago
  Surely the Debian Foundation can see that an init project that can support more than one kernel/OS, pretty much as Debian does with Hurd and kFreeBSD, would be a better platform to support through the long term.

bch 13y ago

"Maintaining portable code increases complexity Since systemd is written in C, the canonical way to write portable code is by using conditional compilation, for example with ifdef statements. That makes the code harder to understand and reason about, but more importantly it blows up the test matrix." Take a page from NetBSDs effort... http://www.netbsd.org/about/portability.html http://www.netbsd.org/about/portability.html

dschiptsov 13y ago

systemd is, in some sense, a very modern-day product - a mess of different "alien" concepts and functionality stuck together into one project with an intention to show other the only true way of doing things. It like some (freedesktop guys, perhaps) will come to Plan9 and would say that all they need is gconf* -like registry to have a uniform configuration, or something of the same level of absurdity. The movement out of shell-based initscripts for non-specialized (non-mobile/embedded) distributions is a cancer.) Remaining BSD guys are much more sane and "conservative" in this respect. There is absolutely no necessity to break what is good-enough and well-balanced - having a standard shell scripts to do the job they were designed to. FreeBSD's rc.d system is a very good example.

Jasper_ 13y ago
systemd has one purpose: to be about system and service management. It will replace everything that deals with services: starting them (whether based on traditional init, scheduling, socket activation, or from a desktop user session), logging the stdout/stderr in a consistent and well-defined location, and about giving you flexible tools to manage, debug, and inspect system services. Besides that, yes, it does have a few things (hostnamed, timedated), which are mostly about some POSIX infrastructure that wasn't there already: notification when the system hostname or timedate changes (yes, it happens quite often on desktop systems, due to NTP, user setting, and VPN). They're just utilities they needed along the way, and systemd can be built without them. If the system or service fails to start, instead of hunting around in /var/log/, syslog, dmesg, etc. for anything that looks relevant, you simply use the journal which aggregates most everything. It's already a very good breakthrough. I've debugged countless bad Debian service scripts (which usually comes down to bash's terrible whitespace and quote management), and inserted echo statements into my Arch Linux to debug why it wouldn't boot when I upgraded, hacking out clear statements here and there designed to make the boot pretty. Shell scripts aren't a good solution for robust system and service management.
- dschiptsov 13y ago
  We have no services in UNIX-like systems, we have daemons and it is perfectly OK to use a templated shell script to start/stop restart it, modified according to the nature of a daemon, as needed. That other operating system from which the concept of a "service" came from (along with lots of other crap) have different philosophy and founded on different design decisions, so blindly trying to bring stuff from it here is not always reasonable. And, of course, shell scripts are OK when well-written - there are other UNIX-like systems beside Linux.)

16s 13y ago

When higher-level software begins requiring systemd (Gnome, KDE, etc.), the BSDs and other non-Linux, but Unix-like operating systems will no longer be able to use that software.