Ibex design: user switching, presence and session termination (Here Be Dragons)
With Intrepid on track to hit the wires today I thought Id 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 its been mentioned in a couple of different forums (briefly earning the memorable title the new hotness), but since its 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."
Posted Oct 30, 2008 23:20 UTC (Thu)
by jwb (guest, #15467)
[Link] (10 responses)
Posted Oct 31, 2008 0:18 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Oct 31, 2008 0:31 UTC (Fri)
by jwb (guest, #15467)
[Link] (1 responses)
Posted Oct 31, 2008 7:50 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Posted Oct 31, 2008 1:59 UTC (Fri)
by ringerc (subscriber, #3071)
[Link] (3 responses)
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
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
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.
Posted Oct 31, 2008 2:09 UTC (Fri)
by jwb (guest, #15467)
[Link] (2 responses)
The start time is October 20, as listed. The total CPU time used is 9h49m44s, also as listed.
Posted Oct 31, 2008 8:07 UTC (Fri)
by ringerc (subscriber, #3071)
[Link]
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?
Posted Oct 31, 2008 13:12 UTC (Fri)
by sbergman27 (guest, #10767)
[Link]
Posted Oct 31, 2008 3:04 UTC (Fri)
by spiv (guest, #9031)
[Link]
Posted Oct 31, 2008 11:54 UTC (Fri)
by Frej (guest, #4165)
[Link]
Just don't use top as a blame tool.
Posted Nov 6, 2008 8:40 UTC (Thu)
by ekj (guest, #1524)
[Link]
Posted Oct 31, 2008 7:45 UTC (Fri)
by AlexHudson (guest, #41828)
[Link] (18 responses)
Posted Oct 31, 2008 8:37 UTC (Fri)
by dholbach (guest, #53300)
[Link] (9 responses)
"The FUSA applet itself is going through a bit of a transformation upstream as its been merged into the new GDM codebase and the old code - on which our work is based - is more or less EOLd. But well figure out how to update this work for Jaunty and hopefully it will be easier to get it upstreamed at that point."
Posted Oct 31, 2008 9:50 UTC (Fri)
by AlexHudson (guest, #41828)
[Link] (8 responses)
Posted Oct 31, 2008 17:31 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (6 responses)
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
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
Posted Oct 31, 2008 21:09 UTC (Fri)
by kragil (guest, #34373)
[Link] (1 responses)
The CVS days are over.
Posted Oct 31, 2008 21:38 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link]
-jef
Posted Nov 1, 2008 4:17 UTC (Sat)
by gouldtj (guest, #48027)
[Link] (3 responses)
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.
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.
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.
Posted Nov 2, 2008 22:41 UTC (Sun)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
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
Posted Nov 3, 2008 9:37 UTC (Mon)
by hppnq (guest, #14462)
[Link] (1 responses)
Posted Nov 3, 2008 10:30 UTC (Mon)
by kragil (guest, #34373)
[Link]
Ubuntu FUD daily. Someone teach him HTML.
Posted Oct 31, 2008 18:17 UTC (Fri)
by dbnichol (subscriber, #39622)
[Link]
Posted Nov 1, 2008 3:59 UTC (Sat)
by gouldtj (guest, #48027)
[Link] (7 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.
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.
Posted Nov 1, 2008 8:28 UTC (Sat)
by AlexHudson (guest, #41828)
[Link]
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.
Posted Nov 3, 2008 16:54 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (5 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.
-jef
Posted Nov 3, 2008 17:43 UTC (Mon)
by gouldtj (guest, #48027)
[Link] (4 responses)
Yes, we decided that was the best approach for meeting the schedule that we wanted to hit. No, the discussion was not public.
Posted Nov 3, 2008 17:57 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (3 responses)
I look forward to seeing the Canonical commits in the upstream GDM codebase.
-jef
Posted Nov 3, 2008 21:03 UTC (Mon)
by gouldtj (guest, #48027)
[Link] (2 responses)
Posted Nov 3, 2008 21:26 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
-jef
Posted Nov 6, 2008 22:54 UTC (Thu)
by lysse (guest, #3190)
[Link]
Posted Nov 6, 2008 5:09 UTC (Thu)
by madscientist (subscriber, #16861)
[Link]
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.
I have some disturbing news about Ubuntu's "new hotness":
Ibex design: user switching, presence and session termination (Here Be Dragons)
$ 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)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
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)
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
9119 root 0.0 /usr/sbin/console-kit-daemon
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
"We focus most of our effort on integration"
Ibex design: user switching, presence and session termination (Here Be Dragons)
It is getting really old.
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)
Ibex design: user switching, presence and session termination (Here Be Dragons)
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?
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.
Well, there is lots to discuss here, perhaps over a beer sometime.
Ibex design: user switching, presence and session termination (Here Be Dragons)
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)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
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.
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
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.
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
Ibex design: user switching, presence and session termination (Here Be Dragons)
