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!

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"..

> Read More... | Digg This!

The Ubuntu Software Center is making some rocking progress, but as everyone’s favorite Dr Vish suggests, it is only a container for other content, and we need to fix and improve the descriptions of apps inside Ubuntu to make it easier for users. This is a wonderful contribution to Ubuntu. Want to get involved? Simple, check [...]

> Read More... | Digg This!

Earlier this week at GUADEC, the always affable Dave Neary presented his GNOME Census work. Unfortunately, I was not there to see it, but I read his excellent post on the topic. One of the reactions from the survey was that Red Hat are responsible for 16% of the contributions to GNOME whereas Canonical are responsible [...]

> Read More... | Digg This!

A few years ago Novell conducted an online public survey to determine which MS-Windows only need to be ported on Linux desktop. Graphics apps did tops most wanted Linux app list on the survey. However, Linux comes with the sheer numbers of open source software projects produced by the community. You may overwhelmed by the choices available under Linux and not know where to begin.

> Read More... | Digg This!

After many months kubuntu.org got a new look, complete with new logo. Many thanks to Ofir for his patience in seeing this through.

---

During the Platform sprint in Prague I took Aurelien Gateau, doko and a couple of nice chaps from SuSE Prague canoeing on the awesome whitewater course near the city centre.

Looking confident at the top

This flatwater is easy

King of the wave

This blury photo is the last anyone has seen of Aurelien, if you live downstream of Prauge please look out for him in his blue canoe


> Read More... | Digg This!

New announcement about Solaris support on non-Oracle servers:

• Oracle today announced Dell and HP will certify and resell Oracle Solaris, Oracle Enterprise Linux and Oracle VM on their respective x86 platforms.

> Read More... | Digg This!

Are you good folks aware of what is happening on 27th – 29th August 2010. But of course, it is the Ubuntu Global Jam! In the last few cycles we have organized and run an event called the Ubuntu Global Jam. The idea was simple: encourage our awesome global Ubuntu community to get together in the [...]

> Read More... | Digg This!

I have always been a fan of helping in any way I can to encourage people to support small organizations and businesses who are doing their best to be successful by working hard and providing a friendly, honest service. For the earlier part of this week I am in The Hague at GUADEC, and I stumbled [...]

> Read More... | Digg This!

Some time ago we created the Team Reporting facility in Ubuntu, and I am pleased to see that LoCo Teams are using Team Reports to kep us all up to date on the awesome progress going on across the community. I just wanted to remind you good folks of where to find the reports and how [...]

> Read More... | Digg This!

Last week I was in Prague with my team; the first with Ahmed since he joined. It was an awesome week and it was useful to checkpoint our progress. We also took the first ever full team photos of us, first in our room and second at the end of the week having a drink: Thanks to [...]

> Read More... | Digg This!

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:

• "kbuildsycoca4 --noincremental" (with warm caches) went from 2.8s to 2.1s
• Mimetype inheritance tests (KMimeType::is() on a list of 40 mimetypes, like PreviewJob does), went from 791,404 instr. loads to 568,345 instr. loads (QBENCHMARK and "./mytest -callgrind" rock). So, loading the subclasses file directly from disk is actually faster than loading a preprocessed form from ksycoca? Well, it's also that constructing a KMimeType is way faster now, since the mimetype details are not loaded in this case.
• Mimetype glob matching (reconizing that "foo.jpg" is a jpeg file) is also much faster: from 100k-120k instructions to 75k instructions. (This doesn't include the one-time-per-process parsing of the globs files).
• Something had to give, though. The worst case for loading mimetype details is a tree that shows all mimetypes, such as the KMimeTypeChooser widget. Instead of loading the icon and comments from ksycoca it now loads them from individual xml files, so even though I ported that code from QDomDocument to QXmlStreamReader (which made it 29% faster), the overall time for loading all mimetype details is much longer: 1182k instead of 113k instructions. However from the user's point of view, this means 460ms instead of 60ms when opening that tree of mimetypes, which actually takes quite longer because of the icon loading anyway. I think this is acceptable. The very common use case (mimetype lookup and matching) was optimized at the expense of the rare case (showing all mimetypes).

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:

I'm not entirely sure why, in fact, apart from the fact that ksycoca (kmimetypefactory, more precisely) was loading some dicts unconditionally, like the alias list, which isn't loaded anymore in this particular use case. It can't be the size of KMimeType objects, they are not kept in memory in either case. So I'm still a bit surprised, but well, the good way, so not really worth spending time with massif

The "visual" result of all this:

(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

> Read More... | Digg This!

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.

> Read More... | Digg This!

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!

> Read More... | Digg This!

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!

> Read More... | Digg This!