Presentations from LinuxTag / Fudcon Berlin 2009 available; Tomorrow: Hackfests

My presentations on LinuxTag and Fudcon Berlin 2009 went mostly well. Biggest problem when looking back now: Seems it was more then enough stuff to talk for 90 or 100 minutes, but I only had a hour in total :-/.

Want to look at the slides? Follow these links:

• German, LinuxTag: "Überblick über aktuelle Entwicklungen des Linux-Kernels"
• English, FUDCon: "What is RPM Fusion and why it is really important for Fedora (and how you can help to make it better!)"

Another problem: There are so many people here at FUDCon and I more and more get the impression that the list with people I "want to meet, shake hands with and talk to for a while, to get a better connection between faces, email addresses, nicks, and (those sometimes overrated) real names" isn't getting shorter as fast as it should to meet everyone in the remaining time. Seems I need to speed up somehow...

It's the same for you? If yes and if you ever wanted to talk to the crazy troublemaker that did or does a lot of work for Fedora, EPEL and Livna/RPM Fusion then just grab me and start to talk to me when you see me walking by or sitting somewhere. The photo on the right shows how I look like, just imagine some mostly inconspicuous glasses on the nose. Ohh, and the hair is a bit shorter right now (I guess nature will do it's best to fix that over time).

BTW, again some informations for the FUDConners: I plan a small "RPM Fusion" hackfest for tomorrow *if* people are interested in one. There is no real plan what to do exactly besides the general idea: Do some work to improve RPM Fusion, and work out the details on the fly. Want to join? Then just watch the wiki and the usual places at FUDCon for details!

thl and knurd @ LinuxTag 2009 and Fudcon Berlin 2009

I just arrived in Berlin at the fairgrounds where LinuxTag 2009 and Fudcon 2009 are held. I'm staying till Sunday evening, but like so often I have to split my attention and time as I'm partly here for my employer and partly for fun/Fedora (just like last year at Red Hat Summit Boston).

As usual that's creating some interesting problems where I ideally wound like to be at two places at the same time :-/

Friday will get most complicated. I for example can't visit the Fudcon-Keynote from Jan Wildeboer, as I'm giving a "Kernel-Log" talk as part of the "Kernel Track" of LinuxTag at just the same time. That wasn't planed like that, but seems Jonathan Corbet canceled his trip and thus can't give his well know and always interesting "The Kernel report"; I three or four weeks ago was asked to fill the position and accepted (presentation is basically finished; luckily Linus closed the merge window a few hours ago). Note that I'm giving that talk in German, not in English, as Jonathan would have done.

I also have time and space problems for the barcamp pitching session at 5 pm local time: Together with Nils Magnus from LinuxTag e.V. / Linux New Media I'm moderating the Kernel Kwestioning at that time, where the audience can ask some kernel developers on stage a few questions.

And that are only the hard scheduled events which I really can't miss. I also want (have?) to hear at least two of the other talks (Union Mounts and Ksplice) from the Kernel track on LinuxTag, so I likely walk back and forth between Kernel track and Fudcon a lot on Friday. But I hope to join the Fudcon crowd early for Fudpub in the evening -- I mean, I likely *have to*, as the Fudpub otherwise might run out of pizza and drinks before I arrive (you know how Fedorians are...).

Remains to be seen how long I can stay at Fudpub, as I still have to prepare my presentation on RPM Fusion which I'm giving at 2 pm on Saturday on Fudcon. I'll give that talk in English -- I'm not completely sure yet if that works out, but I guess I have to give it a try sooner or later. So remember to bring eggs and tomatoes to throw them on the stage if my English is way to worse ;-)

So, see you on LinuxTag and Fudcon! This is how I look like. But note, I had to buy a add-on a few months ago: now with glasses (often, not always) ;-)

P.S.: Headline-Explanation: those that contribute to Fedora for a long while will remember that I used to be known as "thl" in the Fedora -world initially. But I already was and still am "thl" at work and a few years ago decided it might be better to use a different nick in the Fedora world -- after a bit of thinking I chose "knurd". That way it's at least a bit harder (especially on IRC!) to get the connection "Ohh, the thl that writes the kernel-log for c't/heise.de/the-h is also the one that contributes to Fedora", which I think is a good thing. But it's not really a secret anyway, as rare blog entry like this make it obvious. But trying to keep it a real secret would not work anyway, as the name "Thorsten Leemhuis" quite rare, so it's not that hard to find out anyway.

rpmfusion-{,non}free-remix-kickstarts -- or -- knurdix

There was always the idea to build a linux distribution with RPM Fusion packages within the RPM Fusion project -- e.g. live media and installer spins ^w remixes that are basically a distribution like Fedora under a different name and with some packages from RPM Fusion. There is/was Omega 10, which until now never became the official spin for one reason or another. Recently some other work was done to get one step closer to create a official "Fedora Remix" from RPM Fusion sooner or later:

RPM Fusion since a few weeks contains the packages rpmfusion-free-remix-kickstarts and rpmfusion-nonfree-remix-kickstarts in the repositories for Fedora 11 and Rawhide. They just like the Fedora package spin-kickstarts contain kickstart files that can be used to create your own linux distribution live-image using the Fedora Package Collection and Fedora's livecd-tools. A installer image is still on the todo list and might need some fixes in anaconda and the rpmfusion-{,non}free-release packages afaics.

The kickstart files in the two RPM Fusion packages are pretty basic: They simply include the kickstart files from Fedora, remove the Fedora branding, add the generic branding and add the repo definitions for RPM Fusion. That's basically it, because the comps groups from RPM Fusion extend the groups that Fedora defines and thus you automatically get all the packages you want depending on what's defined in the RPM Fusion comps files -- that is for example gstreamer-plugins-ugly and gstreamer-ffmpeg in the case of the Gnome groups and xine-lib-extras-freeworld for the KDE remix.

As a proffce of concept I created four remixes (Desktop and KDE for i586 and x86_64) for testing purposes and uploaded them to to the web for public testing. But warning: They are basically untested and just meant to show what's possible. Ohh, and due to the lack of a better name I just called them "knurdix" ;-) We'll need to find a different name for the official RPM Fusion images (which might be simply "RPM Fusion" or something else that sounds better).

Hopefully those packages and the kickstart files in it can help to get some people interested in the idea of a RPM Fusion remix -- maybe enough people to build and maintain official "Fedora remixes" with packages from RPM Fusion" in the long term. If you are interested to help just join the rpmfusion-developers list and share your ideas. Or get in contact with me directly, but the mailing list is the preferred way.

Make things easy

Alan Cox recently on LKML:

[...] If nobody else is interested then you can do the reviewing/acking
because clearly nobody else cares if you make a mistake. And if they do
then they'll be motivated to add resources to assist you ;) [...]

Sometimes I wonder if we should apply a similar concept in Fedora/RPM Fusion land more often.

Leave kmods in RPM Fusion, but make sure they work well

In short: Fedora IMHO should not ship separate packages with kernel modules (so called "kmod packages") as part of the package collection. But Fedora afaics needs to make sure things like kmods work well, even if they are not used in the Fedora package collection.

Verbose variant: Recently there was another(¹) discussion on fedora-devel about allowing packages with kernel-modules in the Fedora package collection. I'm one of the drivers of the original "kmod" packaging standard for kernel-modules in Fedora and take care of it in RPM Fusion these days (which uses a modified version). So obviously I have a strong interest in the area.

Nevertheless I stayed away from the discussion and I guess many would have been surprised if I'd shared my option: It doesn't make much (if any) sense to package kernel modules as separate packages in Fedora. The main reason for this option: Everything lands in one package repository anyway(²), so it's much easier for everyone to get the bits into Fedora's proper kernel package directly. And I agree with the suggested approach way to make that happen as well: get the modules upstream, e.g. in linus' "vanilla" kernel (and not the staging area), then Fedora will get them automatically.

But: Some widely used kernel-modules will never make it upstream. For others (like some of those in linux-staging) it's a long way that takes a lot of time, because the code of those modules often is in a bad shape; until that's fixed and an improved variant merged a lot of people are nevertheless willing to use the ugly code we have today, because for them it's often better than throwing hardware away.

Fedora ignores those cases -- afaics because they are "not the right thing to do" or maybe "politically incorrect". One can argue if that is right or wrong for Fedora, but that's a topic for a different blog entry. The real point I'm up to: users still want to get the modules they need. Thus they will either work around it locally, use/contribute to repositories like RPM Fusion, or switch to a distribution that offers them what they want.

The latter is something that is neither in the interest of Fedora or Red Hat. Hence I'd say it would be good if Fedora would make sure that things like kmods work well, *even if they are not used within Fedora* -- just like Red Hat makes sure that Oracle DBs work fine on RHEL (which uses kmods in RHEL5, so RHEL would benefit from proper kmod support and testing in Fedora as well). But that's not the case right now(³), which makes Fedora sometimes annoying or hard to use.

(¹) There have been a lot similar discussion around kmods over the past years.

(²) My option might be different if we had something like a "extras"/"unsupported" add-on repositories within Fedora, as that would make it obvious "hey, these modules are not part of the upstream kernel/might not work so well/might suddenly go away again".

(³) Note that the main problem afaics is on the Fedora side, so it's not really fixable for RPM Fusion. I outlined the details in a posting to fedora-devel last August, but nothing happened. There are ways to work around the problem using a yum-plugin. But that is not a real fix, because the problem is not specific to kmods -- it happens with a lot of other packages as well in cases where a RPM Fusion package depends on a specific version of a package that is part of Fedora (xine-lib and xine-lib-extras-freeworld for example). And yes, sorry, I don't have the skills to fix the problem myself. But I don't think I have to -- Fedora afaics is meant to be a community where people with different skills work on different areas of the project to make the whole thing better.