Category Archives: General

Systemd in GNOME 3.14 and beyond

Plan to get rid of ConsoleKit in GNOME 3.14

Before the start of the GNOME 3.14 cycle, Ryan Lortie announced his intention to make most GNOME modules depend on a logind-like API. The API would just implement the bits that are actually used. According to Ryan, most GNOME modules only use a selection of the logind functionality. He wanted to document exactly what we depend on and provide a minimal API. Then we could write a minimal stub implementation for e.g. FreeBSD as we’d know exactly what parts of the API we actually need. The stub would still be minimal; allow GNOME to run, but that’s it.

Not done for GNOME 3.14. Needs urgent help.

As didn’t see the changes being made, I asked Ryan about it during GUADEC. He mentioned he underestimated the complexity in doing this. Further, his interests changed. Result: still have support for ConsoleKit in 3.14, though functionality wise the experience without logind (and similar) is probably getting worse and worse.

Systemd user sessions

In future I see systemd user sessions more or less replacing gnome-session. The most recent discussions on desktop-devel-list indicated something like gnome-session would still stay around, but as those discussions are quite a while ago, this might have changed. We’re doing this as systemd in concept does what gnome-session does anyway, but then better. Further, we could theoretically have one implementation across desktop environments. I see this as the next generation of the various XDG specifications.

Coming across as forcing vs “legacy”

From what I understood, KDE will also make use of user sessions, logind, etc. However, they seem to do this by calling the existing software “legacy” and putting everything into something with a new name. Then eventually things will be broken of course. Within GNOME we often try to make things really clear for everyone. E.g. by using wording usch as “fallback”. It makes clear our focus is elsewhere and what likely will happen. I guess KDE is more positive. It might still work, provided someone spends the effort to make it work. In any case, the messaging done by KDE seems to be very good. I don’t see any backlash, though mostly similar things is occurring between GNOME and KDE. There are a few exceptions, e.g. KWin maintainer explicitly tries to make the logind dependency as avoidable as possible. I find the KDE situation pretty confusing though; it feels uncoordinated.

Edit: At least the user session bit in KDE is undecided. It was talked about and seemingly agreed between two well known KDE people, see here, but still undecided. Same person clarifying this requested that I clarify that I’m not from KDE. I am not from KDE.

Appearance that things work fine “as-is”

In a lot of distributions there is still a lot of hacks to make Display Managers, Window Managers and Desktop Environments work with the various specifications and software written loads of years ago. Various software still does not understand XDG sessions. They also do NOT handle ConsoleKit. Distributions add hacks to make this work, doing the ConsoleKit handling in a wrapper.

This is then often used in discussions around logind and similar software.

“My DM/WM/DE is simple and just works. There is no problem needing to be solved.”

There are various distributions which have as goal to make everything work, no regressions are allowed. If you use such a distribution and given enough manpower, enough hacks will be added which on short term ensures things work. However, those temporary hacks are hacks. E.g. if some software should support XDG sessions and it does not, eventually the problem is with that software.

Looking at various distributions, I see that those temporary hacks are still in place. Especially funny one is Mageia, where XDG session support is second class. The XDG session files are generated from different configuration files. This results in fun times when a XDG session file changes. Each time this happened, the blame is quickly with the upstream software. “Why are they changing their session files, it should just never change”. While the actual problem is that the upstream files are thrown away!

The support for unmaintained software has at various points resulted in preventable bugs in maintained software. While at the same time the maintained software is considered faulty. I find this tendency to blame utterly ridiculous.

Aggressive anti-advocacy

There are many people who have some sort of dislike for systemd. In the QA session Linus had at Debconf, he mentioned he appreciates systemd, but the does NOT like the bughandling. In various other forums I see people really liking systemd, but still having their doubts about the scope of systemd.

When either liking or disliking systemd, it is important to express the reason clearly and in a non-agressive way. Unfortunately there are a few people who limit their dislike in ways that’ll result in them being ignored completely. Examples are:

  • Failure to understand that a blank “you cannot rely on it” statement is not helpful

    If a project sees functionality within systemd that is useful, it is you’ll not get very far with stating that the project is bad for having used that. Or suggesting that there is some conspiracy going on, or that the project maintainer is an idiot. That’s unfortunately often the type of “anti-systemd advocacy” which I see.

  • Failure to provide any realistic alternatives

    Suggesting that systemd-shim is an alternative for logind. It’s a fork and it took 6 months or so to be aligned with latest systemd changes. Further, it’s a fork with as purpose to stay compatible. It’s headed by Ubuntu (Canonical) who are going to use systemd anyway.
    The suggestions are often so strange that I have real difficulty summarizing them.

  • Continuous repeat of non-issues

    E.g. focussing on journald. Disliking e.g. udev or dbus, confusing the personal dislike as a reason everyone should not use systemd.

  • Outright false statements

    E.g. stuff “systemd is made only for desktops”, “all server admins hate it”. If you believe this to be true, suggest to do your homework. That, or staying out of discussions.

  • Suggesting doom and gloom

    According to some of the anti-advocacy, there’s a lot of really bad things in systemd. A few examples: my machine should continuously corrupt the journal files, my machine often doesn’t boot up, etc. As it’s not the case, such a claim pretty much destroys any credibility they might have had with me.

    Anyone trying systemd for the first time will also notice that it’ll just work. Consorting to this type of anti advocacy will just backfire because although systemd is NOT perfect, it does work just fine.

  • Lack of understanding that systemd is providing things which are wanted

    Projects have depended on systemd because it does things which are useful. As a person you might not need it. The other one believes he does need the functionality. Saying “I don’t” is not communication. At least ask why the other believes the functionality is useful!

  • Lack of understanding that systemd is focussed to adding additional wanted functionality

    Systemd often adds new functionality. A large part of that functionality might have been available before in a different way. It’s something which most people seem to worry about. It’s usually added as a response to some demand/need. Having a project listen to everyones needs is awesome!

  • Personal insults

    This I find interesting. The insults are not just limited to e.g. Lennart, the insults are to anyone who switched to systemd. A strategy to of having people use something other than systemd by insulting them is a very bad strategy to have. Especially if you lack any credibility with the very people you need and whom you are insulting.

  • Failure to properly articulate the dislikes

    There are too many blank statements which apparently has to be taken as truths. Saying that something is just bad (udev, dbus, etc) will be ignored if the other person doesn’t see it as a problem. “That systemd uses this greatly used component is one of the reasons not to use it”. Such a statement is not logical.

  • The huge issues aren’t

    Binary logging by journald. Anti-advocacy turns this into one of the biggest problems. The immediate answer by anyone is going to be that you can still have syslog and log it as you do now. If you advocated this as a huge issue, then anyone trying to decide on systemd will quickly see that this huge issue is not an issue at all.
    The attempt is to make people not use systemd. In practice, if the huge issues aren’t an issue, then the anti advocacy is actually helpful to the adoption. The biggest so called problems are easy, so anyone quickly gains confidence in systemd. Not what was intended!

  • Outright trolling

    For this I usually just troll back :-P

What I suggest to anyone disliking systemd is to not make entire lists of easily dismissed arguments. Keep it simple (one is enough IMO), understandable but also in line with the people you’re talking to. Understand whom you’re talking to. Anything technical can often be sorted out or fixed, suggest not to focus on that.

Once the reason against is clearly explained, focus upon what can be done to change things. Here the focus should be on gaining trust and give an idea on what can be done (in a positive way).

Don’t ignore people who dislike systemd

Due to having seen the same arguments for at least 100 times, it’s easy to quickly start ignoring anyone who doesn’t like systemd. I’ve noticed someone saying on Google+ that the systemd should not be used because Lennart is a brat. Eventually enough is enough and it is time to tell these people to STFU. But that’s not according to one part of the GNOME Code of Conduct, “assume people mean well”. Not believing in people meaning well and ignoring it has bitten me various times.

Turns out, this person is concerned that his autofs mounted home directories won’t be supported some time in the future. So this person does follow what Lennart writes. While it appeared to me he’s just someone repeating the anti-advocacy bit, he has a valid concern. I still think it is unacceptable to call people names and said so, but it
is equally important to ensure things are still possible.

Can a “not supported” still be made to work?

Systemd developers are quick to point out that something is not supported. E.g. a kernel other than Linux. A libc other than glibc. Some use cases are not. But there’s a important thing to know: would the usecase be impossible, or would it take way more effort?

The type of effort is also important. For a different kernel/libc, you’d need a developer with good insight into these things. For others, it might be possible by customizing things. I assume the autofs homedirs will always be possible, just not always taken into account.

If it is not supported but can be used anyway if you’re an “ok” sysadmin, that’ll mean for most people it’ll be possible. A “not supported by systemd” does therefore not 1 on 1 relate to impossible. If you want a different libc but you’re are a sysadmin and not a developer that’s quickly seen as impossible. While another “not supported” is actually perfectly possible.

IMO it is good that not everything is supported. Ensure that whatever is supported works really well. But at the same time, I think more focus should be on ensuring people do understand that a “not supported” does not mean “cannot work”.

My opinion on systemd as a release team member

I like *BSD. I like avoiding unneeded differences, this easies portability.

There are some interesting tidbits I’ve learned. Apparently OpenBSD has a GSoC student working on providing alternative implementations for hostnamed, timedated, localed and logind. I don’t think it’s enough, because it needs to be maintained fully. I further think that a logind alternative cannot be written together with the other bits during just a summer. Whatever it is, I think this will make it even easier to use systemd. This is not what some of the anti-advocacy is intending to happen. Oh well.

There seems to be another round of (temporary) increase of people disliking systemd. I’m pretty sure it’ll quiet down to normal levels again once Debian has systemd in a stable release for a few months.

Eventually they’ll notice that although systemd is not perfect, it just works. Unfortunately, this all doesn’t help in with the concerns I still have.

What to do with ConsoleKit?

GUADEC 2014

Some quick thoughts about GUADEC 2014 in no particular order (apologies for any weird English: written while a bit tired):

  • Late opening of registration page made me feel uneasy with arranging things. Sort of felt like things might be cancelled. Probably should’ve spoken up about it beforehand.
  • Strassbourg looks really amazing.
  • I don’t get why EU moves between two cities. Waste of money.
  • I feel for the stress that the organizers must’ve had with GUADEC 2014. Don’t take anything I say about GUADEC 2014 personal.
  • GUADEC 2015 will be in Gothenburg, Sweden. I’m wondering how much alcohol people can legally take and if the selling of alcohol is a good method to ensure it isn’t too expensive for people.
  • I love taking a train, don’t like flights. On the way to Strassbourg I was investigated by a female customs officer. I think she didn’t appreciate me giving her a “wtf” look due to the full body armour + gun she was wearing. IMO that’s too much. Next connection a drunk dude was bothering everyone. It was funny to see what tactics people took. Usually putting their stuff on the empty seats. Initially I thought everyone was being a bit rude (putting your bags on seats on a pretty crowded train is IMO impolite). Initially it was funny when the drunk beggar started to talk to me. Unfortunately quickly discovered he had a really foul smell. He left quickly though, think just wants attention. On the way back the train was delayed quite heavily. First train was annoying, only had to take it for maybe ~30min, was at least delayed by ~20-30min. Reducing my connection time from 38min to IIRC ~8min and making me a bit anxious if I’d miss my connection. Then high speed train eventually was stuck as well, making the German passenger next to me pretty angry. He started talking in English, but really couldn’t be bothered by the delays. Nor by people sitting next to me (upon boarding I took the seat where someone placed a bag, I understand leaving your bags on a seat when train is empty, but afterwards you should be considerate IMO). Trains are entertaining. Regarding flights: read Schneier on Security, I don’t like the senseless rules that are only there to make someone feel good.
  • Though Strassbourg was great, not too many going out places. I wanted to dance, but wasn’t too much around.
  • Surprising amount of non-Europeans/non-USA people attending GUADEC.
  • Realized that I’m an old fart @ release team.
  • Someone was surprised everyone @ GNOME is so young. My first GUADEC is Stuttgart, 2005.
  • 200gr of cheap Supermarket chocolate for max 0.70 EUR. I bought loads of them :-D, though was limited by available space in backpack. Going to have a painful stomach for a couple of days.
  • Usual stuff about being really bad at linking names with faces, not recognizing people I met before. Not being able to connect people I emailed with with the names, etc. Forgetting the names of really cool people. All of this is very frustrating :-(
  • As expected, didn’t attend too many talks.
  • BoFs felt really useful. Didn’t always do whatever that the BoF was about
  • I prefer my company laptop over all the laptops that I saw :-P
  • Apologies that I used the opensuse usb stick to boot Mageia, but hey, it didn’t have an opensuse live image, so…
  • Not too many attendees IMO, wondering why. Late registration? Lack of Nokia? Less travel sponsorship? Thought maybe that we lack community members, but actually there is a impressive amount of “young blood” :-P.
  • Discovered I overlooked the Foundationship renewal email. It was unread in my inbox :-(
  • Didn’t like certain things @ AGM.
  • Couldn’t attend engagement BoF. Never time for the Engagement meetings/hackfests/etc. Still sort of feel like I’m part of it. It would be nice to share thoughts.
  • Met Andrea! Italian and tall.
  • Broke the glass in front of camera. Ordered a replacement, should be easy to fix. Wanted to share everything on Hangouts, now was unable :-(
  • Want to go to Prague :-D
  • Disappointingly easy to find a restaurant with a big group. I thought that it is a given that’ll always take ages to decide.

Pre commit hook for PO files on git.gnome.org

After a little pestering by André I’ve made the following changes regarding PO file checking on git.gnome.org:

  1. PO files are actually checked using msgfmt
  2. Added a simple check to ensure keyword header in .desktop is properly translated

That PO files weren’t checked for syntax issues was pretty surprising for me, it seems no translator ever uploaded a PO file with a wrong syntax, else I assume the sysadmin team would’ve received a bugreport/ticket.

The check for a properly translated keyword header is implemented using sed:

sed -rn '/^#: [^\n]+\.desktop/{:start /\nmsgstr/!{N;b start};/\nmsgid [^\n]+;"/{/\nmsgstr [^\n]+;"/!p}}'

Or in English: match from /^#: .*\.desktop/ until /\nmsgstr/. Then if there is a msgid ending with ";, check if there also is a msgstr ending with ;". If msgstr doesn’t end with ;" but all other conditions apply: print the buffer (so #: line up to msgstr). The git hook itself just looks if the output is empty or not.

Example of the error message.

$ git push
Counting objects: 23, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 313 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: ---
remote: The following translation (.po) file should ensure the translated content ends with a semicolon. (When updating branch 'master'.)
remote:
remote: po/sl.po
remote:
remote: The following part of the file fails to do this. Please correct the translation and try to push again.
remote:
remote: #: ../data/nautilus.desktop.in.in.h:3
remote: msgid "folder;manager;explore;disk;filesystem;"
remote: msgstr "mapa;upravljalnik;datoteke;raziskovalec;datotečni sistem;disk"
remote:
remote: After making fixes, modify your commit to include them, by doing:
remote:
remote: git add sl.po
remote: git commit --amend
remote:
remote: If you have any further problems or questions, please contact the GNOME Translation Project mailing list <gnome-i18n@gnome.org>. Thank you.
remote: ---
To ssh://git.gnome.org/git/nautilus
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'ssh://git.gnome.org/git/nautilus'

Note: explanation can probably be improved. The check is not just for Keywords, also for other things like e.g. mime types, etc.

On change management and display servers

There’s been a post, titled Why the display server doesn’t matter. It received a few responses:

Aaron and Martin are not saying anything that hasn’t been said before. What I find interesting is how the communication is happening. Martin is a well known developer and has spent a lot of effort on porting KDE to Wayland. Aaron communicates a lot :P Now I know various developers will hate “change management” courses and the theory, but one thing that is stressed during such courses is to acknowledge and understand what people affected by a change are saying.

Looking into the responses given by “Canonical” (in quotes because I’m not sure if every response was from a Canonical person) towards the various feedback given regarding the change (Mir as additional display server), one common theme is highlighted by the various responses: “it doesn’t matter”, “it is just a bug in the application”, “it is just a bug in the toolkit”, “the toolkit abstracted wrongly”, etc. Sometimes these answers are conflicting. Saying partly that the toolkit abstracts it, while also saying that currently the toolkit is lacking should indicate that there is a problem (at least in the communication).

Despite the pain caused by this change, there is no acknowledgement. Just a repeat of “it doesn’t matter”. As a result, the very people you need to make this change happen will feel ignored and being dismissed. You need these people, yet they’re being dismissed. What gives? It seems headed towards failure. Why not acknowledge and try to understand?

My thoughts on the default init system for Debian discussion

History

The Debian tech committee is deciding on the default init system for Debian. Personally I’m totally biased and think the only realistic choice is systemd. I loved Upstart when it was written, but actually I think the default init system is really of no concern at all.

What you get with systemd is something which strives to be “the basic building block for Linux” (just watch one of the presentations regarding systemd). All the other init systems either don’t want to do this, or actively strive to do as little as possible. As a consequence, loads of functionality offered by systemd is either only available with systemd, or the alternatives (Canonical logind) are striving to follow what systemd does. There could be lots of alternative implementations as various extra functionality is available through D-Bus interfaces. D-Bus means that the same functionality could be offered by something else.

Note that I read and follow loads of projects. Distribution wise I follow openSUSE, Gentoo, Debian, Mageia, Fedora and Ubuntu (last one minimally as development is not mailing list focused). Then obviously GNOME, systemd, freedesktop, KDE (very minimally), various websites, etc. I’ve noticed that not everyone reads as much as I do :-P

Relying on an init system

One item in the upcoming Tech Committe vote is the following two options

Tight coupling

Software may require a specific init system to be pid 1.

However, where feasible, software should interoperate with
all init systems; maintainers are encouraged to accept
technically sound patches to enable interoperation, even if it
results in degraded operation while running under the init system
the patch enables interoperation with.

Loose coupling

Software outside of an init system’s implementation may not require
a specific init system to be pid 1, although degraded operation is
tolerable.

Maintainers are encouraged to accept technically sound patches
to enable improved interoperation with various init systems.

What I don’t like

There are a bunch of things that I dislike about the current status. I think I’d do this totally differently. I like the following quote:

We work for the developer community, helping everyone to work together and make progress. We try not to get in the way.

Anyone who is working in a committee (release team/ctte/etc) has the ability to direct the project. And you’re seen and should be seen as someone who decides. The point is to serve the project and allow people to make progress. On any committee you should not decide, you’re just announcing a decision which was made by others. The same people who are asking you for a decision could be the ones who have actually made the decision. Though always ensure that everyone knows who’s in charge :-P

Lack of distinction of package importance for the distribution

Say you have a package which nobody depends on. Let’s take for example “GNOME Logs”. Nothing depends on it and it is a GUI for the journal (which comes with systemd). Meaning: it relies on a specific init system, and in this case systemd. With “loose coupling”, “GNOME Logs” would not be allowed because it only works with systemd. So I consider “loose coupling” bad. Or would “GNOME Logs” suddenly considered “part of an init system’s implementation”?.

Now consider a package which you need in the distribution. Loads of stuff depends on it and pretty much a requirement to have. With “tight coupling”, the package maintainer could just enable some systemd support, mention other support is not feasible and force the whole of Debian to whatever init system that package maintainer prefers. Allowing maintainers of low level packages to be able to change the Tech Committee decision seems bad. So I consider “tight coupling” bad.

There is a total lack of distinction between the importance of packages as well as the default init system. A low level package could just undo the Tech Committee decision with “tight coupling”. While at the same time, “loose coupling” is a bad option as well as a package which nobody depends on should be totally fine to rely on a specific init system.

Lack of importance for the default

Above choices have no relation to the default init system. Say the Debian GNOME maintainers make systemd a dependency. How is this bad if the default for Debian would be systemd? Say Tech Committe choses Upstart and Debian GNOME maintainers make systemd a dependency. Isn’t the default something that should be considered?

Both options actually encourage maintainers to ensure their packages work with multiple init systems. What if you don’t care? Accepting a patch one time is hugely different from having to maintain the patch.

Now aside from this, if I was maintaining some package that offered better support for whatever init system Debian will use by default, then I’d want to rely on it. Seems nothing wrong with this. It is the default after all.

Burden is placed with package maintainers

If “loose coupling” is chosen and your package doesn’t work with other init systems, then you’re expected to make it work. Say Debian goes for systemd and upstream removes support for anything other than systemd? Too bad, go and implement that support! Say “tight coupling” is chosen and someone offers a patch to make it work on a different init system. Lots of software now depends on this patch. Next upstream comes out and the patch has to be rewritten totally. Well, you’re the packager so good luck uploading the new version.

A one time patch is not maintenance free. The only difference to me between both options who writes the initial patch. Eventually the maintenance burden will be with the packager.

Multiple init system support is always a requirement

Both options demand multiple init system support. With “tight coupling”, packagers are still encouraged to accept patches from a different init system. The burden with “tight coupling” is just with the packagers of the other init system. With “loose coupling”, packagers are forced to ensure it works with multiple init systems.

To me it seems that either way, multiple init system is always a requirement. Just differs where the Tech Committee places the burden.

Doesn’t answer the current issues

To me it seems like the current voting options are not in line with why the question was sent to the ctte. I’ll give a few examples.

logind D-Bus API

GNOME really likes the logind D-Bus API, even if it isn’t a requirement (fallback is the unmaintained ConsoleKit). Now Canonical forked the logind daemon to offer an alternative provider for this API, this fork might be enhanced. At the moment that fork is NOT working in Debian. So can the Debian GNOME packagers or can’t these packagers have GNOME depend on logind and who should do the work?

A reminder on what “loose coupling” means:

Software outside of an init system’s implementation may not require a specific init system to be pid 1

With “loose coupling”, you could argue that an alternative exists, have logind provide a fake package such as “logind-dbus-api” and be done with it. Up to others to package the alternative. Then you can just rely on “logind-dbus-api” and you’re not requiring one init system, though in practice you are, or maybe you are not :-P.

“Loose coupling” seems the option that most of the Upstart supporters will be voting for. Can GNOME require logind API or not? There are alternative implementations. The Canonical fork will likely work with Upstart. But what about other init systems? If those alternative implementations aren’t available or working under all of the init systems, then you might end up requiring a few. Is this bad or not? Or is “a specific init” bad if you want one, but ok if at least two are supported?

I notified the GNOME distributors about this freedesktop.org change back in January 2012 (started with ConsoleKit deprecation, I already wrote multiple blogposts about ConsoleKit and logind explaing this in great detail).

UPower 1.0

For UPower 1.0, some functionality is removed and instead you’re expected to rely on systemd (or anything similar, in practice there is nothing else AFAIK) as that already had the functionality UPower was offering before. This functionality will be gone. With “tight coupling”, that’ll force systemd slowly in more and more things as whatever relied on UPower, now also should have systemd as a dependency. With “loose coupling”, I guess loads of patches in the packages making use of UPower 1.0 to duplicate the functionality UPower 1.0 offered before? Or maybe change UPower 1.0 and make the API different between Debian and non-Debian? It all doesn’t really make sense to me.

I notified the GNOME distributors about this freedesktop.org change back in October 2013.

Glosses over the ability to provide alternative implementations

Say a package requires a D-Bus API provided by systemd, but it could be reimplemented by something else? I fail to see how that is a bad dependency to have. What matters is the interface is implementable by something else. If the API is stable or not. These things should be taken into consideration IMO. It seems to not have been considered at all.

I think it is much better to quality in what way dependencies are allowed. A dependency that currently is tied to a specific init system, while it doesn’t have to be, seems like a totally ok dependency to have. If it is important then someone will eventually do the work. If not, it wasn’t important enough.

CTTE seem to have skipped opportunities for a more thorough analysis

In the whole discussion, I never saw anyone from ctte mention that Debian/Hurd doesn’t make use of sysvinit. I have the strong suspicion that nobody from the Tech Committee went out to ask the porters for their ideas. Then again for the various package maintainers. There was a call, some people who maintain a wiki page, that is it. The problems which resulted in this issue to be raised to the Tech Committee: I don’t think any of the current voting options is going to give satisfactory answer.

Same for checking other distributions. Even Gentoo allows packagers to depend on specific init systems.

Lack of importance of impact on QA

Loads of distributions have switched to systemd. Especially the distributions with a lot of people behind them (paid or not). Now even Gentoo is ok with a systemd dependency. On Gentoo the packagers added a systemd dependency since a few months ago. I know that on Mageia the period where we tried to support multiple init systems had a bad impact on QA. Mageia got way more stable after we switched to systemd only instead of trying to support multiple. There was also a period where Gentoo provided a lot of fixes to GNOME to solve the various bugs GNOME had with trying to support both. But since then loads of code has been moved around. Debian is going to be facing such bugs for the first time with almost nobody to help them out.

Now obviously Debian has loads of volunteers so given enough time and effort everything gets fixed. But it seems pretty much a given that there is a huge extra burden that will be specific to just Debian. The impact on QA (and thus your release schedule) seems like something you should consciously consider.

Consideration to meritocracy

Mageia switched to systemd because everyone who works on the low level bits wanted it that way and they made it happen. To me it always seems good to give consideration to what the people who do the most work in the affected area think. I have no idea though what the ideas are amongst them in Debian.

Guaranteed to be followed up by a GR

I’m pretty sure this will result in another vote, but then open for all of the Debian developers. I don’t like “gut feeling”, I prefer meritocracy. I think it’ll be decided by the gut feeling Debian developers have.

Basic building block vs nothing

To me, the Tech Committee voting is inadequate and misguided. One of the choices strives to be a basic building block. There are interfaces with stability guarantees, but other init systems would just be followers. Further, as systemd strives to be a basic building block, various other projects have or are going to rely on the offered functionality.

Theoretically such functionality can be offered by another init system. Which I like. But currently the Tech Committee seems to have the opinion it is just an init system discussion. This seems an awfully simplistic assumption.

Debian/Hurd and Debian/FreeBSD

Already various differences

Various people really care about Debian/Hurd and Debian/FreeBSD. I find it terribly odd that various people think that there is a requirement that every software should be available under every port. This in direct contrast with the current situation. Debian/Hurd does NOT use sysvinit. According to a porter, sysvinit is not portable. For Debian/Hurd a few hacks had to be added to work around assumptions. On both ports it relies on Linux compatibility layers.

I don’t really understand the purpose of Debian/Hurd and Debian/FreeBSD. By some people, it seems that every current Debian package works under those ports. No matter how low level that package is, it MUST be portable. By some others, FreeBSD offers ZFS and using that on your server in combination with having “apt” is great.

To me it seems terribly odd to have the assumption that everything should be the same while it isn’t at the moment.

Already GNOME barely works on the ports

Another huge problem seems to be that the GNOME packagers want to rely on systemd. This would exclude GNOME from Debian/Hurd and Debian/FreeBSD. However, most GNOME packages already do NOT work on any of the ports. That GNOME works on the real FreeBSD doesn’t mean it automatically is in great shape on Debian/FreeBSD! So there is no practical change, though now people notice the actual situation. I guess it is easier to just assume Debian/Hurd and Debian/FreeBSD are at a good level and a “default system init” has a noticeable impact. It does not. The Debian GNOME packagers wanting to add a dependency is of similar unimportance.

Conclusion

None, I’m just following with interest.

On being political

From a blog from Mark Shuttleworth:

Mir is really important work. When lots of competitors attack a project on purely political grounds, you have to wonder what THEIR agenda is.

From upstart vs systemd article for the Debian tech committee by the Upstart maintainer and Debian tech committee member:

SystemD is “greedy”. Most of the recent arguments about why it’s dangerous to adopt upstart instead of systemd center around features that are being built into systemd in a manner that can’t be separated out (e.g., cgroup management in PID 1). There is an advantage to the implementor to put these features in-process in init, because it ensures early availability with no concerns about startup ordering at boot, but it commits downstreams to a monolithic design with respect to parts of the system architecture which are not settled questions in the wider ecosystem. Debian should take a principled position regarding its future architecture, and not find itself at the mercy of other parties who wish to dictate design to us.

Nothing political to see, move along people! :P Amazing how lack of features in one project is turned into “principled stance” against the other.

Wayland vs /usr/share/xsessions

Past

A long time very display manager had its own way of determining the various sessions. Eventually this was standardized via freedesktop.org using /usr/share/xsessions. Display managers can figure out the various sessions using .desktop files in previous mentioned directory.

Present

With Wayland coming along, you want to perhaps know which of those sessions should run under Wayland, which under X. A specific header was added to the gnome-wayland session file, X-GDM-NeedsVT=true.

Adding a new header is problematic. Adding this means breaking compatibility. But maybe we’ll just ignore any compatibility problems. Before worrying about this, I noticed that in Mageia /usr/share/xsessions is auto-generated. Any file you place there will be overwritten on reboot! Meaning, no such header will appear in Mageia. No GNOME Wayland.

I asked around why these things are still being overwritten. Apparently in the past we used to have some other method which on Mageia is converted into /usr/share/xsessions. Anyway, clearly legacy and time to get rid of this. I quickly looked into what Debian does. They go from xsessions to the old way of doing things, still. Debian being Debian.

Imagine my surprise in discovering that we cannot just kill this code. XDM (fallback display manager on Mageia) only supports that old way! So even though it has been 10+ years (in my mind at least), we continue to live on with two ways of doing this. Plus in bits that we cannot just ignore.

Basic functionality

Showing sessions seems rather basic functionality, solved ages ago. Anyone would expect display sessions to show up in every display manager you might install. Reality is a mess. There is choice in display managers, but there is a lot of complexity in supporting this. The way of doing that is different per distribution. Although we have Linux Plumbers conferences and freedesktop.org (which is not specific to Linux), this never was simplified.

Simplifying

Why to simplify code? For that I rather point to something known to developers, meaning code refactoring. In general, simplifying is usually done to ease either maintenance and/or make it extensible. A clear example is above, there are outright bugs in various distributions triggered by this. The maintenance of this is higher than it should be. And this for something really basic, ensuring that the sessions are the same no matter which display manager you use.

Another way of thinking: The CEO of a very large non-technical company sometimes talks about technical legacy and the need to simplify. Isn’t it time to acknowledge this in free software? Pretty safe to assume that the free software community is way more technical than this CEO or an average person in that company.

Another layer of abstraction

Now in my previous blogpost I talked about logind and systemd. An argument raised there is that “power management” is something anyone should be able to expect in 2013. This seems overly similar to the expectation that every session shows up in any display manager.

To solve this, let’s not continue in having abstraction layers around for another 10+ years for something as basic as power management. The different solutions should define one API and stick with it, whatever that is. Let’s not push such complexity into desktop environments. That would lead to similar differences as the session support in Debian vs Mageia. Want to offer choice in power management or another display manager? Go for it! Using one API (/usr/share/xsessions rings a bell :P). Not loads. Not anything which requires an abstraction layer. How to get there? Who cares! Talk about it on Linux Plumbers conferences, freedesktop.org, by email, by implementing the same API as systemd or whatever you think is best. But let’s not pretend to go for choice while going for complexity.

It’s 2013, let’s fix things in the right place!

Wayland vs /usr/share/xsessions?

For those who are wondering about the original topic of this blogpost, this is how things were solved: Wayland specific sessions are placed in /usr/share/wayland-sessions. This avoids breaking compatibility in non-GDM display managers and avoids breakage in Mageia. The right thing to do because breaking display managers is bad. That said, having and expecting all display managers to support /usr/share/xsessions properly is long overdue.

GNOME and logind+systemd thoughts

Distributions usage

At most 3 weeks ago I noticed by then already month old thread on gentoo-dev discussing that GNOME 3.8 has a dependency on systemd. At most this should be about logind, even though logind is optional. The assertion of Gentoo is different than what we communicated. For one, in the last stages of GNOME 3.8.0 as release team we specifically approved some patches to allow Canonical to run logind without systemd. Secondly, the last official statement still stands, No hard compile time dep on systemd for “basic functionality”. This is a bit vague but think of session tracking as basic functionality.

Figuring out why Gentoo really believes systemd is a requirement took a while to figure out. For one, gentoo-dev is unfortunately like a lot of mailing lists. Loads and loads of noise. Out of the 190+ messages, only one or two has a pointer to some more information. One was Bugzilla, another was that logind now requires systemd. Apparently our (=GNOME) assumption that logind was independent from systemd changed since systemd v205 due to the cgroups kernel change. This is really unfortunate, but GNOME 3.8 does not require logind. I discussed the non-dependency of logind+systemd on #gentoo-desktop and why they thought different. Apparently GDM 3.8 assumes that an init system will also clean up any processes it started. This is what systemd does, but OpenRC didn’t support that. Which means that GDM under OpenRC would leave lingering processes around, making it impossible to restart/shutdown GDM properly. The Gentoo GNOME packagers had to add this ability to OpenRC themselves. Then there were various other small little bugs, details which I already forgot and cannot be bothered to read the IRC logs. :P

Due to 1) logind now requiring systemd, 2) that they don’t have time to develop missing functionality in OpenRC 3) supporting non-systemd + systemd at the same time likely resulting in bugs and a lot of support time, they decided it is much easier to just require systemd/logind. This also get the features that systemd and logind offer and avoid any weird bugs (as most GNOME developers seem to use systemd).

Debian GNOME packagers are planning the same AFAIK; they rather just rely on systemd (as init system, not just some dependencies). In the end, the number of distributions not having systemd decreases. This despite clarifying that GNOME really does not need systemd, nor logind and trying to help out with issues (though GNOME is not going to maintain distribution specific choices).

Wayland

GNOME 3.10 has Wayland as technological preview. The Wayland support in Mutter is being tracked in a special branch and tarballs are released as mutter-wayland. The Wayland support in GNOME will rely on logind to function (to be clear: Wayland in GNOME, not Wayland in general). If you have read my entire blog, you’ll notice that though we knew about logind runing on Ubuntu, as of version 205, logind is now tied together to systemd.

GNOME session

For GNOME 3.12, a feature has been proposed called systemd for the user session. This feature is explained as follows:

When booted on systemd systems, we can use systemd to also manage parts of the user session. There are a number of benefits to this, but the primary one is to place each application in its own kernel cgroup. This allows gnome-shell to do application matching more reliably, and one can use resource controls to (for example) say Epiphany only gets 20% of system RAM.

Furthermore, this lays some fundamental groundwork for application sandboxing.

It’s important to note that with these patches, we still support non-systemd systems (as well as older systemd). How far into the future we do so is an open question, but it should not be too difficult to leave non-systemd systems with the previous model over the next few cycles.

Upstart has something similar, called Session Init. I am not sure if what Upstart does is the same as systemd, just that they seem the same. In Ubuntu/Unity this is already used (though not sure to what extend), reasoning is described here (recommend to read it).

Making use of systemd in short term just provides some benefits and allows us to eventually support application sandboxing. However, long term hopefully gnome-session can die and such code in systemd. There it could possibly be reused by other desktop environments (only aware of Enlightenment).

ConsoleKit

We’ve been relying on ConsoleKit for a long time. If you see the git history, you’ll note that it was first written by a GNOME developer and my impression is that he wrote the majority of the code. Since preferring logind, ConsoleKit development has as good as completely stopped. No development in 1.5 years.

Upstream vs downstream

I remember the days where we had a program which tried to change some “OS” settings. E.g. maybe the timezone. IIRC this was handled using a Perl backend which would try and determine the OS/distribution and then would do whatever it needed to do. A complication was that things might change between the version of the OS/distribution, so the version also needed to be tracked. As a result, this program would sometimes ask you if your distribution was the same or similar to one of the distributions it knew about.

Only since very recently, we rely on fancy new things like dbus and the dbus specification described at http://www.freedesktop.org/wiki/Software/systemd/timedated/. Since the GNOME 1.x days, we’ve gone from trying to support all the differences out there, to promoting standardization (across desktop environments as well as OS/distributions). And in some cases like this timedated dbus specification, we either provide a function or it won’t work. It will be up to a distribution/OS to ensure that the function is available.

Future

Personally speaking, it seems that there is little going on to change the direction in which GNOME is heading. GNOME is getting rid of more and more code which overlaps with other code. Fallback mode, ConsoleKit, power management vs systemd handling this, etc. Then for new functionality, GNOME is also relying on new things. Think of Wayland, timedated, localed, application sandboxing, etc.

At the same time, I don’t see people working on ConsoleKit. Or ensuring that either there is a replacement for logind or ability to run logind without systemd. Development of any init system other than Upstart (user session is cool) seems low and in need of extra help.

Having GNOME run on non-Linux based operating systems (*BSD) and distributions not willing to switch for whatever reason to systemd is great. But it seems distributions rather depend GNOME on systemd than maintain things themselves. Leaving out *BSD, GNU/Hurd and Ubuntu. :(