Debian debates systemd

By Jake Edge
July 27, 2011

Wherever systemd goes, arguments about it seem to follow. The latest episode involves Debian "discussing" the pros and cons of the init replacement, with many of the same arguments we have seen elsewhere on both sides. But there is a difference for Debian because, unlike most distributions, it supports both Linux and FreeBSD kernels and may start supporting Hurd in 7.0 ("Wheezy"). That makes switching to systemd more difficult for Debian—if it is even desirable—but it also brings up an interesting question for the distribution: should the needs of the smaller sub-distributions (GNU/kFreeBSD, GNU/Hurd) hold back progress on Debian GNU/Linux?

Perhaps unaware of the firestorm he was about to set off, Juliusz Chroboczek posted some observations about systemd to the debian-devel mailing list. In it, he offered his opinion on the good and the bad with respect to systemd and tried to make it clear that he wasn't trying to push the decision in any particular direction, just recording his observations. Overall, it is a fairly even-handed look at systemd that notes multiple advantages and disadvantages.

Of course, systemd advocates will argue that some of the disadvantages cited are wrong as Debian systemd maintainer Tollef Fog Heen did, but overall there weren't many big complaints about the posting itself—except from systemd developer Lennart Poettering. His response was forwarded to the list by Chroboczek and was characteristically combative, which to some completely justified one of the original posting's complaints: "Systemd's author is annoying".

Undoubtedly Poettering is tired of defending systemd against what he sees as "amazingly badly informed" criticisms. Given that the overall tone of Chroboczek's post was fairly positive, though, it's a little surprising to see the animosity with which Poettering responds. One of the main problems that some in the Debian community (including Chroboczek) have identified with systemd is its "Linux-only" attitude. Poettering addresses that, like he has many times before, but includes a long list of non-POSIX features that systemd uses, concluding: "There's a reason why systemd is more powerful than other init systems: we don't limit ourselves to POSIX, we actually want to give the user/administrator the power that Linux can offer you."

But that power also limits the environments where systemd can run, of course. In addition, the systemd developers have made it clear that they are not interested in taking patches to make it portable to non-Linux systems. In fact, Poettering calls it "practically impossible. about every line of it is non-portable code" in an IRC conversation summary posted to the thread by Matthias Klumpp. All of that makes it difficult for the Debian FreeBSD port, as well as the Hurd effort (and would presumably hinder a humorously suggested Plan 9 version of Debian too).

The Linux versions of Debian (including the various architectures and embedded Linux versions) are by far the most popular, so there is a question of how much minority Debians should be able to hold back progress. As Uoti Urpala puts it:

I think the important question is whether portability to other kernels is or should be a "project's goal", and how much else you're willing to lose for the sake of that goal. I know I would personally be a lot happier with a Debian that supports systemd functionality than with a Debian that can run on a BSD kernel.

Wouter Verhelst, on the other hand, is adamant that GNU/kFreeBSD is going to continue as part of Debian, and that systemd is not welcome if it will make it harder for that variation to operate:

Whatever its features, if we have to jump through a large heap of hoops to get it to work at all, or to make life for maintainers of daemon packages not a complete nightmare, it's not likely to become the default in Debian any time soon.

As might be guessed, Urpala was not convinced that supporting FreeBSD was enough of a reason to stop the eventual adoption of systemd:

But the attitude that it's OK for kFreeBSD to set limits on Linux development (or that developers working on Linux must handle the BSD porting/compatibility to be "permitted" to adopt a new technology) smells of trying to hold the project hostage, and I doubt it can have positive effects for the project overall.

In addition, he and others believe that moving away from the traditional System V shell-script-based init would be a net benefit for package maintainers: "I think the life of many maintainers of daemon packages is a 'complete nightmare' now with sysvinit, compared to what it would be with systemd." Because systemd can use existing init scripts, there is no need for a mass translation of packages to support systemd. However, an eventual switch to use systemd by default would undoubtedly cause various Debian packages to drop their init scripts in favor of systemd unit files that are far simpler, but wouldn't be usable directly by the System V init system that is currently the default. All is not lost however, as Russell Coker describes:

If a daemon supports socket activation then there would need to be separate work done to write a systemd unit and a sysvinit script.

If a daemon doesn't support socket activation then IMHO the ideal situation would be to have a program that takes a systemd unit file as input and creates a sysvinit script. That would reduce the amount of effort and reduce the amount of low quality sysvinit scripts that are out there (and I've written my share of such bad scripts).

Another possibility would be for Debian to directly support both System V and another init (i.e. systemd or Upstart) but many think that idea is a non-starter. Maintainers would have to support both styles of initialization (or ignore the benefits of the newer systems) as Russ Allberry noted:

Unless you're willing to write init scripts and cripple systemd by making it use init scripts, it's a huge pain, since you have to maintain two parallel init setups for every package requiring something to run at boot, one of which will probably never be tested by the maintainer.

The same issue applies with upstart, of course. Both systems support old-style init scripts, but one of the huge motivations for switching init systems is to *stop using* old-style init scripts, since they support a tiny fraction of the capabilities of systemd or upstart and are massively annoying and tricky to maintain in a bug-free fashion.

There is a potential support problem for upstream projects, however, as Gergely Nagy points out: "[...] even if systemd can be made portable enough for Debian's needs, or Debian can find a way to work around systemds unportability, upstreams who need to support other systems will still have yet another extra burden to carry." Of course, whether Debian switches to systemd, Upstart, or stays put, the problem for upstreams doesn't really change. None of the init systems is likely to disappear anytime soon, so either upstreams or distributions will have to support all of them in one way or another. As is often the case, Debian project leader Stefano Zacchiroli finds some middle ground:

But what I find surprising in this discussion (with notable exception, luckily) is the feeling that portability is boolean: it is not. It is rather a trade-off among the work that needs to be done / code that needs to be maintained and the distro-wide technical choices that we make. In that respect, the fact that systemd upstream might decide not to integrate upstream our [changes] is sad, but it's not the end of the world: it won't be the first nor the last upstream not willing to integrate some of our changes.

Zacchiroli's post—worth reading in full—manages to express support for most of the positions taken in the thread, while also pointing out a clear path forward for any change to the init system for Debian. While there hasn't been a large contingent pushing Upstart in the thread, it is clearly on the radar as a possibility. Any change is likely to be a ways off in any case, so a long thread arguing the merits of systemd is premature. Whenever such a decision is made, though, the general sense from those participating in the thread is that the decision will be made on technical grounds separate from the issue of how to support non-Linux versions of Debian. That problem will be solved too, but there is no reason to hold back progress on Linux for other kernels (or vice versa).

Debian debates systemd

Posted Jul 28, 2011 8:16 UTC (Thu) by jezuch (subscriber, #52988) [Link] (21 responses)

> "There's a reason why systemd is more powerful than other init systems: we don't limit ourselves to POSIX, we actually want to give the user/administrator the power that Linux can offer you."

I tend to agree. Through all these years we got so many great features in Linux that go to waste because they are not in POSIX and thus "non-portable" and nobody uses them because "portability" is some kind of a holy cow. It's about time someone used them *somewhere* :)

Debian debates systemd

Posted Jul 28, 2011 18:26 UTC (Thu) by dlang (guest, #313) [Link] (19 responses)

Linux was able to grow because of portability, deciding that now that linux is big portability doesn't matter and developers should be encouraged to write linux only code smells very much like stage two of "embrace, extend, extinguish"

linux developers should not do things that they would criticise microsoft for doing.

Debian debates systemd

Posted Jul 28, 2011 18:45 UTC (Thu) by danieldk (subscriber, #27876) [Link] (3 responses)

Linux' portability was important when proprietary competitors were still widely used. If those competitors complied to POSIX/SUS, it was a reasonable expectation that the software would also compile on GNU/Linux without too many modifications.

Most proprietary Unices except OS X are gone, and the BSD and Hurd communities are really marginal. Does the community really want to slow down development for systems that are only used by thousands of users at most (Debian GNU/kFreeBSD and Debian GNU/Hurd)?

Debian debates systemd

Posted Jul 28, 2011 18:56 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

by that argument, nobody should develop for linux, after all, it's userbase is only a tiny faction of the userbase of windows (and with apple getting into businesses now, linux in corporate desktop use is also only a fraction of MAC OS use)

this doesn't mean that you can't do things that nobody else does (how can everyone collectivly make progress otherwise), but it does mean that you should keep portability in mind. This means that if you do use a linux-only feature, you need to think about how to work if that feature doesn't exist (graceful degradation)

Debian debates systemd

Posted Jul 28, 2011 20:29 UTC (Thu) by sgros (guest, #36440) [Link]

IMHO, his argument is valid, your's is a bit stretched. If you ask why, at least for two reasons:

First, you generalize 'nobody should develop for linux' and then suddenly you restrict yourself to desktop. It is true that (almost) nobody is developing _desktop applications_ for Linux. And it is true that with Apple in the game, Linux's chances of dominating desktop are quite slim. But server part is completely different story. So, 'nobody should develop for linux' is only in part true.

Next, if we analyze a bit more your analogy, then Debian in this context is Microsoft (similarity is for Apple) that tries to use Linux (or FreeBSD) as a core component of "Widows distribution". Then, Microsoft's kernel development team develops some new cool feature but it can not be put into use as other kernel's don't support it. And this is obviously false, as Microsoft (as well as Apple) uses only their own kernel and use them to the maximum extent possible (i.e. don't spend resources on developing something you don't need!). This is also true for IBM (AIX), HP (HPUX), and probably many others.

So, yes, in the end, Debian shouldn't be hold by FreeBSD or Hurd that are developed at much slower pace then Linux is (face it, Linux has a momentum).

But also, in the end, I don't care as much, since Fedora is my primary desktop (and server in form of CentOS/RedHat) and I like the way it develops.

Debian debates systemd

Posted Jul 29, 2011 9:55 UTC (Fri) by danieldk (subscriber, #27876) [Link]

Yes, except that we are not looking from the general perspective, but from the perspective of a project that has been developing a Linux distribution for 18 years.

Debian debates systemd

Posted Jul 28, 2011 21:09 UTC (Thu) by sgros (guest, #36440) [Link] (8 responses)

First, the key difference between Linux kernel and Microsoft is the fact that whatever is built into the Linux kernel is public. And no one is prohibited from reimplementing this same functionality. So no, Linux developers can not be accused of doing things Microsoft way...

And second, this POSIX stuff is treated as a kind of a holy cow! But it is only a standard that doesn't evolve (at least I'm not aware of that). And now it is misused in the sense: Well, that's not in POSIX so it shouldn't be used/implemented/tried. But, it is hard to get it in POSIX because lot of marginal (no specific OS meant here!) operating systems don't support that feature (political stuff as usual). And, they don't support it because (i) they don't have enough men power, and/or (ii) the feature is quite new and there are multiple possible approaches and so there is a certain degree of experimentation still present. So, we end up in some kind of a lock in which standard is misused to prevent further progress! And while I'm at that, note that there were times when SunOS/Solaris was a big leader and all other Unixes copied it, especially Linux.

And don't get me wrong, POSIX is good, and I'm not for "abolishing" POSIX. But, it's not set in stone and we have to be careful about context in which we are discussing it...

Debian debates systemd

Posted Jul 28, 2011 22:16 UTC (Thu) by dlang (guest, #313) [Link] (7 responses)

POSIX and the SuS (Single Unix Specification do evolve. It's not rapid, and like the C standard they work to codify and standardise what everyone is doing, not push new 'neat stuff' into the standard. So you won't see a lot of the desktop related things there.

Debian debates systemd

Posted Jul 29, 2011 10:10 UTC (Fri) by danieldk (subscriber, #27876) [Link] (4 responses)

But the standard can only evolve when at least someone is doing something new. So, either all members of the SUS committee should jointly dream up new features (without real-world evolution), or a member should try a new feature in their system and attempt to standardize it when proven successful.

Now, I don't who are participating in the SUS standard, but at least one vendor of a SUSv3 system (Apple) is adding features (not all in the realm of SUS) that are not standardized rapidly. Also, in GNU systems, there is precedent, e.g. think of gcc extensions to ANSI-C that a lot of software has come to rely on.

Debian debates systemd

Posted Jul 29, 2011 23:59 UTC (Fri) by dlang (guest, #313) [Link] (3 responses)

> But the standard can only evolve when at least someone is doing something new. So, either all members of the SUS committee should jointly dream up new features (without real-world evolution), or a member should try a new feature in their system and attempt to standardize it when proven successful.

yes, people should try out new things and push to get them standardised if they work well.

Linux has been doing this since it started.

> Also, in GNU systems, there is precedent, e.g. think of gcc extensions to ANSI-C that a lot of software has come to rely on.

many of these GCC only features are getting standardized in the latest C spec revisions.

the issue is not the existance of non-standard features, it's in not writing (or being willing to accept patches to provide) fallback routines that will let the software continue to function without these features.

If you want portability - use OpenSSH model...

Posted Jul 30, 2011 6:40 UTC (Sat) by khim (subscriber, #9252) [Link] (2 responses)

the issue is not the existance of non-standard features, it's in not writing (or being willing to accept patches to provide) fallback routines that will let the software continue to function without these features.

This is how OpenSSH is developed. Yet it's the most portable and useful ssh client today. How? Easy: separate team collects patches and publishes "Portable OpenSSH". Which is two times as big as original OpenSSH BTW.

I can see why Poettering does not want to do 2x work (actually more since complexity is growing faster then number of LOC) for the same gain so if other people will want "portable systemd" they'll need to create these fallbacks themselves.

If you want portability - use OpenSSH model...

Posted Jul 30, 2011 16:09 UTC (Sat) by jch (guest, #51929) [Link] (1 responses)

> I can see why Poettering does not want to do 2x work

It's always a dangerous exercice to try to double-guess an author, but from reading the systemd code I get the impression that he's deliberately using non-portable features, with relish. (See for example the systematic use of the "%m" printf descriptor where strerror would do just fine. 302 occurrences.)

The other reason for non-portable code, of course, is that systemd is doing a lot of low-level system stuff that usually belongs in separate utilities. Much of that could probably be compiled out if Poettering were to accept patches that optionally disable parts of systemd functionality.

-- jch

Why should not he?

Posted Jul 30, 2011 19:48 UTC (Sat) by khim (subscriber, #9252) [Link]

It's always a dangerous exercice to try to double-guess an author, but from reading the systemd code I get the impression that he's deliberately using non-portable features, with relish.

Quite acceptable choice if you decided from the start that you want to keep things simpler and don't care about portability.

See for example the systematic use of the "%m" printf descriptor where strerror would do just fine. 302 occurrences.

Yup. This means he was able to save few keystrokes 302 times. Good for him.

The other reason for non-portable code, of course, is that systemd is doing a lot of low-level system stuff that usually belongs in separate utilities.

Yup. But again: separate utilities are useful if they can be tied in different ways. If you only have something in separate utility to make porting easier then you make the whole system more complex for the sake of portability - and we already know Poettering decided to put simplicity ahead of portability.

Much of that could probably be compiled out if Poettering were to accept patches that optionally disable parts of systemd functionality.

Again: it complicates the whole thing for no apparent benefit (if you don't view portability as benefit in itself).

I've pointed to the openssh for this exact reason: portable version is quite literally 2x in size compared to non-portable version. OpenBSD version 5.8 is 81386 lines, portable version 5.8p2 is 169155 lines; of course there are a lot of autogenerated autoconf lines - but even so some 29660 lines change .[ch] code. I'm pretty sure "portable systemd" will differ from "non-portable" one similarly or even more - for the simple reason that it needs to deal with lots of low-level stuff. If people want to see such changes - they can create "portable systemd", no problem, but why should upstrem version be complicated for the sake of 1% of users?

Debian debates systemd

Posted Jul 29, 2011 10:43 UTC (Fri) by nowster (subscriber, #67) [Link] (1 responses)

You're all assuming that *BSD and Hurd are POSIX compliant. Hurd doesn't appear to be it omits certain POSIX constants in its headers for a start. (The one that bit me was PATH_MAX.)

Debian debates systemd

Posted Jul 30, 2011 15:48 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]

POSIX doesn't specify that there has to be a PATH_MAX macro. You may have to use pathconf() or fpathconf() instead.

Debian debates systemd

Posted Jul 28, 2011 21:42 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (5 responses)

Please. Portability (at least reasonable one) is a must for end programs (stuff like GCC, Gnome, and stuff). For low-level, kernel-intimate stuff it should be considered, but can certainly be traded for other desirable characteristics. BTW, I don't remember a similar tornado-in-a-teapot when X moved some stuff into the kernel...

Debian debates systemd

Posted Jul 28, 2011 22:12 UTC (Thu) by dlang (guest, #313) [Link] (4 responses)

> BTW, I don't remember a similar tornado-in-a-teapot when X moved some stuff into the kernel...

that's because X did things right.

they take advantage of the new linux-only features if they exist, but they have a fallback that they use if those features don't exist.

the opposition you are seeing isn't "don't take advantage of Linux-only features" it's "don't be dependant on Linux-only features"

it doesn't even need to be that _everything_ still works without the Linux-only features available, but if a feature isn't available, the only thing that should not work are the particulars involving that feature, everything else should still work.

Debian debates systemd

Posted Jul 28, 2011 23:46 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (3 responses)

Really? You can point at the userspace modesetting code for Sandybridge hardware?

Debian debates systemd

Posted Jul 28, 2011 23:55 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

My understanding is that Sandybridge support is still problematic for any use.

but even if there isn't ever userspace modesetting code for it, there are differences

1. the X team isn't going to reject paches that are submitted to add userspace modesetting code on the basis that they only care about Linux.

2. it's very common for _NEW_ hardware to not be supported under different operating systems, I see a huge difference between making it so that new software cannot run on existing systems and not supporting new hardware.

Debian debates systemd

Posted Jul 29, 2011 6:06 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (1 responses)

The last chipset to be added to the UMS path in the intel driver was GM45. Backported Iron Lake code exists but hasn't been merged, and nobody's shown any interest in Sandy Bridge. Meanwhile, nouveau no longer really supports UMS (including for chips it used to support) and modern Radeon is heading in that direction as well.

Would the X team reject patches that added UMS code to drivers that only have KMS drivers? I suspect so. It's additional complexity for almost no benefit. The people working on this code simply aren't interested in supporting BSDs if there's no commensurate effort on behalf of the BSD developers to implement compatible interfaces. The simple and observable fact is that X developers have little interest in supporting a fallback for non-Linux support on any vaguely modern hardware. BSD can catch up or BSD can run with VESA until the adoption of EFI makes that impossible.

Debian debates systemd

Posted Nov 5, 2013 21:38 UTC (Tue) by juliank (guest, #45896) [Link]

(Free)BSD caught up, AFAIK.

Debian debates systemd

Posted Jul 28, 2011 22:12 UTC (Thu) by ballombe (subscriber, #9523) [Link]

systemd does not even work on Linux. It only works with a small number of Linux versions, and only if a number of build-time options are set in make config.

Debian debates systemd

Posted Jul 28, 2011 8:28 UTC (Thu) by kragilkragil2 (guest, #76172) [Link] (42 responses)

But wasn't Lennarts prominent sales pitch for systemd "Everybody will switch to systemd except Ubuntu!". If that was a lie how many other lies did he tell?

And if the way systemd works is so superior why don't the BSD people come up with a similar BSD-specific solution. Last I heard was that the BSD kernel has most of the features needed.
Maybe the solution to this problem is just waiting a release and letting the dust settle.

Where exactly he did that?

Posted Jul 28, 2011 8:48 UTC (Thu) by khim (subscriber, #9252) [Link]

But wasn't Lennarts prominent sales pitch for systemd "Everybody will switch to systemd except Ubuntu!".

Hmm... The exact quote is The first big distribution with systemd by default will be Fedora 15, due end of May. It is expected that the others will follow the lead a bit later (with one exception). (where "one exception" pointed to Ubuntu). It was expected and it's still expected. But yes, it's not written in stone.

If that was a lie how many other lies did he tell?

None. Lennarts may a good politician. When politician is caught in a straight lie - it's the end of his carrier, but to say truth in such a way as to create false perception... this is what the politics is all about! View Lennarts escapades from this POV - and your life will be much simpler :-)

And if the way systemd works is so superior why don't the BSD people come up with a similar BSD-specific solution.

Actually they did. Other, smaller, BSD distributions just had no clout to push something like this.

Debian debates systemd

Posted Jul 28, 2011 18:49 UTC (Thu) by danieldk (subscriber, #27876) [Link] (1 responses)

And if the way systemd works is so superior why don't the BSD people come up with a similar BSD-specific solution. Last I heard was that the BSD kernel has most of the features needed.

There could also be political or social reasons: the BSD community tends to be very conservative.

Debian debates systemd

Posted Jul 28, 2011 21:19 UTC (Thu) by roblucid (guest, #48964) [Link]

When did they give up /etc/rc.local?
Gentoo didn't have Sys V init, but a "BSD inspired" start up, which is only Linux I remember using without Sys V init.

Debian debates systemd

Posted Jul 29, 2011 0:51 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (37 responses)

And if the way systemd works is so superior why don't the BSD people come up with a similar BSD-specific solution.

I suspect this is a good example of the difference between the Linux and BSD development models. When Mr. Poettering decided it would be a good idea to invent a new init system, he went off, implemented his idea, and convinced his distribution to try out the new system. Now that it looks good, they've switched to the new system and other distros are considering it. If it hadn't worked, his distro would have rejected the new init and gone back to what they were doing before. It produced at most a small fork between the distros, but nothing really major. Even within other distros, it's producing some heat and disagreement, but no serious threat of anything more.

I doubt it would have played out the same way in the BSD world. If a BSD had the same kind of rancor as displayed in the Debian discussion, it would probably be the first step in establishing Yet Another BSD Fork. That would wind up diluting the developer manpower to the point the new project would be very slow to turn the new init into a production system, and it would take even more time before the other BSDs were willing to adopt it.

Debian debates systemd

Posted Jul 29, 2011 3:53 UTC (Fri) by viro (subscriber, #7872) [Link] (36 responses)

It still might end up with a fork - if Debian puts that piece of shit into squeeze+1, I'll have very little choice. I prefer to spend time working on kernel, but I do need tolerable userland for that. And pissed'em'd would cross that boundary, even if its author had not been such a... politician, for the lack of printable terms.

I'm not fond of that possibility, to put it very mildly - running autobuilder is not my idea of fun and even though I need only a smallish subset of packages, build-deps make the set grow greatly. Not that doing that for all architectures I need would be fun either (x86/amd64/sparc64 as minimum, probably mips as well)...

I really hope they DTRT and send that crap packing. And I suspect that I'm not alone in that among the kernel developers...

Debian debates systemd

Posted Jul 29, 2011 10:18 UTC (Fri) by danieldk (subscriber, #27876) [Link]

What's your opinion of upstart?

Debian debates systemd

Posted Jul 29, 2011 10:54 UTC (Fri) by appie (guest, #34002) [Link] (3 responses)

I can hardly call 50000 LOC and a sort of dependency on dbus a "a tighly integrated, small, minimal, lightweight system". Not using XML configuration files is a good choice though.
I guess for the author and people advocating it's use there is a Problem that systemd solves. I don't quite came across that such a problem, so I don't require a solution really. But I'm probably get the 'solution' anyway when I'll upgrade somewhere in the future :)
The only benefit I see so far is for desktop boot time and it'd be suprised if there wasn't a simpler more elegant way to solve that issue (after all, starting dbus first causes a delay as well :)

Debian debates systemd

Posted Jul 29, 2011 12:09 UTC (Fri) by anselm (subscriber, #2796) [Link]

The only benefit I see so far is for desktop boot time

The potential for greater standardisation of system boot and daemon setup, and hence a reduction of distribution-specific peculiarities and/or bugs, is another benefit in my book.

Debian debates systemd

Posted Jul 29, 2011 12:47 UTC (Fri) by HelloWorld (guest, #56129) [Link]

> I can hardly call 50000 LOC and a sort of dependency on dbus a "a tighly integrated, small, minimal, lightweight system".
systemd needs some kind of IPC, and D-Bus is the only sane choice. Or, as Poettering himself put it: "Now you have two options: every project can implement its own IPC, duplicate code, and fuck it up. Or all projects use the same, powerful one with bindings for all programming languages, that has been reviewed thoroughly, is well known and hence relatively secure."

> The only benefit I see so far is for desktop boot time
Yeah right, because being able to reliably kill a service is not a benefit. Or getting rid of all the inter-service dependency crap because socket activiation just magically does the Right Thing.

Debian debates systemd

Posted Mar 15, 2013 21:57 UTC (Fri) by pgoetz (subscriber, #4931) [Link]

You must be running very simple systems then. We've run into a number of hard to solve timing issues with SysV init scripts (services that inexplicably refused to start) that required various random kludges; e.g. randomly inserting sleep 5 or some such in the init script.

Debian debates systemd

Posted Jul 29, 2011 12:33 UTC (Fri) by HelloWorld (guest, #56129) [Link] (2 responses)

> I really hope they DTRT
You mean Do The Right Thing as in giving their users an init system that is actually capable of reliably killing a service instead of listening to whining kernel developers that make up 0.01% of their user base?

Debian debates systemd

Posted Jul 30, 2011 21:28 UTC (Sat) by foom (subscriber, #14868) [Link] (1 responses)

+1. I'm so looking forward to having a init system that is actually good for more than spawning getty, that'd I'd consider switching to Fedora if Debian ends up *NOT* using systemd.

Debian debates systemd

Posted Jul 30, 2011 21:49 UTC (Sat) by HelloWorld (guest, #56129) [Link]

Well, systemd is already packaged in unstable and it works rather nicely. Even if debian doesn't adopt it as the default init system, it'd probably stay available, so I wouldn't switch to Fedora just because of that.

Debian debates systemd

Posted Jul 30, 2011 10:56 UTC (Sat) by patrick_g (subscriber, #44470) [Link] (25 responses)

>>> I really hope they DTRT and send that crap packing.

Unfortunately your post is very light on technical details. Why systemd is crap? Care to explain?

Debian debates systemd

Posted Jul 30, 2011 16:31 UTC (Sat) by viro (subscriber, #7872) [Link] (24 responses)

I have - many times. It hasn't seen an extension it wouldn't love; unfortunately, quite a few of those are badly written and Lennert doesn't seem to be able to realize that such a thing is possible at all. Reading kernel/cgroup.c is enough to make one puke; that's one hell of a badly written lump of code. Yes, it got into the kernel. The best thing to say about it is that it can be configured away, but only if userland does not rely on it. Another equally nasty piece is fanotify, and IIRC systemd also relies on that one. D-bus is spectaculary ugly as well, and contrary to the claims in this thread there *is* a saner replacement - plumber, that is. Yes, it would depend on kernel being Linux (or something supporting 9p), so it probably wouldn't make kFreeBSD crowd any happier, but porting 9p to FreeBSD kernel is not impossible (or to Hurd, for that matter, assuming that anybody cares; I definitely do not).

It's not about using non-POSIX stuff; there are perfectly POSIX-enshrined FPOS APIs - look at POSIX ipc for starters (interface and, unfortunately, implementation as well). And I've no problem whatsoever with Linux-specific things being used - I could hardly claim that after having done Linux implemantation of namespaces, after all. Or after having helped Ram Pai with shared subtree implementation - the latter being unique to Linux, as far as I know (Plan 9 has namespaces, albeit somewhat different, but not this one).

The problem is that Lennert seems to treat everything in the kernel, no matter how optional and badly written, as fair game for making mandatory. And _that_ is a bloody bad idea, no matter how many deficiencies sysvinit has. Init replacements are not optional, thus pinning their dependencies down.

If you want kernel/cgroup.c code review, I can probably post it a bit after -rc1. Assuming I survive writing it - high blood pressure and all such... Not sure if lwn would be the right place for that, though.

Debian debates systemd

Posted Jul 30, 2011 16:39 UTC (Sat) by viro (subscriber, #7872) [Link]

gyah... s/Lennert/Lennart/; I definitely need more coffee. My apologies...

Debian debates systemd

Posted Jul 30, 2011 19:04 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (13 responses)

It is upto user space developers to cross check which kernel API's are bad or not. If they are bad, kernel developers shouldn't have merged it. Besides, cgroups *is* a optional dependency for systemd.

Debian debates systemd

Posted Jul 30, 2011 20:23 UTC (Sat) by viro (subscriber, #7872) [Link] (12 responses)

I agree that shit shouldn't be merged. Mistakes happen; some of them - with worse reasons than other. It doesn't make stepping into a pile of shit any smarter, especially with this kind of exhuberance, but Lennart's lack of taste is his problem; having to enable that crap on my boxen is mine and maintaining a set of patches to affected packages in Debian I happen to care about + running autobuilders to generate binaries is more attractive for me than paying that kind of price.

Debian debates systemd

Posted Jul 30, 2011 21:37 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (11 responses)

Let's say I am a user space developer who isn't knee deep in kernel politics and I have no idea which interfaces are considered a terrible mess or which is awesome. If I like the functionality that cgroups offers (and my understanding is that even kernel developers who say it is bad code recognize the value of the functionality), I will use it and let the developers worry about the implementation details. I will trust kernel developers not to merge crappy code. Blaming user space developers for using interfaces that are merged and advertised as available in the kernel seems like just passing around blame. If it just the implementation that is problematic, it can be fixed although you will have to keep compatibility at the interface level. It is not ideal but not the first time it has happened either.

Debian debates systemd

Posted Jul 30, 2011 21:47 UTC (Sat) by riel (subscriber, #3142) [Link]

There should be no reason to keep compatibility in the kernel/user API for something as specialized as cgroups. There is a reason libcgroup abstracts that stuff away.

Debian debates systemd

Posted Jul 31, 2011 0:01 UTC (Sun) by gerdesj (subscriber, #5446) [Link] (9 responses)

... and you sir are spot on.

There is kernel space and there is user space.

The kernel exports a feature called cgroups and this is found useful and used in user space.

It is of absolutely no consequence whether the kernel code is ugly, pretty, has a nicely proportioned ankle or is downright gorgeous. It has an interface, and that is what is used.

To denigrate a user space system by arguing that the kernel implementation that it relies on is flawed is ludicrous to the point of disbelief.

Cheers
Jon

Debian debates systemd

Posted Jul 31, 2011 0:50 UTC (Sun) by viro (subscriber, #7872) [Link] (8 responses)

What the fuck? The interface in question is optional; it's *NOT* guaranteed to be present in any kernel. Disbelieve all you want, but that fact does depend upon your beliefs. Incidentally, the code behind that interface is a misdesigned piece of shit, best configured out unless there are extremely strong reasons to enable it. Not everything that can be enabled should be.

I don't give a rat's arse for denigrating or lauding systemd, its author or its fanboys (OK, beyond the usual allergy to fanboys of any persuasuion). The trouble with systemd is as pragmatic as it gets - due to architecture decision by systemd author(s), running it means that several really badly-written pieces of code will be executed in kernel mode all the time. It doesn't matter how the blame is to be distributed - I simply don't care. Not interesting. It's not about judging Lennart (FWIW, my opinion is simple - (a) obnoxious luser; (b) not my luser, thanks $DEITY), it's not about something systemd might "deserve". The only thing I do care about in that story is what code ends up running on my boxen and what can I do about that.

Debian debates systemd

Posted Jul 31, 2011 11:59 UTC (Sun) by anselm (subscriber, #2796) [Link] (3 responses)

It isn't quite clear to me whether you have a problem with the idea of cgroups in principle, or with the current implementation of cgroups.

If it's the latter, then with all possible respect why is committing to producing your own distribution (if only for your own personal use) for the indefinite future a better course of action than (contributing to) cleaning up or replacing the current cgroups implementation and being done with the issue? If nothing else it would be good for the Linux community at large, either by improving a feature that many people want to use (even though it is implemented badly), or else by making a feature that some people don't want to use (because it is implemented badly) more acceptable.

Also, many other parts of the kernel are »optional« in the sense that there is a switch in the config file that would make them disappear, but that doesn't mean it's a good idea to do so. Some of these might even be badly implemented (I'm not a kernel hacker, so probably wouldn't be able to tell), or might have been badly implemented when they were new and have since been cleaned up. If people are not supposed to make use of »optional« kernel features because they're, well, optional, why offer them in the first place?

Debian debates systemd

Posted Jul 31, 2011 14:27 UTC (Sun) by riel (subscriber, #3142) [Link] (2 responses)

The problem is with systemd not running when one of the optional kernel features it depends on is configured out (or the interface changes).

This is a serious lack of robustness for something that's supposed to replace /sbin/init...

Debian debates systemd

Posted Jul 31, 2011 15:52 UTC (Sun) by anselm (subscriber, #2796) [Link] (1 responses)

The traditional SysV init itself can fail in all sorts of interesting ways if its components aren't in the correct place or otherwise broken. Most distributions have figured out by now that depending on bash-specific stuff in »#!/bin/sh« scripts called during the init process is a bad idea if people install a different (POSIX-compatible) shell as /bin/sh, but it was not an obvious thing at the time. Personally I wouldn't look to SysV init as a paragon of robustness.

OTOH, it is reasonable to assume that distributions that come with systemd as the default init subsystem will make sure that the kernels provided with the distribution have the necessary features enabled. This is no more or less reasonable than to assume that distributions that come with a DHCP client have networking enabled in the kernel. It is also reasonable to assume that people who insist on tweaking their kernels will leave cgroups etc. in if they expect to use systemd, much like they will leave networking in if they expect to use TCP/IP.

Debian debates systemd

Posted Jul 31, 2011 16:39 UTC (Sun) by viro (subscriber, #7872) [Link]

And vice versa, the people who don't want to enable cgroup/fanotify/whatever weird shit Lennart decides to use today won't use systemd. Exactly my point...

Look, I've dealt with more than one entangled mess in the kernel code, thank you very much. I am *not* volunteering to fix cgroups; it's not just badly written kernel/cgroup.c - the interfaces on *both* sides (userland and the rest of kernel) are seriously misdesigned. As far as I'm concerned, configuring it out solves my problem nicely and those who want it are welcome to produce and submit patches. l-k is over -> that way...

And as for fanotify... *shudder* No way in hell I'm taking over that one. Eric is whole-heartedly welcome to that monster; as long as that fuckup can be configured away, I definitely will do so. On all my boxen.

Debian debates systemd

Posted Aug 1, 2011 8:39 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

systemd can work just fine without cgroups.

You will lose reliable kill support, but it'd still work.

Debian debates systemd

Posted Aug 2, 2011 3:35 UTC (Tue) by FraGGod (guest, #63193) [Link] (2 responses)

What on earth gave you guys that idea?

systemd ties units to a processes via cgroups and cgroups only, it's an absolute requirement for systemd to run. No cgroups support in kernel = no systemd. Period.

That said, you can disable resource controllers, like cpu, blkio, etc, they are indeed optional, but not the cgroups feature itself.

Debian debates systemd

Posted Aug 2, 2011 6:33 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Systemd maintainer in Fedora: http://lwn.net/Articles/441149/

Maybe he's incorrect, I've no idea.

Debian debates systemd

Posted Aug 2, 2011 7:46 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

I just did the initial packaging work and got it into the distribution and wrote up the feature page so Lennart and others have time to do the real work. Feel free to look at the source when in doubt. These patches will get you a system that boots but won't have all the functionality that relies on cgroups.

https://bugzilla.redhat.com/show_bug.cgi?id=628004

http://cgit.freedesktop.org/systemd/patch/?id=e5a53dc7463...

http://lists.freedesktop.org/archives/systemd-devel/2011-...

Debian debates systemd

Posted Jan 23, 2013 10:21 UTC (Wed) by pgoetz (subscriber, #4931) [Link]

> If you want kernel/cgroup.c code review, I can probably post it

Did this ever happen? Also, I'm curious to know your reasons for why plumber is better than D-bus.

Debian debates systemd

Posted Jan 23, 2013 15:58 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

Plumber? What is that? Care to provide a URL?

DBUS is _used_. It's actually _used_ in the freaking _real_ _world_. At that point saying it's "ugly" and everyone should just rewrite all their software to use my-obscure-and-useless-implementation is, shall we say, madness.

Debian debates systemd

Posted Jan 23, 2013 16:46 UTC (Wed) by andresfreund (subscriber, #69562) [Link] (3 responses)

Which says approx. nothing about a) the need to put into kernel, b) the quality of the patches submitted.

Debian debates systemd

Posted Jan 23, 2013 17:26 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

a) It's pretty clear - kernel message routing implementation reduces context switch overhead and the number of data copies.
b) Last time network subsystem maintainer refused even the idea of AF_DBUS - we evidently should use IP multicast. So people went the usual way - write something, ship 10 million devices with it and present it as a fait accompli.

Debian debates systemd

Posted Jan 23, 2013 18:30 UTC (Wed) by rleigh (guest, #14622) [Link] (1 responses)

Being in (allegedly) wide use has zero bearing on the quality or suitability of the code for going into the kernel. It's good to see that at least the networking maintainer has an ounce of sanity here. Being pressurised to include this on merits other than quality does not paint this (or the people doing it) in a good light. It's not good to see things being pushed hard by people with agendas which don't necessarily align with what's technically the best path to take, circumventing the review and criticism such a drastic change would normally have.

Debian debates systemd

Posted Jan 23, 2013 18:42 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Code quality is not the problem here (it can be reworked, patches are not that big), it's the opposition to the idea itself.

Debian debates systemd

Posted Jan 23, 2013 17:30 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

So, I found the documents about the plumber (http://doc.cat-v.org/plan_9/4th_edition/papers/plumb). What a freaking POS.

How is it even _comparable_ to DBUS? It can't be used to send file descriptors or credentials, it has no schema support for messages (they are free-form text), it has no central naming directory, it has no support for activation (though we can probably use systemd's socket activation for it). Oh, and it also mixes in weird routing rules that work on the basis of regex matching.

Do you even *know* how and why DBUS is used out there in the real world?

Debian debates systemd

Posted Jan 23, 2013 22:33 UTC (Wed) by raven667 (subscriber, #5198) [Link]

While a bikeshed argument on whether you like the style of plumber or DBUS better is probably not worthwhile I think there is an interesting point worth making and that is that even 15+ years ago the creators of UNIX thought that a system wide standard IPC protocol and daemon was an important thing to have, such that they implemented it. That's an important point to highlight because there are still so many who believe that the idea of a standard IPC system is non-UNIX and some sort of abomination and it should be pointed out how wrong that is.

Debian debates systemd

Posted Mar 15, 2013 21:59 UTC (Fri) by pgoetz (subscriber, #4931) [Link]

> Reading kernel/cgroup.c is enough to make one puke; that's one hell of a badly written lump of code.

That's completely irrelevant. cgroups are an absolute necessity in modern multi-user systems.

Debian debates systemd

Posted Aug 1, 2011 9:22 UTC (Mon) by lyda (subscriber, #7429) [Link] (1 responses)

Just out of curiosity, what does cgroups give you that process groups didn't already give you? Besides a new namespace?

Debian debates systemd

Posted Aug 1, 2011 12:49 UTC (Mon) by foom (subscriber, #14868) [Link]

Inability for contained processes to escape. Ability to get notified when it's empty.

Debian debates systemd

Posted Jul 29, 2011 19:54 UTC (Fri) by raven667 (subscriber, #5198) [Link]

But wasn't Lennarts prominent sales pitch for systemd "Everybody will switch to systemd except Ubuntu!". If that was a lie how many other lies did he tell?

I don't see how his assessment is incorrect, Most of the major distros and probably many of the minor ones are switching. systemd has a lot of momentum behind it because there was so much pent up demand for a better init system. Ubuntu won't switch for a while because they are funding Upstart and Debian is currently on the fence and will hopefully make a good decision but Fedora, SuSE and derivatives are switching to systemd and other minor distros are probably not far behind.

And if the way systemd works is so superior why don't the BSD people come up with a similar BSD-specific solution. Last I heard was that the BSD kernel has most of the features needed. Maybe the solution to this problem is just waiting a release and letting the dust settle.

It was mentioned here as well but I thought it deserved a repeat, launchd developed by Apple for Mac OS X is an open source, socket activated init that has a very similar design and scope as systemd (systemd was inspired by it). This has already been shipping for 5 years or so and proves the concept works well. It is native to a BSD style system so there really is no reason the BSDs (or even debian/kfreebsd) do not pick it up and bring their init systems into the 21st century.

Debian debates systemd

Posted Jul 29, 2011 14:52 UTC (Fri) by dw (subscriber, #12017) [Link] (4 responses)

I opened Lennart's reply expecting to read an angry, inaccurate rant. Instead what I found were many merits in support of systemd (in fact, that mail alone has partially sold me on it).

Not everyone is perfect, and not everybody gets along; I think the tone in which Lennart's reply was described by this article is somewhat unfair.

Debian debates systemd

Posted Aug 4, 2011 17:14 UTC (Thu) by Zizzle (guest, #67739) [Link] (3 responses)

I had the same reaction.

Just look at Lennart's response compared to the ad-hominem attacks and vitriolic rants prominent kernel developers are spreading in this thread.

It's the first time I've seen LWN try to do a mainstream media style sensational beat-up. Disappointing.

Good on you Lennart, keep up the good work.

Debian debates systemd

Posted Aug 4, 2011 17:25 UTC (Thu) by jake (editor, #205) [Link] (1 responses)

> Just look at Lennart's response compared to the ad-hominem attacks
> and vitriolic rants prominent kernel developers are spreading in
> this thread.

Well, obviously I couldn't compare 'rants' that came afterwards to what Lennart said in his reply. I tried to strike a balance regarding *how* Lennart seems to respond to things, but it would seem that I failed there. I *do* think that lots of the criticism of systemd is overwrought and often unfair, but I don't think that Lennart's tone (here and elsewhere) helps his case at all.

> It's the first time I've seen LWN try to do a mainstream media
> style sensational beat-up.

Eh? For whatever it's worth, that was not the intent here at all. The part about Lennart's response is a few grafs in a fairly lengthy piece. I thought it important to report that piece of the puzzle, though evidently I failed to do that well, but I certainly didn't dwell on it or sensationalize it. I think the sentence above is a pretty unfair characterization of the article. YMMV ...

jake

Debian debates systemd

Posted Mar 15, 2013 22:03 UTC (Fri) by pgoetz (subscriber, #4931) [Link]

Sorry, I read the article the same way. Far too much focus on "Lennart is annoying" when I and other's don't even agree that he is annoying at all in his responses. You need to get out more if you're seeing Poettering's responses and vitriolic.

Debian debates systemd

Posted Aug 5, 2011 18:42 UTC (Fri) by jubal (subscriber, #67202) [Link]

Dear me! A true fanboy! :-)

Debian debates systemd

Posted Jul 30, 2011 2:31 UTC (Sat) by sbergman27 (guest, #10767) [Link] (14 responses)

After living through (and continuing to live through) the nightmare of pulseaudio these last several years, I'm quite leary of Lennart Poettering's software. Debian is a damned good distro for its intended audience. If you have hardware that is less than a couple of years old, you might not want to bother. But if you don't, and want a nice, stable environment, use Debian. Systemd is an incredibly bad fit here.

We're talking about a distro which, to its credit, defaults to ext3, and goes the extra mile of seeing through the bullshit that made data=writeback the default for ext3 in kernel 2.6.30, and sets the kernel config option to make the tried and true data=ordered the default.

I just can't see perpetually alpha quality software like systemd going into Debian. And if they were going to change their init system, which I would not advise for their next release, Upstart would be a less bad choice.

Despite what people might tell you, the SysV Init system is still quite serviceable. It's not the fanciest. And it's not the best, if you're looking for features. But it works, and works well.

-Steve

Debian debates systemd

Posted Jul 30, 2011 15:53 UTC (Sat) by BenHutchings (subscriber, #37955) [Link] (3 responses)

I would consider most init scripts to be 'perpetually alpha quality software'.

Debian debates systemd

Posted Jul 31, 2011 2:10 UTC (Sun) by sbergman27 (guest, #10767) [Link] (2 responses)

I would consider most init scripts to be 'perpetually alpha quality software'.

Really? If I had to bet my life on something working properly, Debian's init scripts would definitely make the short list. Not so, systemd. Look, Debian is not Fedora. People simply expect Fedora to be shiny and have problems. And they expect Debian to be boring and work right. And I'll take boring and working right any day of the week. I'd give both systemd and upstart a pass until Debian x+2.

Debian debates systemd

Posted Aug 1, 2011 8:45 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

LOL ROTFL.

I've had many many many problems with Debian init scripts over the years. Right now, on one machine BIND init script hangs the shutdown process (luckily not after SSH is shut down). I've no idea why and too lazy to check it.

I've seen problems with Apache init scripts, lighttpd init scripts, postfix init scripts and so on over the years. All in Debian (I don't really use other distributions).

That's why I consider systemd to be such a good idea. Getting rid of these scripts is a great way to improve Linux.

Debian debates systemd

Posted Aug 1, 2011 19:40 UTC (Mon) by bronson (subscriber, #4806) [Link]

> If I had to bet my life on something working properly, Debian's init scripts would definitely make the short list.

Really??? I guess we'll miss you when you're gone.

Half of Debian's init scripts don't even support restart properly. Ever purged a package and found the daemon still running? Ever tried /etc/init.d/blah stop, seen no error, yet you need to go hunt down the daemon by hand? Happens to me all the time.

I love Debian, but please never ever bet your life on its crawling mess of always changing init scripts!

Debian debates systemd

Posted Jul 31, 2011 0:24 UTC (Sun) by gerdesj (subscriber, #5446) [Link] (9 responses)

What the hell has PulseAudio got to do with systemd?

I'll digress:

I run Gentoo on everything I have. I don't run PulseAudio on anything, whatever that is. I don't think its an OS and I'm pretty sure I can ignore it if I don't want it.

I do have to start and stop services on my systems and it would be nice if I could do that with some certainty as to their behaviour. Now Gentoo does things quite similarly to the SysV Init way, which is crap. You tell the service to stop and for some reason it doesn't but the system thinks it has. Then I get to play with ps and then kill or killall. This wastes my time.

Now, systemd can guarantee that a service has stopped by using the kernel interface by dropping the cgroup. It does things the right way.

There are quite a few other aspects of systemd that are quite useful.

As a sysadmin of quite a few systems, systemd is looking like a good idea.

Cheers
Jon

PS L Poetering does come across as a bit of a wanker but you cant fault systemd for that.

Debian debates systemd

Posted Jul 31, 2011 1:55 UTC (Sun) by sbergman27 (guest, #10767) [Link] (8 responses)

"What the hell has PulseAudio got to do with systemd?"

Everything. Years after its initial debut, I still have to kill PA and restart it on both desktop machines and my netbook something like twice a day. (No. I'm not exagerating.) It goes into a mode where everything sounds like alien flute tunes. Every 6 months, I encounter another set of PA problems. Not a huge deal since it's simply a sound issue. But it says something about the author/maintainer. I certainly would never want to trust my customers' servers to Lennart's idea of software quality. The guy has an attitude problem, and it shows up, clearly, in his work.

Debian debates systemd

Posted Aug 1, 2011 8:48 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

Hm. It looks like your drivers are crap.

I've been running PulseAudio on tens of different devices without any problem at all for a couple of years now.

Debian debates systemd

Posted Aug 1, 2011 16:38 UTC (Mon) by sbergman27 (guest, #10767) [Link] (6 responses)

Right. All my machines for the last several years have had crap drivers. If that's the case, what does it say about Linux?

Odd thing, though. If I disable PA completely and replace it with esd, all those problems magically disappear.

Debian debates systemd

Posted Aug 1, 2011 16:41 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

It says that sound drivers are crap.

And I really find it hard to believe that it all magically works with ESD without having a lot of fun with ALSA config files.

Debian debates systemd

Posted Aug 1, 2011 17:50 UTC (Mon) by sfeam (subscriber, #2841) [Link] (1 responses)

The difference being that once you have an ALSA configuration working, it stays working. Whereas in my sad experience pulseaudio's configuration only stays working until the next suspend/resume or reboot or phase of the moon. For USB sound, chances are about 50/50 that after a resume pulseaudio will refuse to admit the device still exists. The only reliable fix I've found for this is to blow away ~/.pulse and restart from scratch. Now maybe there is a configuration option that I've failed to find - one that says "pin this device across suspend/resume; even if you don't see it immediately, it _will_ come back." If so, I may be falsely blaming the implementation when it is more correctly a documentation failure.

Debian debates systemd

Posted Aug 1, 2011 19:07 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Not so. I've had persistent problems with ALSA (and OSS) before the PA.

Your USB issue seems to be related to your USB devices. I have a USB camera/microphone and they work just fine.

May be you should file bugs?

Debian debates systemd

Posted Aug 2, 2011 2:34 UTC (Tue) by Trelane (subscriber, #56877) [Link]

Perhaps, but at least it says that Linux device drivers aren't the same as Windows device drivers, leading to bugs in the hardware getting exposed to Linux and not Windows. See also mjg59's stuff on the importance of Doing It Like Windows.

Debian debates systemd

Posted Aug 4, 2011 21:25 UTC (Thu) by oak (guest, #2786) [Link] (1 responses)

ESD? Shudder. When they finally abandoned it, it still had battery eating daemon/lib error-handling/busyloop bug(s). KDE's sound daemon wasn't any better in the bugginess department. And I think these bugs were in the daemons themselves, not in the audio drivers.

Debian debates systemd

Posted Aug 8, 2011 10:51 UTC (Mon) by nye (subscriber, #51576) [Link]

>ESD? Shudder. When they finally abandoned it, it still had battery eating daemon/lib error-handling/busyloop bug(s).

Battery-eating isn't the end of the world - especially back when ESD was written since we didn't have all the CPU power states we do now, and hardly anyone had a laptop, so it didn't end up making much difference. The real problem with ESD was the randomly high latency and the fact that it was buggy and unstable.

That said, even today it's the only reliable-ish method of forwarding sound from a Linux machine to a Windows machine. Fortunately it looks like some brave soul has been working on getting PA running on Windows, so maybe within a year or two this crawling horror can finally be put to rest.

Debian debates systemd

Posted Aug 4, 2011 13:03 UTC (Thu) by slashdot (guest, #22014) [Link] (1 responses)

Hopefully Debian will switch to systemd, which will likewise hopefully lead to Ubuntu switching too.

Once this happens, all software will be able to assume that systemd is available and ditch initscripts, thereby simplifying daemon development.

Systemd's design is clearly the best, since on-demand activation is the only way to run the minimal possible set of daemons needed, and in the correct order.

Sysvinit is broken because there is no way to run daemons in the correct order other than giving up parallelization and defining the serial order by hand, while Upstart is broken because it launches everything which is installed on the system, as soon as dependencies are available (both of these approaches totally fail to scale to lots of daemon packages)

Conversely, with Systemd you can install a new daemon, and the system behavior won't change until you use it, but when you do it will work correctly.

The only issue is that activating daemons on-demand can be slower due to delaying their start-up; however, this should be fixable by adding a facility to store dependencies across boots, so that if a daemon activated another on the previous boot, then that other is preemptively started in anticipation of it being required on the current boot too.

The notion of systemd only working on Linux is dumb, since it is obviously possible to port it to any OS, albeit perhaps with varying degrees of functionality and performance

However, anyone wanting to use *BSD or something else should be expected the porting work himself.

Debian debates systemd

Posted Aug 4, 2011 16:55 UTC (Thu) by raven667 (subscriber, #5198) [Link]

The notion of systemd only working on Linux is dumb, since it is obviously possible to port it to any OS, albeit perhaps with varying degrees of functionality and performance However, anyone wanting to use *BSD or something else should be expected the porting work himself.

This is the same way that OpenSSH works, OpenSSH is OpenBSD-only and makes full use of that OS' capabilities but a separate patch set is maintained to turn it into Portable OpenSSH which can run everywhere else. I don't think that managing systemd that way would even be as much work as OpenSSH because I would expect systemd to stabilize over the next couple of years and not have a lot of churn after that.

Debian debates systemd

Posted Nov 6, 2013 0:44 UTC (Wed) by ras (subscriber, #33059) [Link] (1 responses)

Personally, I prefer they choose anything but systemd.

One of systemd's author primary arguments for systemd nothing else does what it does. If true, this is a problem - the same sort of problem we have with xorg. Everything should have alternates.

If Debian decides to use something other than systemd, it means there will be alternates for the magic it does cgroup's, udev and so on.

Debian debates systemd

Posted Nov 6, 2013 15:55 UTC (Wed) by raven667 (subscriber, #5198) [Link]

I'm going to propose an alternate view, for core system features especially competition happens between different operating systems but is far less useful within an operating system unless you are talking about replacing an older subsystem with a newer one that includes compatibility hooks for the old way of doing things (like Wayland and xorg or systemd and sysvinit). There is a diffuse cost borne by everyone when application developers have to port their applications between the different infrastructures provided by different distributions and versions of what should be the same operating system. You don't get any internet points for being gratuitously different, it just makes things pointlessly complicated as they have to deal with all the variability rather than just having a standard way to do things.