GNOME and/or systemd

By Nathan Willis
October 24, 2012

While GNOME is used predominantly on Linux desktops, it has historically supported other platforms as well. But the project is again debating whether or not it should add hard dependencies on low-level system components when those dependencies could have the side effect of making the GNOME desktop unusable on non-Linux operating systems and a large portion of Linux distributions. In this instance, workarounds for other systems are not too onerous, but the topic invariably leads to a larger discussion about how the project operates and establishes its direction.

Daemons and desktops

On October 19, Bastien Nocera announced to the GNOME desktop-devel-list that he would make systemd a hard requirement for gnome-settings-daemon's power plugin. Doing so, he said, would allow the plugin to better handle suspending the system, and it would simplify the power management codebase. The patch set also drops support for ConsoleKit and UPower. Nocera enumerated several benefits of using systemd for suspends, including providing better information to applications about suspending.

Perhaps predictably, several developers replied that adding a systemd dependency would make GNOME harder to deploy on systems that do not use systemd: in particular Ubuntu, Gentoo, the BSDs, and Solaris. At the very least, these downstream projects would have to patch gnome-settings-daemon, which makes maintenance more difficult for everyone. The distributions will have to dedicate time to patching and testing their branches, but a number of bug reports will invariably make their way back to Nocera and the other GNOME developers, too — bug reports that GNOME can do little about, since they involve downstream work.

Antoine Jacoutot said that the change would impact OpenBSD's decision to ship GNOME in future releases; Sebastien Bacher echoed the sentiment for Ubuntu, as did Brian Cameron for Solaris, and Alexandre Rostovtsev for Gentoo. For the present, however, the non-systemd projects are looking for a workaround, starting with a way to re-implement the systemd features expected by the power plugin. Although many seemed to initially interpret Nocera's "hard requirement" message to mean that gnome-settings-daemon would have a build-time dependency on systemd, he later clarified that the change relied on systemd's D-Bus interface, and that through run-time detection, the system would simply disable the power plugin if systemd was unavailable. According to another message, the power plugin only uses two systemd interfaces, inhibitor locks and session tracking.

But if the plugin that introduces the dependency only needs to access two well-known interfaces over D-Bus, the question becomes whether or not systemd is actually required at all. In the email cited above, Bacher asked if Nocera had considered defining the interfaces as a standard, so that GNOME would work on any system that implemented them. Nocera responded that the question should be directed at the systemd developers, as he was not interested in taking on the task. That suggestion garnered little support; although Rostovtsev expressed some interest, Bacher replied that he did not have time to undertake the task.

Complicating matters further is the prospect that if systemd becomes a dependency for one GNOME module, it is increasingly likely that additional modules will start expecting it as well. That could lead to the point where the non-systemd OSes conclude that the GNOME desktop environment is more work to support than it is worth, and the OS projects simply drop it. Jacoutot, who maintains the GNOME packages for OpenBSD, expressed concern over that possibility:

If we are talking about implementing a couple of systemd interfaces, fine. If the end goal is to need most of systemd to have a working Desktop environment then I am very much concerned and would love to know about it.

Similarly, in his message, Cameron noted that Solaris already has its own power management features, several of which support enterprise and cluster-management features that are not addressed by systemd. As a result, although Solaris is interested in making GNOME run if possible, the potential loss of features expected by customers is a likely deal-breaker.

GNOME ripples

For his part, Nocera argued that as module maintainer, the decision was his, and ultimately he needed to make it on the basis of how it affected his ability to maintain the code — not on the needs of downstream projects. As he told Jacoutot:

whether GNOME still works on OpenBSD is up to you, and the amount of time and effort you're willing to spend keeping up with the 'reference implementation'. We cannot tell you when the work needed to keep up will be too big, we also cannot tell you when the features systemd implements will be too hard to replicate on OpenBSD.

But there were critics of adding the dependency within the GNOME project, too. Florian Müllner pointed out that other packages would be affected by the patches, including GNOME Shell, and Colin Walters argued that because the full GNOME desktop depends on gnome-settings-daemon, the move did affect other packages and other maintainers.

In particular, Walters took issue with dropping support for ConsoleKit and UPower systems, because doing so would cause a major regression for GNOME on systems that used them. He offered to take over maintainership of the relevant bits of code. Nocera objected to that idea, characterizing it as a "we 'support it, kind of, but not really'" approach that would result in numerous bugs. Walters replied that bugs of that sort are an ongoing burden already, and that his objection was one based on general principle:

I don't care about ConsoleKit (the codebase) much at all. What I do care about is when I go to GUADEC and hang out with some of the Debian or Ubuntu people who rely on CK, we have a sense that we're part of a shared project.

I'm all for making GNOME+systemd kick ass. But not at the cost of giving up the "rough consensus and working code" aspect that forms GNOME and other FOSS projects.

Your process here was to post on a Friday that you were going to delete the code, have a lot of feedback even over the weekend, then on Monday *do it anyways*. That's just not the way we should approach problems in GNOME.

Nocera countered that he had carefully responded to every comment, and that his decision was in line with GNOME's guidelines. As to the process, he said:

GNOME's way seems to be to postpone the hard decisions 6-month down the line. I've already had those same problems when I wanted to remove the date and time helper in January, even though we discussed having systemd as an external dependency in May the year before.

Walters also pointed out another issue, which was that maintaining ConsoleKit support is unnecessarily complex because of how little code is shared between the various GNOME modules. Matthias Clasen agreed, saying "in some cases (such as power or randr), we have dbus interfaces, in others we share code in libraries (randr again, xkb, backgrounds), and we also copy some glue code around (user accounts come to mind)."

Steering

Certainly, no one would argue that Nocera and other module maintainers are not free to make the decisions that they see as the best path forward; in fact GNOME has long held "maintainers rule" as a mantra. As this case illustrates, though, that philosophy is far trickier to live by in the real world than in the abstract. Maintaining systemd and ConsoleKit support in parallel is a considerable amount of work, and it does not seem fair to impose that burden on Nocera. But as Walters and others pointed out, GNOME's modules do not live in isolation — introducing an external dependency in one module pulls it in for others (which can become chaotic), while dropping support for existing configurations harms users (and should not be done cavalierly).

Systemd is also something of a special case because its availability is a decision historically made by the distributions (and other downstream OS projects), based on system-wide factors that GNOME does not control. As Jacoutot explained, implementing workarounds for the gnome-settings-daemon power plugin is not likely to be a Herculean ordeal, but adding such a low-level dependency suggests that the number of workarounds require will begin to increase. Systemd's maintainers have no problem with this; they are intent on making the tool useful for more and more tasks.

But GNOME as a cross-platform project has different considerations. In this case, perhaps the long-term impact of the decision means "maintainers rule" is insufficient. Vincent Untz thought so, saying "this is exactly the kind of stuff that, at least from my perspective, was raised during the [Annual General Meeting] at GUADEC." At the meeting, several suggested that GNOME needed a "Technical Board" of some sort to set long-term strategy and make broader decisions that would affect multiple modules.

There has not been significant movement on that point since GUADEC; at the time the GNOME Release Team told the audience that it had been serving as sort of an ad hoc decision-making board in recent years, but that it was not entirely comfortable with the role. Nevertheless, it is still functioning in that capacity; Nocera pushed the changes through on October 22, in response to which Frederic Peters from the Release Team commented:

Well, this all happened a few days before the release deadline, this is not easy matter, we have a release team meeting this week-end and we will talk about the whole situation.

Of course this is still just 3.7.1, but anyway. I'd suggest we do *not* ship gnome-settings-daemon 3.7.1 in GNOME 3.7.1 and wait for a project-wide decision on how support of ConsoleKit systems should be (dis)continued.

Thus, GNOME users should know in a few days whether or not GNOME 3.8 is likely to require systemd or to drop support for ConsoleKit. But whichever happens, the debate is likely to continue.

to post comments

GNOME and/or systemd

Posted Oct 25, 2012 5:49 UTC (Thu) by davidstrauss (guest, #85867) [Link] (3 responses)

tl;dr: Using systemd for much of GNOME only creates a hard dependency on Linux, not using systemd as the base system's init daemon.

It's a bit misleading to say that making systemd a dependency for user sessions inherently requires using it for boot or the base system. It should be possible to boot with Upstart, SysV init, or any system of your choice and still run "systemd --user" to manage the user session. I doubt this will ever be a first-class option, but we shouldn't prematurely rule it out.

Of course, if a utility running in the user session interacts with the core OS to *manage* user sessions and expects to find systemd there, running systemd in the user session alone won't be enough. That makes the power plugin different from other parts of GNOME that could use a user session instance of systemd for, say, launching applications and session services like PulseAudio.

GNOME and/or systemd

Posted Oct 25, 2012 6:10 UTC (Thu) by mbiebl (subscriber, #41876) [Link] (2 responses)

Unfortunately you are mistaken about that, see http://cgit.freedesktop.org/systemd/systemd/commit/?id=6b...

GNOME and/or systemd

Posted Oct 25, 2012 6:24 UTC (Thu) by davidstrauss (guest, #85867) [Link] (1 responses)

That's interesting, given that systemd runs find in an austere container with no access to the base system. Maybe the user session mode requires interacting with the base systemd session management API. Regardless, I stand corrected.

GNOME and/or systemd

Posted Oct 25, 2012 9:45 UTC (Thu) by zuki (subscriber, #41808) [Link]

> Now, Thomas' patch actually changes much less than people might
> think. This is because sd_booted() simply checks whether
> /sys/fs/cgroup/systemd is mounted. But to run --user on a foreign system
> you need to set that tree up anyway, as that is a requirement for
> systemd either way.

http://www.mail-archive.com/systemd-devel@lists.freedeskt...

As a Red Hat employee ...

Posted Oct 25, 2012 9:48 UTC (Thu) by rwmj (guest, #5474) [Link] (8 responses)

I'm very unhappy about this attitude to other distros and BSD. I write a lot of software, and all of it works wherever possible on all distros, BSD, even Windows. I even keep around a whole stack of virtual machines running other distros so I can routinely test things against them and respond to bug reports. I know there are many others in Red Hat who feel the same way as me.

Rich.

As a Red Hat employee ...

Posted Oct 25, 2012 13:06 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

It's a trade off.

Portability is important, but so is also coming up with clean, simple, and correct solutions. Gnome is NOT going to be able to create a top-notch desktop system while still having to take on the work of supporting a dozen or so conflicting implementations of low-level system services with dramatically different capabilities for platforms that, frankly, nobody really gives a crap about except the developers.

Hell I expect that the majority of *BSD users don't even use BSD as their primary desktop. I expect the same thing for Solaris. The reason for this is that while they are good operating systems they have always been miserable on most desktop/laptop systems. Traditionally you ALWAYS get a massive increase in utility by using OS X or Windows desktop with Solaris/BSD/Linux servers when compared to using any platform alone. So this makes all the sense the in the world and is not a flame or a indictment of any sort.. it's simply reality.

Therefore forcing the Gnome Devs to compromise to support platforms that are always going to be a hopeless basket case when it comes to desktop is not a smart thing to do.

The solution, as I see it, is this:

Fork SystemD. Make a brain-dead version of it called AbortD or something like that. Have it provide the same APIs that SystemD provides for Gnome and Gnome software and just let the functionality not supported or conflicts with 'native' utilities on non-SystemD systems just go fallow. As SystemD grows and changes it will be simple to add functionality to 'AbortD' even if that functionality provides little more then a useless 'warm fuzzy' to software that tries to hook into it.

As a Red Hat employee ...

Posted Oct 25, 2012 13:09 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

To put it another way: have 'AbortD' provide the modern equivalent of symlinking systemd to /bin/true

As a Red Hat employee ...

Posted Oct 25, 2012 19:28 UTC (Thu) by alvieboy (guest, #51617) [Link]

Man, you made me laugh now :)

As a Red Hat employee ...

Posted Oct 25, 2012 16:38 UTC (Thu) by cmorgan (guest, #71980) [Link]

Sometimes it takes this kind of change in approach in order to build support behind a solution. Maybe a systemd equivalent as drag suggested, or maybe use a different system that works for your particular OS. Maybe a standard dbus interface that multiple OSes can implement.

Sometimes progress leaves behind those unable or unwilling to change.

As a Red Hat employee ...

Posted Oct 25, 2012 17:07 UTC (Thu) by dmm (guest, #9815) [Link] (1 responses)

> I know there are many others in Red Hat who feel the same way as me.

Glad to hear that. Unfortunately, for quite some time, I have an impression that RH is intent on bulldozing or swallowing anything not developed at RH. It reflects the reality that this company is by far the biggest in the open source world and thus has enough sources to behave as it does. Another poster below said that "Sometimes progress leaves behind those unable or unwilling to change" which reminds me of some David Byrne's lyrics: "The weak among us will perish/The strong alone will survive/Voices like thunder/Decisions like steel..." We're about to enter a philosophical discussion here, I'm afraid. And I am afraid indeed.

As a Red Hat employee ...

Posted Oct 28, 2012 18:27 UTC (Sun) by ovitters (guest, #27950) [Link]

I have an impression that RH is intent on bulldozing or swallowing anything not developed at RH

Are you aware that Matthias Clasen and Colin Walters work for Red Hat?

As a Red Hat employee ...

Posted Oct 26, 2012 13:49 UTC (Fri) by walters (subscriber, #7396) [Link] (1 responses)

It's relatively easy to be portable to get 60-70% of functionality. But some of the bugs in that last 30% get hard. As I said on the list, things like shutdown/suspend state and login state *are* related, and it makes total sense that systemd has them integrated in logind.

Mentioning Windows makes no sense in the context of GNOME - sure, maybe the libvirt client API or whatever compiles on Windows. That's not too hard, especially once you have a portability layer like we have in GLib that is necessary for GTK+ on Windows.

But the full desktop would be totally insane to even try on Windows; I know KDE tried, but I don't think they got anywhere really. It's hard enough to get everything working and making sense even when we control the full stack. Stuff like the integrated lock/login screen just wouldn't be possible, etc.

As a Red Hat employee ...

Posted Oct 26, 2012 14:16 UTC (Fri) by halla (subscriber, #14185) [Link]

Well, we never really put any effort in getting the desktop running on Windows. The kde-windows project focuses on getting the applications running. That works quite well, not perfectly, but well enough for real work.

GNOME and/or systemd

Posted Oct 25, 2012 13:01 UTC (Thu) by mjthayer (guest, #39183) [Link] (9 responses)

On the one hand it seems to me that such an unnecessarily tight dependency is a sign that the abstraction layers used should possibly be better chosen. On the other, a DBus interface isn't such a bad way of doing the abstraction - perhaps the solution would be to look at the interface systemd is presenting here and see if it can be generalised to be made useful to the other candidates?

That said, I have a feeling (not backed by expert knowledge), that systemd, while an excellent project, is straying a bit far from the principle of "do one thing and do it well". (Like, it must be said, the Linux kernel on top of which it runs!)

GNOME and/or systemd

Posted Oct 25, 2012 19:22 UTC (Thu) by iabervon (subscriber, #722) [Link]

The principle has never really been "do one thing, and do it well"; it's about having a collection of tools, where each tool does one thing well, but doesn't exist in isolation. Each command line tool should do one thing, but coreutils provides a bunch of tools, and busybox is a single executable which does many things, but any time you call it, it does one thing well. Furthermore, it's clear that "ln", "cp", and "mv" share conventions which make less sense for some than others, but all benefit from the consistency across tools (in particular, making symlinks has the arguments in an order which would not be the obvious choice if there were no other similar operations).

As such, systemd is reasonable as a set of functions which are designed together, implemented together, and shipped together, but can be called individually. (Which is not to say that systemd is necessarily designed or implemented well, but that there's not anything inherently wrong with a lot of functionality coming from systemd.)

GNOME and/or systemd

Posted Nov 1, 2012 4:05 UTC (Thu) by HelloWorld (guest, #56129) [Link] (7 responses)

"Do one thing and do it well" has never been a useful principle anyway (like most of the so-called "UNIX philosophy), as people have vastly different ideas about what "one thing" is.

GNOME and/or systemd

Posted Nov 1, 2012 6:43 UTC (Thu) by dlang (guest, #313) [Link] (6 responses)

you are ignoring the rest of it.

A loosely coupled collection of tools that each do one thing and do it well

the loosely coupled portion is what makes things work so well, and it allows you to have multiple options for doing each thing, including having some of the lower level tools be replaced over time.

replacing this with a tightly coupled set of tools that between then try and do everything just doesn't work. Commercial vendors who want to take over your entire system and have spent billions on software development haven't been able to make it work (Sun, Microsoft, IBM, Oracle, Novell, Apple and others have all tried at different times)

GNOME and/or systemd

Posted Nov 1, 2012 20:50 UTC (Thu) by HelloWorld (guest, #56129) [Link]

There's a difference between loose coupling and no coupling. systemd offers a few interfaces (d-bus, socket activation etc.) that can, but don't have to be used. So please, how would you make the coupling any more loose without sacrificing functionality?

GNOME and/or systemd

Posted Nov 2, 2012 17:13 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

You are comparing (again) apples and oranges.

replacing this with a tightly coupled set of tools that between then try and do everything just doesn't work. Commercial vendors who want to take over your entire system and have spent billions on software development haven't been able to make it work (Sun, Microsoft, IBM, Oracle, Novell, Apple and others have all tried at different times)

Actually at least couple of these (Apple and Microsoft) are fine. And on desktop they are winning. Microsoft also wins on SME's servers!

Why? The answer is obvious: robustness vs repairability. In the "professional" environment (where repairability is king) "loosely coupled collection of tools that each do one thing and do it well" works fine because there are people who can fix it - and it's easier to fix small thing which does "one thing well". When you move in the direction of unmaintaned devices you see only monolithic solutions - because they are more robust and there noone behind the keyboard who can fix them!

Think set-top boxes: people are proud that there are so many linux-based ones, but they violate "do one thing and do it well" pretty severely - you can not introduce tighter coupling then busybox's one!

Now, you may argue that even with busybox there are pieces which can be disabled and/or replaced. Sure, but systemd is designed in the same way so what's the difference?

If Linux wants to win on desktop then something like systemd is strict requirement, not an option! Now, on server… I'm not sure if it's good enough or not, but if it's somehow not good enough then it's simpler to fix it rather then fight it.

GNOME and/or systemd

Posted Nov 6, 2012 18:45 UTC (Tue) by kevlar (guest, #83261) [Link] (3 responses)

Systemd does violate the one thing well principle set by the Unix founders.

It also violates the no1 security rule of running as little as possible as root.

Busybox does not violate this rule because you can select every utility you want. The reason it is one binary is purely due to embedded hardware limits such as fragmented memory. Note that systemd is not ideal at all for deeply embedded systems that these set top box designers work on, though the kernel like busybox is perfectly configurable and usable on these systems to a smaller size than systemds pid1 even, and don't tell me Lennart said it's better for embedded because it isn't, check out the embedded lists like buildroot or uclinux, android uses a tiny init and android size devices actually account for a little of the embedded market.

I actually prefer OpenBSD as a desktop system to Linux however I do use Linux purely due to the dev power to provide faster and easier package and system updates for a few systems as well as the security KMS video can offer and on one system to run software that will only run on Windows/Linux.

The OpenBSD init system is great and is easily and completely followed and edited, locked down and understood from init.c and /etc/rc to rc.shutdown. Openrc and sysvinit is harder but do-able. I would be there all year with systemd.

The main problem with linux init is the human interfacing. Systemd is an improvement over upstart but I'd rather run upstart even and OpenBSDs and openrc's interface is far more intuitve and better than systemds.

The problem of sshd dying before a shutdown can be completed does not require systemd to solve and is something I have only witnessed on Linux a while ago. How about systemd hanging rather than one shell hanging on boot before sshd has started, a far more common occurence from the mailing lists.

Systemd actually offers a very poor function gain to risk ratio when you pick through the many pre-existing/stolen features and many either wrong assumptions or purposeful lies.

The majority of Linux systems (Gentoo, Debian, Ubuntu) will never run systemd so have fun marginalising Gnome and launching mate and XFCE.

Oh and moving critical statically compiled binaries into a larger /usr as encouraged by Lennart and the FSF is a function/stability mistake too. Think about it, don't take historical hype and busybox hype as given.

GNOME and/or systemd

Posted Nov 6, 2012 22:24 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> It also violates the no1 security rule of running as little as possible as root.
That's fun. Cause sysvinit runs MUCH more staff as root - bash, often perl and python, various unix utils, etc.

So thanks for supplying yet another argument why systemd is better.

GNOME and/or systemd

Posted Nov 7, 2012 18:51 UTC (Wed) by nix (subscriber, #2304) [Link]

Um, I might point out that bash, Unix utilities, perl and python are routinely run as root by *normal system administrators*, so the fact that sysvinit init scripts often run them as root is not a meaningful argument against them or against sysvinit. They would pose security concerns in any case.

GNOME and/or systemd

Posted Nov 7, 2012 19:00 UTC (Wed) by nix (subscriber, #2304) [Link]

Well, I disagree with a substantial proportion of what you have to say.

It also violates the no1 security rule of running as little as possible as root.

systemd is cut into pieces precisely so that this rule is satisfied. It doesn't run things as root unless necessary. Lennart isn't an idiot. (It just runs too much *as PID 1* for me to be happy with it.)

Systemd actually offers a very poor function gain to risk ratio when you pick through the many pre-existing/stolen features and many either wrong assumptions or purposeful lies.

This sentence veers through a variety of logical fallacies at blistering speed:

There's nothing wrong with writing new software that has some of the same features as pre-existing software -- it's actually a good thing if you want to keep the risk down -- and describing them as 'stolen' is not something I would expect an LWN reader to say. They're not 'stolen'. Lennart did not go round to Scott James Remnant's house and steal the secret Upstart blueprints. He stole nothing.
The only "wrong assumptions" I can find in systemd are the axiom that portability doesn't matter and all that follows from it, and the axiom that people won't worry if you pile lots of work into PID 1.
As for "purposeful lies", well, without stating them and providing evidence that Lennart knows those statements to be untrue, this is just a straight insult, and as little worthy of notice.

I think you need some better reasons for not using systemd. (Feel free to take mine. I won't consider it stealing, honest.)

GNOME and/or systemd

Posted Oct 26, 2012 6:19 UTC (Fri) by Comet (guest, #11646) [Link] (2 responses)

It's simple in theory (which tells you how hard it is in practice): as a project, you come up with a portability statement which declares what you will expect to run on, and get folks to accept that this is a guiding goal of the project. I do say this as someone who's produced, and updated, the portability statement for an active open source project. Much less politics, much smaller community, but it worked.

At present, the angst comes from the "betrayal" felt by developers who've worked to build GNOME, working on their chosen OS, when their work is later taken by others and made unavailable to them by making the project not run on their OS. I happen to sympathise with them: if the project has supported many OSes, then it's part of the unwritten social project that they either continue to do so, or develop a backbone, step up, and state clearly what the new reality is.

As things stand, I'm left with an impression of politician, ducking away from answering the hard questions of their constituents. When you tell everyone what they want to hear, but don't do anything to make the decisions something which others can be asked to adhere to, or have their code rejected, then the current complaint is the natural consequence, and will keep happening. It happens with bad managers in corporations, too. Unsurprisingly, open source projects are not only not immune to this, but with a common meme of "you can't tell volunteers what to do", are more vulnerable to it. Indeed, you can't tell actual volunteers what to do, but you can lay down guidelines for what contributions will be accepted. You don't *have* to accept code just because someone wrote it.

The Linux kernel gets this right.

GNOME and/or systemd

Posted Oct 29, 2012 14:45 UTC (Mon) by ovitters (guest, #27950) [Link] (1 responses)

You mean https://live.gnome.org/ReleasePlanning/WhatWeRelease or https://live.gnome.org/PortabilityMatrix ?

GNOME and/or systemd

Posted Oct 29, 2012 22:57 UTC (Mon) by Comet (guest, #11646) [Link]

No, because both duck away from affirmative statements of which platforms will be supported when push comes to shove.

The matrix reports what currently works where, but includes columns for OSes which the first document explicitly asserts that GNOME is not intended to be portable to those OSes. So nothing in that matrix is an affirmative statement.

The WhatWeRelease states "This effort focuses on a tightly-integrated desktop environment based on the GNOME Shell running on a GNU-based operating system with a Linux kernel. Above all else, our interest is to create a cohesive product. Uses of our technologies in other environments are welcome, but are considered secondary concerns."

The current controversy shows that the naive reading of that cited text is wrong. A secondary concern, but one for which use is welcome, does not get cut off absolutely by a hard Linux-specific dependency.

If the document carries any weight, then a hard Linux dependency is not allowed by the release team and they simply won't include components which have that dependency. If it doesn't carry weight, it's a meaningless sop. If it carries weight, but is open to reinterpretation which completely reverses the words, then techs in the GNOME project can never again complain about politicians and how they twist the language. :)

If that document carried the weight which, I infer, you assert it does (by your posting it) then there wouldn't be a LWN article because there wouldn't be controversy.

GNOME and/or systemd

Posted Oct 28, 2012 0:39 UTC (Sun) by GhePeU (subscriber, #56133) [Link]

"Nearly all men can stand adversity, but if you want to test a man's character, give him power."

Apparently the small power of being the maintainer of a module of a DE of a minority OS was power enough...

GNOME and/or systemd

Posted Nov 1, 2012 0:42 UTC (Thu) by wagerrard (guest, #87558) [Link] (44 responses)

I'm always amazed, in a sad sort of way, when developers do something that, inevitably, has the effect of reducing the number of users for their product.

This seems a classic case of developers making choices based on reasons important to developers, not users. In this instance, users want suspend to work when they run Gnome. How the developers make that happen is not at all important to them, and ought not to be to the developers. Otherwise, you know, they're coding for themselves.

Here we have the case of a single Gnome developer deciding that his unilateral decision is worth the potential loss to Gnome of every non-systems OS. How does that make sense?

GNOME and/or systemd

Posted Nov 1, 2012 3:47 UTC (Thu) by HelloWorld (guest, #56129) [Link] (40 responses)

> This seems a classic case of developers making choices based on reasons important to developers, not users.
If this change leads to better maintainability, the users will ultimately benefit as well.

> Here we have the case of a single Gnome developer deciding that his unilateral decision is worth the potential loss to Gnome of every non-systems OS. How does that make sense?
How does it make sense to waste time by maintaining support for operating systems like Solaris or OpenBSD that nobody uses on the desktop anyway?

Also, systemd is technically miles ahead of every other init implementation. The Linux community should embrace and leverage its functionality instead of starting yet another boneheaded turf war on whether to adopt it, like Ubuntu/upstart is doing right now. Lack of unity is what keeps Linux from succeeding on the desktop, just like it allowed the rise of Windows NT against UNIX a few years ago. Unfortunately, most people don't realize that and blather about what they think is lack of "flexibility" and "choice" etc..

GNOME and/or systemd

Posted Nov 1, 2012 6:40 UTC (Thu) by dlang (guest, #313) [Link] (38 responses)

> Lack of unity is what keeps Linux from succeeding on the desktop

so by that logic, and the fact that upstart existed before systemd, shame on the systemd people for creating a new project rather than just joining an existing project.

GNOME and/or systemd

Posted Nov 1, 2012 13:40 UTC (Thu) by HelloWorld (guest, #56129) [Link] (34 responses)

It's pointless to join a project whose basic concept you consider flawed. The upstart developers should just acknowledge that someone else came up with a better idea. After all, there is, a reason why distros such as Fedora and openSUSE dropped upstart in favour of systemd. Instead, they hold on to upstart due to NIH syndrome.

GNOME and/or systemd

Posted Nov 1, 2012 18:38 UTC (Thu) by dlang (guest, #313) [Link] (33 responses)

> It's pointless to join a project whose basic concept you consider flawed.

And this is why you won't get all these people joining systemd

GNOME and/or systemd

Posted Nov 1, 2012 19:41 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

You're missing the step two: "Create something better".

Upstart is clearly flailing in that regard. It definitely is NOT better and is actually getting worse with time.

What's funny, upstart's principal developer has stopped using Ubuntu because Ubuntu is not able to support the "forked world" anymore: http://netsplit.com/2012/10/30/goodbye-ubuntu/

GNOME and/or systemd

Posted Nov 1, 2012 20:39 UTC (Thu) by HelloWorld (guest, #56129) [Link] (31 responses)

Yeah, except that an init implementation that is unable to reliably terminate a service (i. e. upstart) *is* fatally flawed. OTOH, I have yet to see any sensible criticism of systemd (that is, something other than "oh my god, sysvinit is so much smaller in my apples-to-oranges comparison!" or "Kill Lennart Poettering, he made PulseAudio!" or "We didn't do it this way in 1985, so it must be against the UNIX philosophy!").

GNOME and/or systemd

Posted Nov 1, 2012 22:42 UTC (Thu) by nix (subscriber, #2304) [Link] (30 responses)

I thought mine (it changes too fast and is thus too unstable to be trusted as PID 1 on any system I administer) was fairly relevant. It doesn't necessarily mean that systemd is *bad*, just that I am far too conservative to use anything changing that fast as critical system software.

GNOME and/or systemd

Posted Nov 1, 2012 23:16 UTC (Thu) by HelloWorld (guest, #56129) [Link] (27 responses)

So your logic is basically that out of the existing init implementations you pick one of which you *know* it's broken (being unable to do basic things like reliably stopping a service) over one that *might* be broken?

Here's a rather witty quote by Georg Christoph Lichtenberg: "I cannot say whether things will get better if we change; what I can say is they must change if they are to get better."

GNOME and/or systemd

Posted Nov 1, 2012 23:42 UTC (Thu) by apoelstra (subscriber, #75205) [Link] (2 responses)

> So your logic is basically that out of the existing init implementations you pick one of which you *know* it's broken (being unable to do basic things like reliably stopping a service) over one that *might* be broken?

Given a choice between "I know how this is broken", and "I don't know how this is broken, and even if I did, that could change in a month", I'd take the former.

Having said that, I've been using systemd since it became the default on Fedora, and I've really had to go out of my way to break it.

GNOME and/or systemd

Posted Nov 2, 2012 0:56 UTC (Fri) by HelloWorld (guest, #56129) [Link] (1 responses)

> "I don't know how this is broken, and even if I did, that could change in a month"
Yeah, like every init implementation must be broken and the only difference between them is how.

Sorry, but "it changes too fast and is thus too unstable" is just a knee-jerk reaction to any kind of change, be it for the better or for the worse. It is *not* what I consider a sensible criticism.

GNOME and/or systemd

Posted Nov 2, 2012 8:01 UTC (Fri) by paulj (subscriber, #341) [Link]

It's perfectly sensible. Change in software leads to bugs - inescapable fact. Further, it can take time to find bugs, because some of them will live in rarely exercised code paths. General software changes tend to result in net positive change in the # of bugs. Changes that are strictly limited to fixing bugs can average to a net negative change in # of bugs, if done with care.

So if you take a piece of software, with its features just developed to an acceptable state, then compare that software with itself after a long period of use, it should be obvious that a lot more bugs will be /known/ about after the period of use. That information alone is worth something if you want to understand the behaviour and stability of a system in the face of whatever inputs. It means if needs be you could choose to limit the input in order to avoid whatever bugs. Further, if during that period of use those bugs are fixed (and fixes strictly limited to that), then the software at the end stands a good chance of being less buggy than the software at the beginning, for the given features.

This all sounds obvious to me. In case it isn't to you, or you think it's hand-wavingly subjective, let me point that the like of RedHat objectively earn billions of $ per annum exploiting this.

GNOME and/or systemd

Posted Nov 2, 2012 18:29 UTC (Fri) by nix (subscriber, #2304) [Link] (23 responses)

Yep. I know sysvinit is 'broken' in the sense that I can't stop a service except by running, e.g. /etc/init.d/blah stop (those scripts may be pig ugly and better off dead, but they work, and if they don't, kill(1) does). However, it works in the sense that the system boots reliably, 100% of the time: sysvinit /sbin/init has never ever once failed for me, probably because it is dead stable and simple and does almost nothing and never changes.

*None* of these properties are true of systemd as PID 1 yet, and given its rate of continued development they seem unlikely to be true for many years to come... and I really really need PID 1 never ever to die. I actually use my system for useful work and cannot afford to turn PID 1 of all things into Lennart's debugging playground. (Note that I had no objections to turning my desktop's sound card into Lennart's debugging playground: if that fails all that happens is that I have a pause with no music until I figure out what is wrong and fix it. If PID 1 dies, I lose everything I'm working on, instantly, and quite possibly get a bunch of stuff I did recently replaced with zero-byte files as well. Not an acceptable tradeoff. And it uses large, complex libraries like libdbus which I *know* to have had crash and security bugs, and fairly recently at that. I'm not willing to tolerate the risk of losing PID 1 to such bugs.)

systemd is just approaching the degree of stability where I might be willing to tolerate it in unimportant virtual machines with no data I value. Anywhere else, you must be joking. (In this it is very like filesystems: I don't use btrfs anywhere I need to keep running in order to get my work done either.)

Lennart's extensively documented contempt for people not running Fedora is just the icing on the cake. I have no desire to see a systemd crash get answered with 'run Fedora' like PulseAudio bugs have been in the past. But that's not the really important thing. The complexity and resulting potential instability of PID 1 is the important thing. Complexity is OK in e.g. Emacs or PulseAudio: if they die, you still have a system you can debug them with. If PID 1 dies, you don't, and you probably have disk corruption too. If PID 1 dying didn't instantly panic the kernel, this might be different -- but it does, so I am incredibly paranoid about it.

GNOME and/or systemd

Posted Nov 2, 2012 19:59 UTC (Fri) by HelloWorld (guest, #56129) [Link] (21 responses)

> Yep. I know sysvinit is 'broken' in the sense that I can't stop a service except by running, e.g. /etc/init.d/blah stop (those scripts may be pig ugly and better off dead, but they work,
How do those scripts make sure that things like double-forking perl scripts started by apache are killed when apache is? Oh wait: they don't.

> and if they don't, kill(1) does).
Except when sshd(8) was shut down before and you thus don't have a shell to run kill(1) from, which is common when rebooting a machine. I actually remember a comment from somebody here on lwn who had to drive hundreds of miles to a server room precisely because of this.

> However, it works in the sense that the system boots reliably, 100% of the time: sysvinit /sbin/init has never ever once failed for me, probably because it is dead stable and simple and does almost nothing and never changes.
Otoh, all those pig ugly shell scripts you mentioned earlier can and do fail all the time. Cyberax pointed to this blog post earlier, and that's but one example.
http://netsplit.com/2012/10/30/goodbye-ubuntu/
You compare sysvinit to systemd and ignore all those by no means trivial shell scripts which do all the actual work and which, unlike sysvinit itself, change all the time and are riddled of bugs. This is exactly the kind of apples-to-oranges comparison I meant earlier.

> And it uses large, complex libraries like libdbus which I *know* to have had crash and security bugs, and fairly recently at that. I'm not willing to tolerate the risk of losing PID 1 to such bugs
Otoh, you are willing to use the Linux kernel, which is much, *much*, *MUCH* bigger and more complex than libdbus, gets a major release with tons of changes every ~3 months and has security issues so regularly that its developers don't even bother documenting them anymore. Yeah, that makes sense.

> In this it is very like filesystems: I don't use btrfs anywhere I need to keep running in order to get my work done either
Heh, so you stick to tried-and-true file systems like ext4? Oh, the irony :)

> The complexity and resulting potential instability of PID 1 is the important thing.
systemd is *way* less complex than what it replaces. This guy put it best:
http://lwn.net/Articles/459725/

GNOME and/or systemd

Posted Nov 2, 2012 21:58 UTC (Fri) by nix (subscriber, #2304) [Link] (20 responses)

How do those scripts make sure that things like double-forking perl scripts started by apache are killed when apache is? Oh wait: they don't.

And I don't care. In my entire professional life I have never ever been bitten by this problem. Adding instability to my system to fix a theoretical problem which even if it hit would have zero negative consequences is not something I am willing to do right now.

Except when sshd(8) was shut down before and you thus don't have a shell to run kill(1) from, which is common when rebooting a machine.

Er, if that's happened your network interfaces have almost certainly been shut down as well. How on earth is systemd supposed to help here? systemd-telepathyd doesn't exist yet as far as I know. (Aside: my sshd never gets shut down until the mass-process-kill right before umount of /usr. It's a critical tool in remote system recovery: killing it explicitly earlier than absolutely necessary strikes me as a bad idea.)

Otoh, all those pig ugly shell scripts you mentioned earlier can and do fail all the time.

You don't get it. They don't fail for me. I'm perfectly willing to believe that systemd is the bees' knees and better in all sorts of ways: but it is more unstable than sysvinit PID 1, and as such on systems where stability is valued (such as every single one I work on), I'm not willing to sacrifice that stability for the sake of improvements which I really don't care very much about. (Yes, they're all nice: are they worth destabilizing my systems for? No. Others may disagree: their stability tradeoffs are different.)

You compare sysvinit to systemd and ignore all those by no means trivial shell scripts which do all the actual work

Those shell scripts are not running all the time. Those shell scripts do not have PID 1. If those shell scripts go wrong, the kernel does not panic. Is this really so hard to understand?

Otoh, you are willing to use the Linux kernel

I have no choice: nothing else will provide the features I need. (Also I'm paid to work on Linux system-level software!)

The Linux kernel introduces instability, granted, and every upgrade is a bit hair-raising (even stable kernel upgrades these days! :) ). However, systemd introduces more instability, and just like the kernel -- and unlike almost everything else other than glibc -- can instantly wedge and panic my system if it goes wrong. If I would prefer less instability to more, and am happy with the minimal features sysvinit provides (as I am), it follows that I should avoid systemd. As I do.

Heh, so you stick to tried-and-true file systems like ext4?

Yeah, that burned me a bit recently -- and I agonized for some time before deciding to use it in 2009. However, it's a hell of a lot faster than ext3 for my use case, the extents are hugely preferable for the very large disk images which I (like so many other people) spend a lot of time in these days, it has a much much faster fsck which is useful when disaster strikes, and it has an incredibly responsive and helpful upstream.

The latter factor cannot be underestimated. Lennart is also responsive, but he is all bristling with opinions I strongly disagree with, sharp edges and active but invisible laser beams: dealing with him is a lot more stressful than dealing with e.g. tytso. I do not like the thought of getting a load of social stress when already stressed out from trying to fix a system-destabilizing problem, and that's what I suspect I'd get from systemd.

This too is something that probably doesn't apply to other people: a huge proportion of my life has always been devoted to stress management, and 'X is more stressful than Y' is almost always a reason to choose Y over X, regardless of any other benefits of X. In this case, systemd bugfixing is both more likely and more likely to be stressful than the nigh-nonexistent sysvinit bugfixing: thus, sysvinit wins by default, regardless of any killer features it may or may not have. Other people have different priorities.

systemd is *way* less complex than what it replaces.

I did not say 'systemd'. I said 'PID 1': that component of systemd which if it crashes panics the kernel. systemd's PID 1 is much much more complicated than the tending-to-trivial sysvinit PID 1. It is also newer, and changing much faster because it is not years maintenance-dead: several commits a month just to systemd/src/core/main.c. Thus it is much more likely to contain bugs that cause it to die (and panic the kernel) than sysvinit. Now, yes, the shell scripts that sysvinit runs to boot the system are horrible nightmares that are better off dead -- but they only run at boot so cannot panic the kernel during normal operation.

sysvinit is dead simple and utterly stable. systemd PID 1 is terrifyingly complex by comparison. Sorry, for people who value stability, systemd is still completely out of the question, and will be for years. You'll note that this would be true no matter the code quality of systemd, no matter its benefits, it could be the best code in the history of the human race -- where things that can panic the kernel if they go wrong are concerned, that's irrelevant beside the failure risk.

GNOME and/or systemd

Posted Nov 2, 2012 22:20 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

> In this case, systemd bugfixing is both more likely and more likely to be stressful than the nigh-nonexistent sysvinit bugfixing

systemd bugfixing would be bad enough, but systemd is continually growing new, and more sophisticated features as well.

GNOME and/or systemd

Posted Nov 2, 2012 23:05 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Although most of that is in adding ancillary utilities that are shipped with systemd, not in the process which runs as PID 1

GNOME and/or systemd

Posted Nov 2, 2012 23:12 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Not really. Most of these features are simple small several-line code snippets to hook up external systems. They are not internalized in systemd binary itself.

GNOME and/or systemd

Posted Nov 2, 2012 23:11 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> Er, if that's happened your network interfaces have almost certainly been shut down as well. How on earth is systemd supposed to help here?

I've had to make a very real 4am trip to our datacenter once when a rebooting node was stuck in bind9 initscript, right after it killed sshd.

Systemd makes sure that services always stop successfully. Reliably and automatically.

GNOME and/or systemd

Posted Nov 3, 2012 2:45 UTC (Sat) by HelloWorld (guest, #56129) [Link] (15 responses)

> And I don't care. In my entire professional life I have never ever been bitten by this problem.
Well, I guess you hadn't been bitten by the recent ext4 problem either until recently. And besides, even if you haven't, others have been, see Cyberax' comment.

> Er, if that's happened your network interfaces have almost certainly been shut down as well. How on earth is systemd supposed to help here?
systemd helps because, unlike sysvinit, it can reliably terminate a service so you don't have to mess around with kill(1) in the first place.

> You don't get it. They don't fail for me.
Well, lucky you. They do fail for others. I've had at least one boot failure due to a broken init script myself. And it broke for others too, see Scott's blog entry.

> but it is more unstable than sysvinit PID 1,
So you keep saying. But where are all those bugs that supposedly crash systemd all the time? I'm not from Missouri, but you'll have to show me anyway.

Besides, as Cyberax and raven667 have pointed out, there's not actually a whole lot going on in systemd itself, most of the recent activity is in systemd-journald and systemd-logind, both of which don't have PID 1.

GNOME and/or systemd

Posted Nov 3, 2012 10:06 UTC (Sat) by rleigh (guest, #14622) [Link] (14 responses)

> > but it is more unstable than sysvinit PID 1,
> So you keep saying. But where are all those bugs that supposedly crash
> systemd all the time? I'm not from Missouri, but you'll have to show me
> anyway.

Code has bugs, and the number of bugs increases as a function of the code size. systemd is much bigger than sysvinit, with a correspondingly larger probability of hitting such a bug. init is absolutely critical, and having it kept as tiny and simple as possible is essential for a reliable system.

This is not to say that systemd can't be large and complex, just that the complexity should not be in PID1. There's no reason why systemd PID1 can't be as small and tiny as sysvinit, with the rest in other processes. As a good example, look at s6, which has focussed on reliability to an even greater extent. There is no reason why systemd and other init systems couldn't adopt this approach.

At present, running a safety-critical or guaranteed reliable system with systemd is an untenable proposition. The risk of failure is too high. This isn't about "bugs that supposedly crash systemd"--it doesn't matter if any have been found or not. It's about the fact that a fault in PID1 will bring the system down, and managing that risk. systemd is a much greater risk than sysvinit. It's more reliable in other ways, as discussed in the thread. But that improvement is irrelevant so long as systemd PID1 remains a critical point of failure that is impossible to validate for correctness.

Regards,
Roger

GNOME and/or systemd

Posted Nov 3, 2012 11:39 UTC (Sat) by HelloWorld (guest, #56129) [Link] (8 responses)

> Code has bugs, and the number of bugs increases as a function of the code size. systemd is much bigger than sysvinit, with a correspondingly larger probability of hitting such a bug.
Great! Show one!

GNOME and/or systemd

Posted Nov 3, 2012 11:44 UTC (Sat) by rleigh (guest, #14622) [Link] (7 responses)

> > Code has bugs, and the number of bugs increases as a function of the
> > code size. systemd is much bigger than sysvinit, with a correspondingly
> > larger probability of hitting such a bug.
> Great! Show one!

This is unhelpful, and completely ignores what I said.

GNOME and/or systemd

Posted Nov 3, 2012 11:58 UTC (Sat) by HelloWorld (guest, #56129) [Link] (6 responses)

> This is unhelpful, and completely ignores what I said.
That's because there's nothing in your comment that hadn't been said already, bold formatting notwithstanding.

And again, if you care so much about reliability, the elephant in the room is the Linux kernel. If that is an acceptable risk, then so is systemd.

GNOME and/or systemd

Posted Nov 3, 2012 12:19 UTC (Sat) by rleigh (guest, #14622) [Link] (5 responses)

These points have been made before. This does not alter their validity.

Arguing that reliability in a critical system component is not of concern is absurd. Yes, the linux kernel can contain bugs. If you do care about reliability, you'll take steps to mitigate the chance of failure. This is a completely separate issue to the robustness and reliability of PID1; there's no need to confuse the discussion by mixing them together.

Ignoring the fact that this is an important concern does not do systemd any favours. systemd could certainly be changed to move the vast majority of the complexity in PID1 to a separate program running in a separate process. There's no intrinsic need for anything to be in PID1 except process reaping, starting/restarting another process and handling shutdown. Everything else can be done in another process; even shutdown--you can just exec the shutdown program. Take a look at how s6 is structured--it has a lot to be said for it, and there's no reason why systemd can't do this.

Regards,
Roger

GNOME and/or systemd

Posted Nov 5, 2012 1:04 UTC (Mon) by HelloWorld (guest, #56129) [Link] (4 responses)

Yeah well, you have a point, an absolutely minimal PID 1 will probably have fewer bugs than systemd.

Anyway, I think the risk is tolerable. I have never seen systemd crash on the systems I've been using. Also systemd doesn't just abort on SIGSEGV, it serializes its state and then execs itself anew. The code to do that is used in other places too (i. e. configuration reloading and reboot-less upgrades), so it's not some obscure code path that is never tested.

You'd have to be very unlucky to hit a bug that makes systemd crash and corrupts its internal state enough for the recovery mechanism to fail.

GNOME and/or systemd

Posted Nov 5, 2012 20:22 UTC (Mon) by nix (subscriber, #2304) [Link] (3 responses)

Also systemd doesn't just abort on SIGSEGV, it serializes its state and then execs itself anew.

Now that is neat. (There's still the faint possibility of corrupted state causing a loop of endless crashes, but that's not as bad as a panic.)

GNOME and/or systemd

Posted Nov 5, 2012 20:50 UTC (Mon) by jimparis (guest, #38647) [Link] (2 responses)

Also systemd doesn't just abort on SIGSEGV, it serializes its state and then execs itself anew.
Now that is neat.

It also appears to be completely untrue. The way I read it, systemd will (optionally) dump core, (optionally) switch VTs, (optionally) spawn an emergency shell, and (unconditionally) freeze.

GNOME and/or systemd

Posted Nov 5, 2012 22:12 UTC (Mon) by raven667 (subscriber, #5198) [Link]

That seems to be correct. There is logic in there for serializing state and re-execing itself which if I am reading correctly, is part of the startup process, so maybe the OP thought that was part of the crash recovery process. It seems that there is some infrastructure such that the described recovery _could_ be attempted, in the same fashion that it drops to /bin/sh on SIGSEGV,SIGILL,SIGFPE,SIGBUS,SIGQUIT,SIGABRT

GNOME and/or systemd

Posted Nov 6, 2012 0:23 UTC (Tue) by HelloWorld (guest, #56129) [Link]

Uh, yes, sorry, I had misunderstood what someone told me in systemd's IRC channel.

Anyway, if you configure systemd to spawn a shell, you can exec systemd from there, so not everything is lost.

GNOME and/or systemd

Posted Nov 3, 2012 20:32 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

>tiny and simple as possible is essential for a reliable system.
Yet init(1) is not reliable. Never has been, never will.

What are you going to do now?

GNOME and/or systemd

Posted Nov 4, 2012 1:16 UTC (Sun) by rleigh (guest, #14622) [Link] (3 responses)

This really isn't about "init vs systemd", it's about the complexity and robustness of PID1, whatever the init system in use might be.

There is a difference between the reliability of PID1 (e.g. /sbin/init) and the reliability of the programs run by that init such as rc (/etc/init.d/rc) for runlevel change, getty, and then e.g. individual init scripts run by rc/startpar.

In the case of sysvinit, init itself is small, simple and robust. It does little more than run rc on runlevel change, respawn gettys and handle a few other events such as shutdown signals. There is nothing stopping systemd, or a systemd-like complex init running as a respawnable service run directly from init (like getty), layering the more complex stuff on top of an ultra-simple PID1. This is partly what openrc does, building a more complex dependency-based boot on top of sysvinit.

The point here is that a bug in rc or getty will not kill init. And a bug in an init script will not kill rc. PID1 will carry on running, as will your system, if there is a bug in one of these higher level layers. Even in the case of sysvinit, there is scope to strip down PID1 even further--the runlevel change and service respawning could be moved into a separate process, as could shutdown.

While systemd does split some still out into additional binaries, the chance of a bug compromising PID1 functioning is much, much higher. Upstart is in a similar situation. Neither of these /need/ to have the complexity directly in PID1.

GNOME and/or systemd

Posted Nov 4, 2012 1:33 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Well, in this case the sysvinit PID1 is !@#*&^!*& unreliable. It can't even kill processes robustly. It can't start them robustly as well - I've had more than one hangup during startup.

> The point here is that a bug in rc or getty will not kill init. And a bug in an init script will not kill rc. PID1 will carry on running, as will your system, if there is a bug in one of these higher level layers.
Yeah. It's kinda like old classic cars with thick steel frame - it can run just fine after collision. You just scrape driver from the steering wheel, replace glass and your descendants can drive it as if nothing has happened!

What use in a robust PID1 if it can't do ANYTHING reliably?

GNOME and/or systemd

Posted Nov 4, 2012 12:27 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

Well, in this case the sysvinit PID1 is !@#*&^!*& unreliable. It can't even kill processes robustly. It can't start them robustly as well - I've had more than one hangup during startup.

You seem to misunderstand what I want of PID 1. Its job is to run an rc script when (in effect) the system starts up and shuts down and to reap processes. *Nothing else* (even forking gettys is really something else's job). Killing processes is killall's job. Monitoring processes is something else's job. Starting processes without hanging up is the job of some scripty thing or something. It is very definitely *not* the job of PID 1, since that is complexity that *can* be somewhere else, and thus *should* be somewhere else, rather than in the one process in the system whose death causes an instant kernel panic.

You keep on giving complaints about sysvinit that have nothing to do with PID 1 robustness, which is my primary concern when choosing an init implementation. sysvinit never fails to reap zombies: it never fails to run its single rc script per runlevel change (those scripts might later hang, but that is not PID 1's fault). It never, ever dies.

I would be happy with systemd were its PID 1 incredibly simple and never changing and all the work done by something else (which can change as often as it likes without causing instant kernel panics if it goes wrong). But instead its PID 1 is more of a kitchen sink than I'd like. Even sysvinit PID 1 really does too much: I'm definitely going to have a look at s6 and see if it has moved things like process supervision to some other binary. PID 1 should not do this job.

GNOME and/or systemd

Posted Nov 4, 2012 17:25 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

If you limit systemd to only running SysV scripts then systemd is incredibly stable. I don't think there was a bug in sysv-compat for a long, long time.

Yet it makes absolutely NO sense to view PID1 functionality in itself. It can't do anything, and any script it runs becomes mission-critical. It's easy to make a non-bootable (or non-haltable) system by making a small mistake in a myriad of twisty [not so] little scripts. And it makes no freaking sense that PID1 itself worked fine.

A car analogy: sysv is a metal cube with thick metal walls. It's very safe (since it can't move) and simple. Only to make it actually do anything useful you need to add wheels, engine, steering system, windows and windshields, etc. And in the end it turns out that a cube on wheels actually doesn't really work as a car and isn't safe anymore.

GNOME and/or systemd

Posted Nov 4, 2012 16:59 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

> I have no desire to see a systemd crash get answered with 'run Fedora' like PulseAudio bugs have been in the past.

IIRC, those comments were from a time when Ubuntu packaging was causing many of the bugs users were running into. Fedora's package was maintained closer to upstream and (I would expect) a newer version with other fixes.

GNOME and/or systemd

Posted Nov 2, 2012 2:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

That's not a good criticism of systemd in itself. That's just a reason to postpone its production use until it's stabilizes a little.

Besides, for simple uses systemd is already quite OK. I'm switching to it once it becomes available in Debian.

GNOME and/or systemd

Posted Nov 2, 2012 18:30 UTC (Fri) by nix (subscriber, #2304) [Link]

Well, yeah. That's just what I'm doing. Assuming it ever stops growing and sucking in more and more of the system, that is.

GNOME and/or systemd

Posted Nov 2, 2012 17:24 UTC (Fri) by intgr (subscriber, #39733) [Link] (2 responses)

> upstart existed before systemd, shame on the systemd people for creating a new project

Yes. But Poettering seriously studied and considered Upstart. The design of Upstart didn't allow what he wanted to achieve: http://0pointer.de/blog/projects/systemd.html

I believe he said in one of the systemd presentations that he did approach Upstart developers with his ideas, but they did not reach an agreement.

GNOME and/or systemd

Posted Nov 2, 2012 17:54 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

look at what I was replying to. The person was criticizing people for working with upstart instead of joining the existing systemd project and just modifying that instead.

I was pointing out that by that by that logic, the systemd people should never have started systemd, they should have joined one of the other existing projects and modified that instead.

In other words, stop criticizing people for working on the project that they think is right, or you will find that the same criticism works against you as well.

I don't think that there's any niche left where there isn't _some_ existing project that could be enhanced to fit whatever you want to have done. There can be very good reasons for wanting to do something new instead of joining and modifying the existing project (which can include the fact that the devs of the existing project may not want the changes you want)

GNOME and/or systemd

Posted Nov 5, 2012 2:28 UTC (Mon) by HelloWorld (guest, #56129) [Link]

> look at what I was replying to. The person was criticizing people for working with upstart instead of joining the existing systemd project and just modifying that instead.
What I criticise is essentially not the upstart developers' actions, but their motivation. There are two strong indications for NIH syndrome: the fact that upstart was developed at Canonical/Ubuntu, and the fact that various distros have or are considering to switch away from upstart in favour of systemd. The latter is a strong hint that there are significant technical benefits to doing so, as switching the init system is a fair amount of work. Creating a new project is fine if you have good technical reasons for doing so. But if you go your own way "just because", then that just makes everybody's lives harder.

Too much unity leads to stagnation and monopolies, too much diversity leads to chaos, bikeshedding and infighting. Neither is good for the linux community as a whole, and we should work on finding a middle ground. Today, we're way too far on the bikeshedding side of that fine line, and I happen to think that upstart is one part of that problem.

GNOME and/or systemd

Posted Nov 4, 2012 17:09 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

> If this change leads to better maintainability, the users will ultimately benefit as well.

But…in order for users to benefit, don't users need to be able to run it? Maybe you're implying that being forced to move away from GNOME for a BSD user is an improvement?

GNOME and/or systemd

Posted Nov 1, 2012 9:23 UTC (Thu) by paulj (subscriber, #341) [Link] (2 responses)

There's no commercial pressure anymore on GNOME. It's gone. Back in the GNOME 2 days RedHat still had an eye on general desktop Unix/Linux, as did Sun. Sun is now dead. RedHat seem to be following Sun down the road of catering exclusively to deep-pocketed, large corporates and public institutions, catering primarily for ultra-conservative Unix server deployments. Not sure how well that can end - there's may be sizable pots of money along that path, but there's also lots of gravestones at the end of it (Unix divisions of HP, DEC, etc, with the remnants of Suns' taking its last gasp).

GNOME and/or systemd

Posted Nov 1, 2012 16:14 UTC (Thu) by bronson (subscriber, #4806) [Link] (1 responses)

Excellent post. Sounds plausible and would explain some of the odd decisions being made lately.

To be fair, I can point to the gravestones of Eazel, Elektra, and all those netbook distros to show the peril of ignoring conservative server deployments. It's a narrow path!

GNOME and/or systemd

Posted Nov 1, 2012 18:37 UTC (Thu) by dlang (guest, #313) [Link]

note that the common problem in both cases is in ignoring a large portion of your users use cases, forcing those users to use different things in different places.

RedHat got it's foot in the datacenter door BECAUSE it was the most popular desktop linux at the time. Admins installed it in the datacenter because they were familiar with using it outside the datacenter.

Microsoft also took over many datacenters because it (superficially anyway) was the same as the desktops that people were running.

Ignoring either side of things opens the door for someone else to edge you out.