Log in

28 December 2008 @ 11:12 am
The session non-manager  

For various reasons (which in the end boil down to lack of manpower), we are quite late in the process of packaging GNOME 2.24. (This is almost finished now, I’ll keep you informed.) Which is why I may sound coming a bit late on noticing this one, but I was really speechless.

The problem: session management has flaws

Currently, a session manager uses XSMP (the X Session Management Protocol) to talk to applications. What it means is that for applications supporting this protocol, it is able to do more than simply starting and killing them: it will also remember their state, and offer them a way to shut down gracefully. However, XSMP is really a shitty protocol – I won’t explain why here, you will find tons of better explanations on the intarweb.

The gnome-session developers, being quite aware of this issue, did what anyone interested enough would have done: they designed a new protocol, based on D-Bus, and implemented it. The new protocol is not considered stable yet, but it is simple, efficient and above all, reliable – that’s a giant leap forward. For this reason, I was very excited to see what gnome-session 2.24 would look like, since it brings major cleanups in the code.

The solution: remove session management!

When I first started it, it did not restore my saved session. I simply supposed that the format of the saved session had changed, and that writing a conversion tool would be in order. Wrong. Let’s bring the session preferences:

The UI of this dialog hasn’t changed since 2.22. However, I do not resist the urge to show you the code behind the “Remember Currently Running Applications” button:

static void
on_save_session_clicked (GtkWidget           *widget,
                         GsmPropertiesDialog *dialog)
        g_debug ("Session saving is not implemented yet!");
As for the check box on top of it, it sets a GConf value that is never read anywhere.

If you know the long term plans for GNOME, it makes sense: when gnome-shell replaces the panel and the window manager, it will also be responsible for starting the visible applications, while gnome-session will deal with what’s happening behind the scenes. But gnome-shell is still far from ready, and you need something in the meantime for the basic requirements of a session manager!

Backwards compawhat?

The surprises don’t stop here. I also noticed that logout was much faster – instantaneous instead of the usual 2-3 seconds. The reason why logging out is this long currently is not because it takes long to kill applications; it’s because the session manager kindly requests applications supporting XSMP to shut down before killing them. If a document isn’t saved, an application will be able to prevent the logout process. Guess what? Now gnome-session completely ignores XSMP applications. Since it doesn’t need them to register for saving the session, it also saves the time to ask them to close cleanly.

The result is that you will see a lot of such dialogs:

It’s very nice to replace a flawed protocol ; and really, the new protocol goes in the correct direction. But let’s be realistic, it’s impossible to immediately port hundreds of applications to a new protocol without having a transition time during which both protocols are supported. You also need to consider your protocol as stable before asking other developers to port their applications. And to get it accepted, you need to standardize it; freedesktop.org would have been the correct body. (Currently, the protocol lies in the org.gnome namespace, not org.freedesktop.)

Release management at its best

Wait… aren’t there some distributions out there which already released stable versions with GNOME 2.24? The answer is yes. At least Ubuntu Intrepid and Fedora Core 10 ship with a session manager that:

  • is unable to restore applications;
  • kills applications without letting you save your work.

It’s good to see such improvements on the session manager coming, and I’m really thankful to the gnome-session developers to work on it. What I wonder is:

  • How could it slip into a stable GNOME release?
  • How could two major distributions let it slip into a so-called stable release?
It definitely looks like we’re not the only ones who could improve our release management processes.

So what?

This is a very good example of a lack of “big picture” thinking. On one side, there is a brilliant design and its good implementation. On the other side, two major regressions from the user’s point of view – the kind of regressions that make people fly away.

If there’s one thing that I’ve learned from working in IT, it’s that you must often keep your brilliant designs as long-term goals. In the short term, you will run a bastardized version of your brilliant design that will make you cry; but it will work. When you need to talk to shitty applications or with shitty protocols, you need to write shitty code.

trs80 [typekey.com] on December 28th, 2008 11:00 am (UTC)
Yeah, I saw this clusterfuck and am quite happy Lenny avoided it. BTW OpenSolaris 2008.11 also shipped with 2.24.
ext_98186 on December 28th, 2008 01:09 pm (UTC)
perfect example of unregulated time-based releases
GNOME release management has done fuck-ups like this a few times already, like releasing 'stable' GIO-powered Nautilus with serious regressions, just to be on time. Same like Ubuntu with a shitty 8.04 (immature PulseAudio) and 8.10 (buggy NetworkManager), just to be on time.
(Anonymous) on December 28th, 2008 11:04 pm (UTC)
Re: perfect example of unregulated time-based releases
Well they are just imitating the proprietary software world. Ship by a given date, damn the quality.
(Anonymous) on March 14th, 2009 06:52 pm (UTC)
Re: perfect example of unregulated time-based releases
The difference is that the proprietary software folks don't turn off deprecated features until the new ones are ready. It's not a matter of scheduling, it's a matter of following the correct procedure for deprecating old code.
ext_49859 on March 14th, 2009 08:19 pm (UTC)
Re: perfect example of unregulated time-based releases
The problem with PulseAudio in 8.04 was the configuration, not the version. It was set to take an exclusive lock on the ALSA device, which means non-PA-enabled apps could be blocked or could block it. It should have gone through dmix.
np237np237 on March 14th, 2009 08:26 pm (UTC)
Re: perfect example of unregulated time-based releases
Making a software mixer (PA) go through another software mixer (dmix) is a very, very bad idea. Especially with PulseAudio given the assumptions it makes to allow for “gapless” (aka screw my ears) playback.
(Anonymous) on March 14th, 2009 10:31 pm (UTC)
Re: perfect example of unregulated time-based releases
I completely disagree, as a user and as a developer.

As a user, I want flexibility. Not allowing me to run ALSA stuff because of PulseAudio or some other crap wants to lock it down makes it unusable.

From a developer standpoint, these types of locks are horrible as well. They limit sound to only using PulseAudio or nothing.

So yes, having mixer on top of a mixer is not a good idea, but it is a better idea than no sound.
(Anonymous) on December 29th, 2008 12:45 am (UTC)
GNOME-2.24 problems in Gentoo as well
Having the same trouble for Gentoo Linux GNOME packaging as well. Major delays to keep the complete experience of GNOME-2.24 working right with gnome-session being kept at version 2.22 and gdm being kept at 2.20 due to the huge core features being removed in the 2.24 versions. Necessary patches for gnome-panel, gnome-session, consolekit and so on, as far as I recall. You might be interested in some of them - we also restored translations for all languages to 2.22 level for some code patch for gnome-panel-2.24 to keep things working with gnome-session-2.22 and gdm-2.20.
Additionally gnome-terminal-2.24 lost "switch to tab n" configurability in the UI (then restored in gconf, then removed even there again) - for that we have full patches, including translations as well.
All in all, things have been pretty delayed for GNOME-2.24 packages getting marked "stable" in our way of doing experimental/testing/stable due to having to have concentrated long amounts of time to forward port stuff, restore translations, test things, and so on. On top of that some of us allocate more free time to do GNOME packaging for a community driven distribution to match GNOME release times - if there are so many problems, things get delayed even more if we don't manage to tackle show-stopper things completely during the time we have planned for more free time for such work due to so many issues.

You can contact gnome at gentoo dot org if interested in details on the patches we apply to get the full experience work right with older gnome-session (a la, logout/shutdown dialogs actually working with gnome-panel-2.24) - can't look them up immediately. If you do, the reply is likely to go to distributor-list of gnome as well, of course. Also perhaps Debian is doing something additional we'd like to reuse

Mart Raudsepp
Member of Gentoo Linux GNOME team
np237np237 on December 29th, 2008 05:33 pm (UTC)
Re: GNOME-2.24 problems in Gentoo as well
Thanks for confirming my impressions. Anyway, I am not going to upload gnome-session 2.24 anytime soon, even in experimental. I have patched gnome-panel to bring back the old logout dialog, on top of which we build gnome-panel-logout for other uses.

I wonder why patches are necessary for gnome-session and consolekit, though. If you have a pointer, that would be appreciated.

In all cases, you can have a look at the patches we are applying (there are quite a lot) at http://patch-tracking.debian.net/email/pkg-gnome-maintainers@lists.alioth.debian.org
(Anonymous) on December 29th, 2008 06:21 pm (UTC)
Re: GNOME-2.24 problems in Gentoo as well
http://bugzilla.gnome.org/show_bug.cgi?id=552387#c52 mentions a link to one of our mirror servers in the mirroring system where the patch we use for gnome-panel-2.24 compatibility with gnome-session-2.22 can be retrieved from.
It doesn't outright revert the changes, but adds back support for gnome-session-2.22. That means that when someone decides that she doesn't need the session saving features and upgrades to gnome-session-2.24, logout is still going to work as gnome-panel can work with either gnome-session versions. That way in Gentoo we can provide a package for gnome-session-2.24, that is package.mask'ed (knowledgeable users can explicitly "unmask" it to get it, and while doing so can read the reason this is masked - lack of session saving) and if installed won't break logout due to gnome-panel not supporting D-Bus based way of doing this. So there's a fallback to the old way if the D-Bus interfaces don't exist or something along those lines. So you might want that version to not worry about having to upgrade both gnome-session and gnome-panel at once, when gnome-session latest stable releases finally regain session saving support.
The patch(set) also has fully forward ported translations for the dialog, so that there is no out of place english standard logout dialog on an otherwise fully localized desktop. That would certainly be useful for Debian.

I believe the ConsoleKit and gnome-session patches were to keep the non-PolicyKit code paths to work. We currently don't fully integrate PolicyKit and in the future when we do, we are going to keep that with an opt-out possibility via our USE flags mechanism for as long as reasonably possible. So if you guys fully use PolicyKit, then those bugs our patches fix are not triggered.

https://bugzilla.gnome.org/show_bug.cgi?id=562834 has my patches for bringing "Switch to tab " configurability support back (many users rely on that, especially irssi users), again including full translations (gconf schemas and keyboard shortcuts dialog) in a secondary patch.

-- Mart Raudsepp
(Anonymous) on December 29th, 2008 07:38 am (UTC)
Thank goodness for Debian. Thanks again Joss.
(Anonymous) on March 14th, 2009 07:22 pm (UTC)
"Thank goodness for Debian."
Yeah man. Staying with 2.22 for another two years for the win.
(Anonymous) on March 15th, 2009 01:08 am (UTC)
Yeah, thank goodness for Debian...
Without their mad security skillz, I would not have been cleaning up broken SSH/SSL keys all summer. The issue is that OSS developers, especially those working on core tech, need to grow up. People, like me, rely your code to make a living and to have a high quality of life on our personal machines. Stop developing like caffeine-driven teenagers. There a real-world consequences to your actions.
Justin Duggerjldugger on December 29th, 2008 10:09 am (UTC)
Isn't session management mainly a workaround for a lack of hibernation and suspend? Obviously the lack of shutdown notification is huge. It's a pain in the ass when Liferea doesn't get a chance to mark read/unread state.

Time based releases are not a magic bullet for software. The purpose is to put code in the hands of users, on the theory that even though some software is worse off, the system as a whole will improve in value. Every moment you delay, more software is outdated and users have more reason to go out of the distro for updates. Worse, everyone has different values. A laptop user may not particularly care if session management works as long as NetworkManager stops asking for a keyring password to connect to WiFi; a server certainly doesn't care about either of those.

My question to you is, how does the presence of bugs disqualify a release as "stable"?
(Anonymous) on December 29th, 2008 12:24 pm (UTC)
This isn't a presence of a bug. This is a major feature regression of a core feature of the package in question from one stable series to the next, without any prominent warning.

And session saving is not a workaround for suspend/hibernation problems. Try telling a thin client admin that you want to stay logged in 24/7 to "suspend" your session state.

-- Mart Raudsepp
(Anonymous) on March 14th, 2009 08:46 pm (UTC)
You face is scary!
ext_140362 on December 29th, 2008 03:16 pm (UTC)
Another example of why Ubuntu's time-based releases are not working. Intrepid is the worst Ubuntu release I've seen, and the cause seems to be a rigid adherence to releasing on a certain date instead of releasing a stable system with stable features and no bugs.
np237np237 on December 29th, 2008 05:36 pm (UTC)
I don’t think the problem is inherent to time-based releases. However, the tighter is the schedule, the more careful you need to be. Especially, you need to track very early which such important problems are unfixed and to have backup plans for each of them.
(Anonymous) on March 14th, 2009 07:33 pm (UTC)
I'm not entirely unhappy about this issue.
While I did spend a lot of time unhappy at Intrepid because I had to manually bring up my 30 different windows on 7 workspaces, until I then found that Fedora had the same issue... I also did end up switching back to KDE, which I had abandoned when Fedora shipped version 4 and it was unusable. KDE will save and restore most of my session (the notable exception is, oddly enough, konversation).

So, Gnome isn't the only one to screw up like this, KDE also recently had a pretty bad release. The nice thing is that they weren't both unusable at the same time. :-)

(Anonymous) on March 14th, 2009 08:52 pm (UTC)
So what?
This is normal for software development. KDE just went thru this for KDE4.
The answer is: if you don't want to ride the bleeding edge, stick with older versions (think LTS). What's the fuss about? Do people really think that great software springs up fully-formed? It takes work and time-that's why it's called development.
np237np237 on March 14th, 2009 09:30 pm (UTC)
Re: So what?
Bwahaha LTS. Let’s look back at what they shipped: a complete GNOME 2.22 desktop, with a half-working Nautilus. Good job.

No, if you don’t want to ride the bleeding edge, stick with distributions that check whether applications actually work before making a release. Think Debian or Gentoo.
(Anonymous) on March 28th, 2009 01:58 am (UTC)
Re: So what?
So which Gnome release is stable... every one of the recent ones has had major problems. So do distributions need to stop using Gnome releases altogether and just do their own release management because official Gnome can't manage to do it properly? Or do you mean we should all still be using Gnome 2.18 or 2.20 from several years ago before the brain damage set in with Gnome's release manament?
np237np237 on March 28th, 2009 02:09 pm (UTC)
Re: So what?
Troubles with GNOME release management did not start today. GNOME 2.16, for example, was a terrible release because GTK+ 2.10 was not stable enough.
(Anonymous) on March 29th, 2009 10:29 pm (UTC)
Re: So what?
So perhaps the solution is for distributions to stand together and drop Gnome altogether until Gnome can figure out how to do proper release management for their "STABLE" releases. Just keeping with the status quo of one crappy stable release after another of Gnome without making them realize the pain they are inflicting on everyone downstream of them doesn't seem to be working well.
np237np237 on March 30th, 2009 08:41 am (UTC)
Re: So what?
I don’t see what problem you are trying to fix with your “solution”, but I fail to see how it would fix anything.
(Anonymous) on April 25th, 2009 03:10 pm (UTC)
Thanks for pointing out session manager is broken on 2.24
Thanks for this insight. I was searching for a week now how to get 'gdesklets stop' working on logout. I guess I will have to wait for 2.26, and not thinking about implementing it myself....
(Anonymous) on June 3rd, 2009 09:11 am (UTC)
Re: Thanks for pointing out session manager is broken on 2.24
unfortunately, too late for me. I'm stuck with openSUSE 11.1 which has 2.24. Screwed! Anyway, I'm installing 2.26 right now. I hope that's fixed.
np237np237 on June 3rd, 2009 02:52 pm (UTC)
Re: Thanks for pointing out session manager is broken on 2.24
There are still some things missing in 2.26, but we have patches in Debian to add the missing functionality.
(Deleted comment)
np237np237 on September 21st, 2009 12:24 pm (UTC)
Most of these issues are fixed, but some of the fixes are still Debian-specific and have not been integrated upstream as of 2.28.0.
(Anonymous) on August 3rd, 2011 04:44 pm (UTC)
Why do GNOME developers need to rewrite session management with D-Bus? Why wouldn't update XSMP specification? All legacy applications will work, new applications will use the new features. Why the developers everytime choose the hard way?