Its that time of the year again. Happy SysAdmin Day everyone.
If today is dragging, might want to refresh your memory of the great OddTodd... always a pick-me-up.
> Read More... | Digg This!

Its that time of the year again. Happy SysAdmin Day everyone.
If today is dragging, might want to refresh your memory of the great OddTodd... always a pick-me-up.
It's official the combined KDE Akademy and Gnome GAUDEC conferences will be held in Berlin in 2011, next year and this is great news! I played a small part in organising the joint conference in Gran Canaria in 2009, and really enjoyed working with the Gnome guys most of whom I hadn't meet before, as well as the familiar KDE people. It was great fun to see how it turned out. I don't think anyone really knew in advance - we didn't know if too much collaboration would spoil the 'community bonding' aspects of the conference and their individual identities. Or maybe too little collaboration would increase the distance between the two communities. In the end I thought the collaboration aspects could have been better, indeed like the WiFi could have been better - there is always something you can improve at these conferences, but what the heck, by and large it was mostly pretty good.
I enjoyed being able to go to both presentations, and some of my favourite ones, like the MeeGo^h^h^hMoblin user experience talk in the mobile track, came from the Gnome side. Both projects are facing the problem of how to you merge your desktop technology with the upcoming Smartphone/Small devices that run platforms such as Android or Meego.
A consequence of stresses like upstream vs downstream or mobile vs desktop, is that Dave Neary's recent survey of Gnome contributors has given rise to much discussion and flaming about Canonical's contribution. One from Mark Shuttleworth called Tribalism is the enemy within, which is worth a read. That addresses tribalism within the Gnome community, and that is clearly a bad thing.
Another good post from Jono Bacon RED HAT, CANONICAL AND GNOME CONTRIBUTIONS included this from Dylan Macall, which made a good point:
"..This whole thing is really putting forwards an issue Gnome has right now: they can?t, as a community, decide whether they like the idea of external projects building new environments on the Gnome platform. (Case in point: Meego for netbooks).
I think there?s one camp that thinks Gnome should be a user-facing product, with its own special branding and its own distinctive look that everything ships in pristine condition. (I?ll inject my opinion in brackets here: I think that entirely defeats the purpose of having multiple distributions).
Then there?s another camp that sees Gnome as a starting point with lots of handy tools (and common modules) for distributions to build operating systems. For example, Unity, Meego, Jolicloud, UNR?
That first camp sees Gnome as a monolithic project; only internal work is worthy. The latter camp sees Gnome as something akin to Gnu.."
I think you could have exactly the same discussion about the KDE project and what it's relationship with MeeGo should be. Does KDE consist of a lot of useful tools and libraries that we should encourage as many other projects as possible to use? Or should we concentrate mainly on a cohesive desktop experience? Are the two aims incompatible? I don't know..
I hope we can minimise Gnome vs KDE tribalism too, and I'm looking forward to another combined conference, where we can integrate the communities better (and in the process have great parties involving much beer drinking of course). I was slightly disappointed that Gnome 3.0 has been delayed, and I really wish them good luck in getting it out of the door. It is not true at all, that if Gnome does worse, then KDE will do better. If both projects succeed it is more like '1 + 1 = 3' or if one project fails it is '1 + 1 = 0.5'. We now have much infrastructure in common and need each other to succeed so let's "Relax"..



During the Akademy kde-on-mobile discussion, Kévin Ottens suggested that mimetypes be splitted out from the main sycoca database, in order to reduce the overall time kbuildsycoca takes every time it runs, and to make things more modular. Last monday I had a look and decided to go one step further and not use ksycoca at all for mimetypes. This makes the KMimeType subsystem really independent (usable without having run kbuildsycoca4 before, so no dependency on kdeinit+kded etc). Took me the whole week, but there we are.
Given that shared-mime-info delivers pre-processed output already, we "just" have to load what we need, on demand, in-process. I was afraid this would be slower and take more memory as a result, but see results below.
The KMimeType subsystem now loads directly from disk the information it needs. The first time you use findByPath("foo.jpeg") it loads the "globs" file generated by shared-mime-info once and for all into memory, and then uses that for fast matching. Same thing for the list of aliases (one big file, loaded once), and for "subclasses". The more expensive information is the XML file for each mimetype, but this is only needed when asking for the icon, the comment, or the list of extensions for a given mimetype. This used to be all parsed and cached into ksycoca, now it's done on demand by KMimeType.
The only mimetype-related thing that is still in ksycoca is one tiny entry per mimetype, with a pointer to the list of services (applications) which support this mimetype, for KMimeTypeTrader.
Here are the performance results:
I find it interesting how not using a cache that was invented to improve performance, actually improves performance 
Interestingly, I thought it would be worse on memory usage too, but it's not:
./kmimetypechoosertest_gui in kdelibs-4.5: VmSize: 282060 kB, VmData: 14524 kB
./kmimetypechoosertest_gui in kdelibs-trunk: VmSize: 215976 kB, VmData: 11976 kB
The "visual" result of all this:
kdelibs-4.5$ kmimetypefinder foo.cpp
KSycocaPrivate::openDatabase: Trying to open ksycoca from "/var/tmp/dfaure-kde4/kdecache-dfaure/ksycoca4"
text/x-c++src
kdelibs-trunk$ kmimetypefinder foo.cpp
text/x-c++src(This particular use case of starting one process for one mimetype lookup has of course worse performance now, but it's time to stop looking at performance when it's about 0.01s vs 0.03s for a one-time operation...)
Anyway the main point of these 2 commands was: no ksycoca needed.
Now I'm not trying to send the message that ksycoca is bad. We definitely need it for things like "find the apps that support image/jpeg" or "find the apps that contain FooBar in their name or keywords". The number of app desktop files is so big, that we definitely need some kind of database index for these, we don't want to load all of them into memory in each process. But for mimetypes, thanks to shared-mime-info producing usable output, not using ksycoca actually makes sense, the information is already in a usable form even for fast lookups (mimetype by name, mimetype for a certain file, by name and/or content).
Writing all this makes me realize that the caching of kioslave .protocolinfo files into ksycoca is more like mimetypes than applications and even simpler: fewer items, and always used for looking up the details for a single protocol by name. So, logically I should extract it from ksycoca too. Well, after the vacations 
Nova, my first daughter, is now 6 and Glenn, my first son, is now 5. As a GeekDad I ensure to bathe them in geeky goodness. I've been thankful that Glenn is obsessed with Lego. The kool thing about it is that of course, I get to help him, so its just a great time.
This got me thinking back to my own youth. I had a box of Lego's but not a lot of sets. The one that I did get was in 1988, when my parents got me perhaps my favorite (but forgotten until recently) toy of youth: the Lego Technic 8865 "Test Car".
That set was amazing. I proudly displayed it on my shelf in my room, both because of my pride in building it as well as just how outright kool it is.
Since that time Technic has grown up as much as I have. Take a look at the Technic Lego 8421 Mobile Crane:
So tempted to buy that.
But most fun of all... this week Glenn is in a one-week Lego Pre-Engineering class. For 3 hours a day they geek out and build all manner of fun stuff.
One thing I'll throw out there for Dad's... Lego has an Education dept: Lego Education. Of particular interest to Tamarah and I, is they have a complete Homeschool Curriculum and various kids, including robotics kits, for education. A really amazing resource for parents.
Damon Edwards (DTO Solutions) & John Willis (Opscode) are the two guys really pumping out the "good news" of devops. They started a new podcast, Devops Cafe several weeks ago. Already on episode 8, having featured guests such as John Allspaw, R.I. Pienaar, Andrew Shafer, and more. Highly recommended.
Whats interesting is that John & Damon really aware of an outcry from the community, that is: "How do all these devops shops do it!!" We want to emulate them, know what tools they have, how they use them, what works, what doesn't, etc. So to facilitate just that, they started a videocast sub-series called: Open Mic.
Open Mic 1: DevOps Metrics and Dashboards at Shopzilla from dev2ops.org on Vimeo.
In the first episode, they take us into Shopzilla, where Juan Paul Ramirez shows us their tools, metrics, and talks extensively about how they got to where they are. Excellent content!
If you haven't already seen, perhaps the most popular talk this year at Velocity, "A Day in the Life of Facebook", in which the Facebook Ops team introduces us to their tools and organization.
Whats really great here is that we're not share deeper information about how we're doing things, such that we can be a community of organizations. In the past, only a handful would really share and they were always far removed from useful pratice. I really hope this trend continues.
Big thanks to John and Damon for helping fuel that fire!
OpenChange is an important project, but it does require quite a lot of work to get it all to build. We're working on the process, but in the mean time, we've (ok, Julien Kerihuel with nothing from me except encouragement) has built a Virtual Box image that provides OpenChange all built, configured, set up and ready to try.
See http://tracker.openchange.org/projects/openchange/wiki/OpenChange_Appliance for the download (ftp or rsync) location and setup procedures.
Have fun, and let us know how it goes!