|
|
Subscribe / Log in / New account

Ibex design: user switching, presence and session termination (Here Be Dragons)

Mark Shuttleworth discusses recent work done on Ubuntu 8.10. "With Intrepid on track to hit the wires today I thought I’d blog a little on the process we followed in designing the new user switcher, presence manager and session management experience, and lessons learned along the way. Ted has been blogging about the work he did, and it’s been mentioned in a couple of different forums (briefly earning the memorable title “the new hotness”), but since it’s one of the first pieces of work to go through the user experience design process within Canonical I thought it would be interesting to write it up."

to post comments

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 30, 2008 23:20 UTC (Thu) by jwb (guest, #15467) [Link] (10 responses)

I have some disturbing news about Ubuntu's "new hotness":
$ ps -fe | grep console
root      8101     1  4 Oct20 ?        09:49:44 /usr/sbin/console-kit-daemon
$ uptime
 16:16:37 up 10 days,  4:48,  2 users,  load average: 0.22, 0.36, 0.51
$ dc
2k
9 60 * 49 + 10 24 * 60 * 4 60 * 48 + + / p
.04
Verdict: console-kit-daemon, the underpinnings of the "new hotness" consumes 4% of my CPU, all the time, every hour, every day of the week, even though I'm the only person who uses the computer. And I can't remove it, because 95% of the Ubuntu desktop packages depend on the consolekit package.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 0:18 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

You can stop *running* ck-daemon without removing the package, you know.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 0:31 UTC (Fri) by jwb (guest, #15467) [Link] (1 responses)

Then why does everything depend on it?

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 7:50 UTC (Fri) by nix (subscriber, #2304) [Link]

Everything depends on the package which includes the *library*. It doesn't
depend on the *daemon* running, although if it's not running you won't
actually get any console-switching goodness (or CPU-chewing goodness,
sigh).

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 1:59 UTC (Fri) by ringerc (subscriber, #3071) [Link] (3 responses)

That would be true if the field reading "09:49:44" in the `ps -ef' output you quoted meant time on CPU.

It does not. It's the wall clock time for process creation. Most likely, your machine was last booted at around 9:44am and 44 seconds.

craig@ayaki:~$ ps -fe | head
UID PID PPID C STIME TTY TIME CMD
craig@ayaki:~$ ps -fe | grep console-kit
root 9119 1 0 10:13 ? 00:00:00 /usr/sbin/console-kit-daemon

Yes, my machine was booted at around 10:13am.

According to `man ps' the percentage CPU consumed by a process over its lifetime can be obtained with the "%cpu" format specifier. So:

craig@ayaki:~$ ps -eo pid,user,%cpu,cmd | grep console
9119 root 0.0 /usr/sbin/console-kit-daemon

Hmm, so less than 0.1 % .

In fact, watching `top -d 0.2' I barely ever see console-kit-daemon appear at all, since it spends the vast majority of its time sleeping (as it well should). powertop doesn't show it as a significant or even detectable source of wakeups, either.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 2:09 UTC (Fri) by jwb (guest, #15467) [Link] (2 responses)

Thank you for that completely incorrect explanation of how ps -fe works. Please read the manual again.

The start time is October 20, as listed. The total CPU time used is 9h49m44s, also as listed.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 8:07 UTC (Fri) by ringerc (subscriber, #3071) [Link]

Er ... ENOCOFFEE?

Sorry, that was spectacularly dumb.

The fact that I'm not seeing measurable times on console-kit-daemon on any of the systems (long-uptime desktops, a terminal server, and my laptop) does make me wonder if there's something specific to your machine or configuration going on, though. Have you had a look at what it's doing with strace or hooked gdb up to it?

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 13:12 UTC (Fri) by sbergman27 (guest, #10767) [Link]

It shows 5 seconds of cpu time in 17 hours of operation on my desktop box. Attach to it with strace, find out what it's doing, and file a report. You could have done that with less effort than you have expended complaining about it here.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 3:04 UTC (Fri) by spiv (guest, #9031) [Link]

It's only consumed 8 seconds over 3 days of uptime on my laptop. So that doesn't sound like you're experiencing normal behaviour. That's obviously not much consolation to you as you don't have my laptop...

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 11:54 UTC (Fri) by Frej (guest, #4165) [Link]

I might be a bug in console-kit-daemon, it might be bug in some other software excessively querying ck-deamon.... (ipc yay!)

Just don't use top as a blame tool.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 6, 2008 8:40 UTC (Thu) by ekj (guest, #1524) [Link]

Not normal behaviour. Find out what it's doing and file a bug. I've got 13 seconds of cpu-time in 17 days of uptime.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 7:45 UTC (Fri) by AlexHudson (guest, #41828) [Link] (18 responses)

It's a relatively nice applet, but it's a shame to see another piece of code which isn't going to make it upstream (because the FUSA system is undergoing redesign).

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 8:37 UTC (Fri) by dholbach (guest, #53300) [Link] (9 responses)

From http://www.markshuttleworth.com/archives/233

"The FUSA applet itself is going through a bit of a transformation upstream as it’s been merged into the new GDM codebase and the old code - on which our work is based - is more or less EOL’d. But we’ll figure out how to update this work for Jaunty and hopefully it will be easier to get it upstreamed at that point."

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 9:50 UTC (Fri) by AlexHudson (guest, #41828) [Link] (8 responses)

Which is pretty much what I said.... this code is based on a dead end, and is going to have to be re-worked to even be considered by upstream.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 17:31 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (6 responses)

I'm willing to give Shuttleworth and Ted the benefit of the doubt on this one. Mocking up code with an older codebase, isn't necessarily inappropriate. I see people doing mockups all the time, to test out ideas.

What's debatable is whether its worthwhile to go ahead and distribute that mock up to users as an application in a distribution, especially when you know upstream developers are actively working on new bits which are diverging away from your mockup code.

I really hope Ted is involved with ongoing upstream discussions, well before the Jaunty timeline that Shuttleworth eludes to. Either on the gnome usability lists or the desktop-devel-list where redesign of the panel usability is currently an active thread.

Shuttleworth's comments about not having have thought through packaging and integration speaks volumes. If Canonical's expertise is really integration as Shuttleworth as previously stated..why was that the part they had the most trouble with?

http://www.markshuttleworth.com/archives/162
"We focus most of our effort on integration"

Canonical still doesn't understand the benefits of getting new things upstreamed to lower the maintenance and integration costs. It's a lesson they need to learn or they are going to find it harder and harder to integrate and maintain more and more enhancements as the upstream codebase diverges away. Please, if Canonical is going to pay Ted to do usability work, then pay him to do that work as part of the upstream development on the active codebase. It will significantly reduce the pain of integration when you rebase on the next gnome release.

-jef

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 21:09 UTC (Fri) by kragil (guest, #34373) [Link] (1 responses)

More Anti-Mark, Anti-Canonical and Ubuntu FUD from you.
It is getting really old.

The CVS days are over.
Nowadays new features are developed in a branch. New distributed version control systems make that very simple. And it is where new feature development should take place.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 21:38 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

Can you point me to the upstream gnome commit log for any branch commit for the fusa stuff that Ted Gould has done a commit for as part of upstream work on fusa so far? I could be doing my gnome svn or bzr qeuries wrong looking for commits..into any upstream branch.

-jef

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 1, 2008 4:17 UTC (Sat) by gouldtj (guest, #48027) [Link] (3 responses)

I really hope Ted is involved with ongoing upstream discussions, well before the Jaunty timeline that Shuttleworth eludes to. Either on the gnome usability lists or the desktop-devel-list where redesign of the panel usability is currently an active thread.

Of course, both Mark and I attended the GNOME User Interface hackfest and the GNOME Summit immediately afterwards. We've continued to discuss these topics in both IRC and on mailing lists as they've come up. I can't think of a post I've done recently, but that's not because of avoidance.

Shuttleworth's comments about not having have thought through packaging and integration speaks volumes. If Canonical's expertise is really integration as Shuttleworth as previously stated..why was that the part they had the most trouble with?

Well, there is lots to discuss here, perhaps over a beer sometime. But, I think there are a few things to be taken from this. One, we screwed up, we were working on the wrong schedule. If we want to be 'upstream' to the distribution we need to be working on an upstream schedule instead of the distribution schedule. The other thing to take away from this is a big thanks to the folks on the Ubuntu platform team who gave us a huge helping hand when we needed it. Lastly, we've learned our lessons.

Canonical still doesn't understand the benefits of getting new things upstreamed to lower the maintenance and integration costs. It's a lesson they need to learn or they are going to find it harder and harder to integrate and maintain more and more enhancements as the upstream codebase diverges away. Please, if Canonical is going to pay Ted to do usability work, then pay him to do that work as part of the upstream development on the active codebase. It will significantly reduce the pain of integration when you rebase on the next gnome release.

First, I want to say that I think that's very unfair. We've worked hard to ensure that everything we do has the possibility to go upstream. In this case, we didn't see a path that would allow the code to go upstream (see my previous comment). That's unfortunate. We hope that in general, all of our code will be accepted by upstream. I'm sure 100% will never happen, but we'll try.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 2, 2008 22:41 UTC (Sun) by jspaleta (subscriber, #50639) [Link] (2 responses)

Well, there is lots to discuss here, perhaps over a beer sometime.

First, talking to me is absolutely pointless. But if you insist on it, show up at my curling club, and I'll buy you a pitcher after I teach you how to curl. I'll make sure to record the whole discussion and post it somewhere. It will be the first installment of a series of discussion collectively known as "The blowhard chronicles: The re-education of Jef"

Speaking of recordings... you wouldn't happen to know if the audio recording of the teleconference Shuttleworth had about Ibex this past week is available? I'd really hate relying on second hand Shuttleworth quotes from places like the Register, or for any laypress articles for that matter. Relying on cherry picked quotes never gives a full picture. I'd much prefer to see the selected quotes in the original context of the full teleconference. Can you get that full teleconference audio posted somewhere for public consumption?

But, I think there are a few things to be taken from this. One, we screwed up, we were working on the wrong schedule. If we want to be 'upstream' to the distribution we need to be working on an upstream schedule instead of the distribution schedule. The other thing to take away from this is a big thanks to the folks on the Ubuntu platform team who gave us a huge helping hand when we needed it. Lastly, we've learned our lessons.

You say you learned your lessons.. its easy to say that. Don't fall into the trap Shuttleworth falls into by opening his mouth and speaking from the pulpit well before you actually have a plan in place... cough open source launchpad..cough. How about you get on a Ubuntu forum thread or a Ubuntu mailinglist thread and hold an open discussion with your community about exactly what you are planning on doing to address the mistakes Canonical has made in attempting to push things into the distribution without thinking through integration issues. You must build a process where your community can act as a check on Canonical's tendency to jump the gun without thinking through the integration issues. I never actually jump into the middle of discussion in Ubuntu specific communication channels, so you don't have to worry about my trying to sideline that discussion with my own agenda.

Have that discussion, openly, with your entire community. Going out of your way to see me, or any external critic down over a beer that you learned your lesson doesn't really do anything. Discussions with me are not constructive, since I'm not one of the people who pays the price when Canonical screws up. Canonical must have a discussion with its own community and put a set of specific corrective actions forward. Put a publicly communicated process together and talk to your community of contributors so they can hold you accountable for sticking with that process.

If you have already had that discussion, just provide a reference to the forum or mailinglist thread.

First, I want to say that I think that's very unfair.

I am never fair, nor am I balanced. I would never fit in on the staff of Fox News.

We've worked hard to ensure that everything we do has the possibility to go upstream. In this case, we didn't see a path that would allow the code to go upstream (see my previous comment). That's unfortunate. We hope that in general, all of our code will be accepted by upstream. I'm sure 100% will never happen, but we'll try.

Here's the problem you want to think of this situation as exceptional... perhaps you are wrong about that. Perhaps the way that Canonical approaches "integration" makes these unfortunate situation more common than not. It's really nice to say things like you are hopeful that your contributions are upstream friendly...but if you aren't really looking internally at your own contribution statistics..and how much of of your downstream work is actually merged upstream..and how long it takes for that work to merge upstream..then its just wishful thinking. Just ask your own translation community if they are happy with the process Canonical uses and whether they are happy with the rate at which their translations are being merged with upstream projects. They've only been complaining about the same problem for years.

In any event, I look forward to seeing your name show up in upstream Gnome commit logs. Just for the record which accountname should I be looking for? -jef

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 3, 2008 9:37 UTC (Mon) by hppnq (guest, #14462) [Link] (1 responses)

Can we just read the Linux Weekly News, not today's jspaleta agenda? Please?

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 3, 2008 10:30 UTC (Mon) by kragil (guest, #34373) [Link]

+1

Ubuntu FUD daily. Someone teach him HTML.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Oct 31, 2008 18:17 UTC (Fri) by dbnichol (subscriber, #39622) [Link]

The GDM applet started as just a copy of FUSA, so they're not really that different. In fact, one of Ted Gould's features (the status settings) has already been merged into the new gdm applet.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 1, 2008 3:59 UTC (Sat) by gouldtj (guest, #48027) [Link] (7 responses)

Unfortunately the FUSA applet being used and the version of GDM being used are very closely tied together. In the new version of GDM the interface for the applet is entirely different.

When starting the work one of the things that we did is talk to the Ubuntu platform team about changing the version of GDM in Intrepid. We wanted it for several reasons, but it clearly wasn't ready to meet all of the demands that GDM would have placed on it in the distro. This left us with modifying the old applet.

In an attempt to make it easier to integrate upstream specifically I've broken out all the funcationality into individual patches. This could allow other distributions that are shipping with the older GDM/FUSA combo to cherry pick which features they'd like to ship. You can find information on the individual branches here:

http://gould.cx/ted/blog/Right_side_status

The fact that the code will never make it upstream directly is sad, but sometimes those are the choices that make sense at the time.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 1, 2008 8:28 UTC (Sat) by AlexHudson (guest, #41828) [Link]

I can understand the reasons for needing to do that development like that in this case; I just worry about development that has a "push it upstream later" mentality (which probably applies less here).

I've said this on Mark S.' blog as well, and this isn't a criticism specific to Canonical - Novell have (had) exactly the same disease imho - but for pieces that are relatively crucial parts of a desktop (like Novell's new menu, and this user switcher thing) it seems to me potentially dangerous to do the development first and then try to seek agreement about it going upstream later.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 3, 2008 16:54 UTC (Mon) by jspaleta (subscriber, #50639) [Link] (5 responses)

When starting the work one of the things that we did is talk to the Ubuntu platform team about changing the version of GDM in Intrepid. We wanted it for several reasons, but it clearly wasn't ready to meet all of the demands that GDM would have placed on it in the distro. This left us with modifying the old applet.

So instead of working with upstream to help make the active codebase good enough to distribute...you decided to enhance the old codebase. At any point did Canonical hold a discussion internally about tasking manhours to work on the new GDM codebase so that it is "ready" for your distro? If that discussion was public, I would appreciate a pointer to it. -jef

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 3, 2008 17:43 UTC (Mon) by gouldtj (guest, #48027) [Link] (4 responses)

So instead of working with upstream to help make the active codebase good enough to distribute...you decided to enhance the old codebase. At any point did Canonical hold a discussion internally about tasking manhours to work on the new GDM codebase so that it is "ready" for your distro? If that discussion was public, I would appreciate a pointer to it.

Yes, we decided that was the best approach for meeting the schedule that we wanted to hit. No, the discussion was not public.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 3, 2008 17:57 UTC (Mon) by jspaleta (subscriber, #50639) [Link] (3 responses)

Do you mean the near term schedule for this release? What about a year out from now. What happens if the people working on GDM right now...never get around to working on what Canonical needs? Is Canonical going to commit manhours to the upstream work on the current GDM to ensure that it does meet Ubuntu's needs by the next Ubuntu release? Or is Canonical content on letting other people do the work to move the GDM codebase forward?

I look forward to seeing the Canonical commits in the upstream GDM codebase.

-jef

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 3, 2008 21:03 UTC (Mon) by gouldtj (guest, #48027) [Link] (2 responses)

I'm sorry that you disagree with my decision making. I hope that you're able to succeed where I have failed.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 3, 2008 21:26 UTC (Mon) by jspaleta (subscriber, #50639) [Link] (1 responses)

Is that an implicit invitation for me to join future closed door Canonical planning session and make the case to Canonical to work directly in upstream trunk codebases like upstream GDM? I'm not sure I'm going to succeed in a closed door planning session. I would stand a far better chance of succeeding at that in a public forum.. and so would you.

-jef

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 6, 2008 22:54 UTC (Thu) by lysse (guest, #3190) [Link]

corbet: Please, please, please, please, please implement "ignore user" for LWN comments. Please, please, please, please.

Ibex design: user switching, presence and session termination (Here Be Dragons)

Posted Nov 6, 2008 5:09 UTC (Thu) by madscientist (subscriber, #16861) [Link]

I really enjoy using Ubuntu, but I do wish they would spend a little more effort on enterprise readiness. By this I mean in particular, thinking about enterprise capabilities like NIS, enterprise DHCP features like configuring NTP servers and NIS servers, etc. Most every shop that has lots of UNIX systems around still uses NIS at least for user/group login information, and very often for other critical infrastructure like automount maps, etc. Ubuntu is simply broken in these environments: it doesn't configure NTP or NIS servers based on the appropriate options in DHCP response packets. It doesn't properly handle automount maps configured in NIS (it starts automount before NIS is up, so it looks like there are no maps). I filed bugs about these issues at least early in Hardy, if not back in Gutsy.

And, having just upgraded to Intrepid I see a new problem: the user switcher shows ALL the users it can find, not just the local users; when I click on the switcher I get an absolutely ridiculously huge window, taking up my entire screen, containing every user that appears in my NIS passwd database. Really quite unusable. I found a bug about this that was filed in mid-August and still is marked "New" with no comments added.

After seeing how easy it is to keep their systems up-to-date with Ubuntu a number of my co-workers have switched, but I can't in good conscience recommend a wider audience for Ubuntu until these enterprise issues are addressed. It would be nice if there were a real push in that direction for Ibex.


Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds