Ambiently Sharing Creativity

iTunes Protected vs. Unprotected

Dear lazyweb,

A friend of mine has released an album on the iTunes store, and I want to buy it to support her. Of course, I don’t want to buy it there if it’s a DRM-protected AAC file. Anybody know how you can tell before you buy? I checked both using iTunes on a Mac, and on the iTunes Store app on my iPod Touch, but I can’t seem to figure it out.

It seems her album is also sold on Amazon (cheaper, even), and they sell 256kbps MP3s, so I’ll probably end up doing that regardless. But it would be nice to know if you can figure this out for Apple’s store too.

Update: It appears everything on the iTunes store is now DRM-free. Interesting.

July 02, 2009 08:41 PM

Press Release 1

Libre Graphics Meeting 2010 à Bruxelles:

July 02, 2009 03:33 PM

User:Clementine

New user account

New page

July 02, 2009 01:36 PM

Why I disagree with RMS concerning Mono

The GNOME press contact alias got a mail last weekend from Sam Varghese asking about the possibility of new Mono applications being added to GNOME 3.0, and I answered it. I didn’t think much about it at the time, but I see now that the reason Sam was asking was because of Richard Stallman’s recent warnings about Mono - Sam’s article has since appeared with the ominous looking title “GNOME 3.0 may have more Mono apps“. And indeed it may. It may also have more alien technology, we’re not sure yet. We’re still working on an agreement with the DoD to get access to the alien craft in Fort Knox.

Anyway - that aside, Richard’s position is that it’s dangerous to include Mono to the point where removing it is difficult, should that become necessary to legally distribute your software. On the surface, I agree. But he goes a little further, saying that since it is dangerous to depend on Mono, we should actively discourage its use. And on this point, we disagree.

I’m not arguing that we should encourage its use either, but I fundamentally disagree with discouraging someone from pursuing a technology choice because of the threat of patents. In this particular case, the law is an ass. The patent system in the United States is out of control and dysfunctional, and it is bringing the rest of the world down with it. The time has come to take a stand and say “We don’t care about patents. We’re just not going to think about them. Sue us if you want.”

The healthy thing to do now would be to provoke a test case of the US patent system. Take advantage of one of the many cease & desist letters that get sent out for vacuous patented technology to make a case against the US PTO’s policy pertaining to software and business process patents. Run an “implement your favourite stupid patent as free software” competition.

In all of the projects that I have been involved in over the years, patent fears have had a negative affect on developer productivity and morale. In the GIMP, we struggled with patent issues related to compression algorithms for GIF and TIFF, colour management, and for some plug-ins. In GNOME, it’s been Mono mostly, but also MP3, and related (and unrelated) issues have handicapped basic functionality like playing DVDs for years. In Openwengo, the area of audio and video codecs is mined with patent restrictions, including the popular codecs G729 and H264 among others.

What could we have achieved if standards bodies had a patent pledge as part of their standardisation process, and released reference implementations under an artistic licence? How much further along would we be if cryptography, filesystems, codecs and data compression weren’t so heavily handicapped by patents? Or if we’d just ignored the patents and created clean-room implementations of these patented technologies?

That’s what I believe we need to do. Ignore the patent system completely. I believe strongly in respecting licencing requirements related to third party products and developer packs. I think it’s reasonable to respect people’s trademarks and trade secrets. But having respect for patents, and the patent system, is ridiculous. Let a thousand flowers bloom, and let the chips fall where they may.

So if you want to write a killer app in Mono, then don’t let anyone tell you otherwise. If you build it, they will come.

July 02, 2009 09:09 AM

The Green Dam be Damned: Free Party Day Press Hits from using Laoban Soundsystem 1.0

[ End of the day photo by Shasha Liu ]

I wrote a quick summary of yesterday’s party and chronicled many press hits the event got on the Internet. I’m still not finding many photos which I know were being taken. If you took photos or wrote about yesterday, please do comment on this post or email me.

I also wrote about the Laoban Soundsystem 1.0 July 1st Green Day IDEA2009 on my wiki previously if you’d like to chip in some links or comments. I really want to use the speakers, granted they aren’t the big Laoban 2.0 stack, for more events in Beijing! Also, I really must learn more about this brilliant Ableton live software. I’ve avoided it because its not free software, but now I think I’ve got it running in Wine. And, regardless, I must learn about this software if myself or anyone else wants to make something similar for live audio/video performances in the same caliber, but as Free Software (and better!).

If you want a great analysis and take on the Chinese Green Dam Saga, please read Andrew Lih’s post and the other great ones by Rebecca MacKinnon.

July 02, 2009 07:37 AM

Dumping currently loaded Firefox URLs

Chris Cheney posed an interesting problem - how to get a listing of currently opened Firefox windows.

You can get this info from sessionstore.js in your firefox profile, but it's a jumble of javascript. I wrote a script ff-pages to display them in a more useful way.

Example usage:

$ ff-pages .mozilla/firefox/*.default/sessionstore.js

Window 0:
    http://shoutcast.net/directory/index.phtml
    http://www.radioparadise.com
    http://people.ubuntu.com/~bryce/Plots/
    file:///var/www/X/Graphs
Window 1:
    https://bugs.launchpad.net/ubuntu/+bug/379797
    https://bugs.freedesktop.org/show_bug.cgi?id=21315
Window 2:
    https://bugs.launchpad.net/ubuntu/+bug/360319
    https://bugs.launchpad.net/ubuntu/+bug/376092
Window 3:
    https://bugs.freedesktop.org/show_bug.cgi?id=21756
    https://bugs.freedesktop.org/show_bug.cgi?id=16702
...

July 02, 2009 02:22 AM

Solutions to me-too storms

Yesterday I wrote about me-too storms, including how they develop and some of the problems they can cause (most notably - delaying the bug's solution).

Since this is a bad problem there's been quite a few ideas proposed.

FIXING the bugs faster would be the best thing of course. That's a whole other topic... but does deserves first mention.

Launchpad already has a solution in the form of the "This bug doesn't affect me (change)" text and link on every bug.

Presumably this is serving as a lightning rod saving us from heaps of me-too comments. And presumably the data is being stored somewhere to help developers identify highly popular bugs, but I don't know how to access that info. I would imagine if developers could filter/sort/view this data it'd give added incentive for people to use that and it would be a more effective tool.

Another issue is that the link just isn't that noticeable. I'll leave it to usability experts to work out how best to improve it, but it definitely needs a re-think so it's a bit more obvious, especially for casual launchpad visitors.

Educating bug reporters is another oft-suggested solution. I think there's some truism about documentation being the worst way to explain how software works, because no one will read it. Actually there's been reams and reams of discussion and documentation about how to write and behave on bug reports, and indeed I think this is really helpful as it can turn bad bug reporters into really good bug reporters. That said, many people are just too busy, or too lazy, or don't even know they don't know how to report bugs.

Hiding comments or otherwise emphasizing/de-emphasizing comments by various criteria has been suggested and I believe is being considered by the launchpad crew. The trick is to do this in a way that doesn't end up actually consuming more time to manage than it saves. I think a lot of useful experimentation could be done on this idea using greasemonkey, as Brian Murray has done.

Splitting bug reports would be pretty cool feature, at least in theory. If we realize that John and Bob have different issues, it'd be slick to be able to push a button and have all of Bob's comments moved to its own bug report. But in practice I suspect this could result in creating more confusion by losing context. In any case, I don't think it'd help with me-too storms since most of the low value comments really aren't worth setting up a separate bug for; better to just have the people file new bugs from scratch.

Locking bug reports, is sometimes suggested by those familiar with similar functionality provided by forums software.

Minimum karma requirements to post onto other people's bugs is an idea I've been kicking around for a while. I've noticed (thanks to Kees Cook's lp_karma_suffix greasemonkey script) a very strong correlation that the worst me-too'ers also tend to have the lowest karma. People with the most helpful comments usually have higher karma.

So why not make use of that by requiring posters to have a certain karma level before being able to comment on someone else's bug report? From what I can tell, it needn't be high; 50 points would be enough to weed out the vast majority of the noise, but still be low enough that anyone with a legitimate interest in helping on bug reports could earn with a fairly minimal amount of work, such as helping on answers.ubuntu.com or going through the full bug process following up on their own bug reports.

Perhaps it could be set up to kick in only after there are already a few commenters, so we don't get in the way of random helpers on bugs that would otherwise be neglected. In a way, this would be akin to the "locking" idea above, but a bit more targeted.

Other thoughts?

July 01, 2009 06:39 PM

Laoban 1.0 Retrofitted Grillz July 1 Free Party Day

Just in time, Matt got some pretty new aluminum fronts cut in time for the big event today.

Now that the Green Dam Youth Escort has been delayed, we have a full on celebraton on our hands in CaoChangDi from now until midnight, on Wed, July 1, 2009.

July 01, 2009 01:01 AM

Fabricatorz Laoban at Free Ai Wei Wei Party Wednesday July 1, 2009 Caochangdi

Spread the word! The Party Day is on tomorrow like no other in CaoChangDi! Get your boycott on.

[Link to the SVG file]

We will bring our Laoban 1.0 Soundsystem with its new shiny grillz tomorrow. To all DJs and musicians out there (especially good ones!), this is an open call to come on out and plug-in to the speakers. We need you to come out and make some sound, art, and have a big ole green day brainstorm. The whole day is free and open! The entire day is to boycott the Chinese Internet.

To all our Internets Massive! To all Twitteronians, Identicators, Free and Open Source, Creative Commons’d out people in Beijing, or those who just want to have fun, please come out tomorrow for the full day or even just part of it. Matt Hope, Jon Phillips (rejon), Robin, Phil Dunn and so many more will most definitely be on hand to mix, make some projects in realtime and collectively boycott the Internet.

Party Day — See You in Caochangdi

WEDNESDAY 2009 1 July 9:00 AM to 11:30 PM, all day beer and chatting.

Blog friends, food friends, all are welcome. There will be gifts.

Phone: 010-8456-4194
Email: xuesheng512@gmail.com

Address: Beijing, Chaoyang District, Airport Service Road, Caochangdi No. 258 FAKE Studios

Breakfast menu: soy milk, gruel, youtiao, dumplings, four types of pickled vegetables, fried eggs, ham, tea eggs, fruit platter

Lunch menu: cinnamon lotus root, village style fungus mushrooms, seafood hot and sour soup, marinated duck, oyster sauce beef, fried fresh vegetables, Yangzhou fried rice, fried noodles, seasonal fruit

Dinner menu: cucumber, fish and egg soup, barbecue chicken, fish steaks, gulao pork, hot and spicy tofu, black peppercorn beefsteak, fried dishes, assorted mushrooms, udon, lotus fried rice, seasonal fruit

Midnight snack menu: cabbage hearts, spicy dried tofu, peanuts, fried broad noodles, gruel, fried bread with dipping sauce, garlicky vegetables, season fruit, four types of pickled vegetables

Breakfast, lunch, dinner, and midnight snack. Coke, Sprite, Fanta, orange juice, plum juice, lemon tea, Tsingtao, all kinds of beverages.

Guests can hang out in the lobby our outside eating and doing whatever they feel like.

Thanks to our great friend Robin Peckham for the realtime translation of the original post by the Wizzler.

UPDATE: Chinese government has delayed the Green Dam! The party goes on though in more of a celebration-mode!

June 30, 2009 10:41 AM

"Me-too storms" in launchpad

I deal with a lot of X.org bugs in launchpad, and I often run into an intriguing phenomenon, the so-called "me-too storm".

Essentially, a me-too storm is a bug report which accumulates a large number of confirmation statements from different people, to the point that it actually hinders progress.

Knowing that a bug affects additional people does have some value to it. I particularly appreciate it when someone of a technical bent is able to reproduce a problem, because I can have confidence that they can test out patches or at least provide insightful technical analysis.

However, past maybe half a dozen comments, the value of an additional confirmation drops off to zero. So, comments in a healthy bug report would shift from confirmatory statements towards comparing data, discussing workarounds, identifying test cases, proposing patches, and so on.

Unfortunately, with a me-too storm, the confirmation statements come in at a faster clip, and their quality often drops further. Commonly, the confirmer will not provide log files or other proof that they do indeed have the bug. This is a particular problem with X because often there are different unrelated bugs that have identical symptoms (examples include X freezes, black screens, performance degradation), and so they might have a different bug; by "me-too'ing" their bug instead of creating their own bug report, it means their issue probably won't be investigated, or it can cause massive confusion or even sidetrack the discussion away from the original bug.

The bug suffers from a bad feedback loop at this point. The more comments a bug has, the more "important" it looks to launchpad's search engine, so it gets suggested to anyone with vaguely similar symptoms. New commenters notice that some old commenters provided data already so they don't bother putting it in.

Indeed, after a while the bug report can start accumulating negative comments, that have a value below zero - they actually detract from the discussion. These range from demanding "is it fixed yet?" questions to rude, inflammatory or borderline threatening comments "fix it now or I go back to windows, you insensitive clod!!!1!" These predictably stir up a variety of 0-value follow on comments, "No, it's not fixed yet, please be patient," "yeah +1 for fixing this soon," "did you try rebooting? it helped me," "plz unsub me from this list, to many emailz," "'doze sucks, get a mac," and so on.

Now, no one would argue that "me-too storm" bugs are not important. Obviously with so many people commenting, there must be some real problem that needs dealt with. It could be a real bug, or a class of bugs with similar symptoms, or a usability issue, or even just poorly set expectations...

However, the stormy nature of these high comment bugs tends to work against themselves, for a few reasons. First, as a developer it's just plain time consuming to read through a gazillion comments. Second, these bugs can be hard to summarize and send upstream, particularly if analysis data is coming from different people (with perhaps differing hardware). Third, if you post a proposed solution, you often get feedback from people having unrelated bugs that leads you to make erroneous conclusions about the fix.

The "me-too storm" is a fascinating phenomenon, but since it hinders bug solution it is interesting to consider ways that this could be prevented or mitigated in launchpad. I'll share my own thoughts in a future post. Meanwhile, I'd love to hear other's ideas.

June 29, 2009 08:53 PM

Prerelease of 0.47 is available

Later than expected we uploaded a prerelease of upcoming Inkscape 0.47. We are working on rescheduling the final release. The prerelease is currently available as source code and a Mac build and binary builds for Ubuntu. Fedora users can also use testing repository to fetch recent builds. Windows binary builds might follow, but you can use nightly builds for now. We encourage you to test and report issues you run into.

June 29, 2009 05:28 PM

Inkscape 0.47 about screen contest results

We have the winner of the about screen contest! Congratulations to sko whose winning submission has first received 29 votes from the DeviantArt community and then Inkscape developers choose it from three submissions with the most votes. A big thanks go to all participants for showing off what can be done in Inkscape when combined with creativity. In case you have missed them, here are all submissions.

June 29, 2009 05:28 PM

Translation Statistics

Here are the current translation statistics for Inkscape trunk. We have 13 languages at 80% or better - it's only a half of what we had in the 0.46 release! We should catch up since 0.47 release is nearing. Compared to state at 0.46 release we have 1 new language (hy), 15 languages dropped under 80% (bg, ca, de, en_GB, eo, fi, hu, km, nb, pt_BR, pt, sr@latin, sr, vi and zh_CN) and only 1 language got over 80% (ko). am: 1% ar: 9% az: 3% be: 63% bg: 55% bn: 0% br: 100% ca: 64% ca@valencia: 43% cs: 43% da: 37% de: 57% dz: 42% el: 5% en_AU: 26% en_CA: 3% en_GB: 74% en_US@piglatin: 42% eo: 74% es: 91% es_MX: 6% et: 2% eu: 98% fi: 59% fr: 100% ga: 1% gl: 37% he: 81% hr: 56% hu: 65% hy: 11% id: 2% ja: 39% km: 74% ko: 93% lt: 39% mk: 0% mn: 3% nb: 42% ne: 34% nl: 99% nn: 28% pa: 16% pl: 99% pt: 54% pt_BR: 62% ro: 19% ru: 95% rw: 1% sk: 99% sl: 99% sq: 1% sr: 71% sr@latin: 61% sv: 23% th: 21% tr: 22% uk: 100% vi: 63% zh_CN: 58% zh_TW: 99% Average: 47%

June 29, 2009 05:28 PM

Press Release 1

Tried to make English version of first graf more active. English and French text are now OUT OF SYNC following this edit.

June 29, 2009 04:11 PM

Dear GNOME developers…

What happened to Integrated Media Management for GNOME GSoC project? Was there any real code in the end? Is it going to be used? Where? When?

June 29, 2009 03:15 PM

Conference

June 29, 2009 08:57 AM

Conference 2010

Redirected page to Conference

New page

June 29, 2009 08:53 AM

Conference 2009

June 29, 2009 08:52 AM

Texture (v2)

After much waiting around, here’s a new version of the video I presented at the end of my LGM talk. This time, there’s about twice as much new footage, better rhythm, better encoding quality, title cards, and generally a more interesting experience. Of course, all made with PiTiVi 0.13.1.

June 27, 2009 12:17 PM

User:379 buy prandin

New user account

New page

June 27, 2009 12:04 AM

Caochangdi RealLife Painting

It collects particles in the air in #caochangdi

The Underground Space in Beijing

Is this a possible #laoban event space?

June 25, 2009 08:32 AM

Worldlabel: Clip Art of the Week: Minduka’s Notebook

We are really getting into photo-realistic clip art. Maybe its the world being flooded with iPhones or loads of movies like Terminator 4 and Transformers that show off some new concepts in glassy interfaces. Regardless, Minduka has his eyes set on making some quality clip art.

Also, Minduka made a nice image of a Present. With Open Clip Art Library (OCAL), since I’m an admin, I’m able to help cleanup Minduka’s file. When he uploaded it, he did not set the document boundary correctly. We hope that all types of people will upload content, so please keep uploading. However, every once and a while special people come to the Open Clip Art Library who want help fix these issues. We call these awesome people, Librarians. If you want to be one, please do join our mailing list and we can show you how.

I fixed the following image, uploaded the file again and then created a thumbnail of his work for this blog post and the OCAL website. Fixed!

Clip Art of the Week is brought to you by Worldlabel.com, a maker of labels for laser and inkjet printing.

June 24, 2009 09:32 AM

Ubuntu's xorg-edgers PPA

The xorg-edgers Personal Package Archive (PPA) has been proving itself in battle for Karmic.

PPAs can be thought of as basically a "build service", however they also include dependency info that lets you deploy a set of interdependent packages. This feature is extremely handy for X.org since it is not unusual for a package to require a new mesa, libdrm, or kernel update. PPAs provide a package-system compatible way to let users install a package and all its dependencies in one go.

xorg-edgers was originally set up by Tormod Volden a couple years ago to make it easier for bug reporters to test git snapshots of the -ati and -radeonhd drivers. These drivers were not putting out regular releases, but were very active at committing fixes for problems we reported, so xorg-edgers gave a way to both enable users to easily validate the fixes, and as a way to test-drive a particular snapshot before uploading it to Ubuntu proper.

Several of us noticed how useful this approach was, and assisted Tormod. One key was to turn the procedure of packaging new git snapshots into a script, and document the procedure so others could participate more easily.

Over time, xorg-edgers expanded to include more than just ATI drivers. Today it encompasses the major video drivers, the x-server itself, and all manner of various dependency libraries.

Since xorg-edgers is set up as a team PPA, the overhead of getting access to uploading to it is much lower than to upload X.org bits to Ubuntu main. This has paid off recently as the team gained a new member, Robert 'Sarvatt' Hooker, who has dug into the tough work of sorting out KMS packaging issues with Tormod and myself, and has been using the git snapshot scripts to keep packages up to date.

One thing I really like about how xorg-edgers is set up is that it is strongly community-owned and driven. It gives freedom to experiment beyond what would be suitable in the distro proper, and it engages contributions that might not have been made otherwise. This bleeding edge packaging work can be an exciting challenge, especially when it results in you being the first to see some sexy new feature.

Yet I also see xorg-edgers as strategically important for tackling the types of problems we've run into with X.org in the past. First, it should help us more reliably detect major regressions in upstream versions prior to upload by engaging a larger pool of testers than we've had in the past. Second, since upstream prefers reported bugs to be tested against their recent work, it makes it easier to ensure our upstreamed bugs are maximally relevant to upstream. Third, it gives users with bugs in the current version an alternative to try.

Another reason I strongly support xorg-edgers is to help upstream. Without something like xorg-edgers there is a trade-off between including newly released versions in Ubuntu, which helps upstream by giving them more testers but risks regressions, and sticking with older but proven-stable versions. upstream can simply recommend bug reporters test against xorg-edgers, rather than walk them through all the steps of compiling all the various bits from git (which can sometimes overwhelm non-technical folks!) Ubuntu benefits as well in that the bugs and their fixes are tested in a Ubuntu environment, so when we do update to the new version we can be assured that the reported problem will be fixed.

We've gotten good feedback from upstream about xorg-edgers, such as in a recent blog post by Carl Worth. I know that other Linux distributions are often considered more "developer-oriented" because they carry newer (if unstable) versions of packages, but I hope that techniques such as xorg-edgers provide a better solution to the problem in the eyes of upstreams, that gives a stable Ubuntu base to the majority of users, and testing "overlays" that users can opt-in to as needed for doing testing/development of particular subsystems.

June 22, 2009 10:22 PM

PiTiVi manual

I have spent approximately 15.6 hours (in the past week or so) writing a new user manual for PiTiVi. By hand. With a pen and paper during boring meetings. And then converted it to the digital medium with my awesome dvorak typist skills.

The result can be seen in PDF here as a preview (temporary place). The source file is also available if you want to make some extensive edits.

Please take a look, provide suggestions/comments, etc. This manual is geared towards PiTiVi 0.13.2 rather than 0.13.1, so it even documents nonexistent features (such as ripple/roll editing).

I typeset it using OpenOffice Writer, because:

• I want a manual that looks good, modern, professional, unique. So far, the best-looking software manuals I’ve seen are monolithic PDF files.
• I’m much, much faster and efficient with Writer. Hey, if I could typeset a whole 10-20 pages journal in an hour with it, it sure isn’t so bad?
• LaTeX is not an option. I don’t want to fight with it. This manual is too design-centric.
• Docbook gets in my way (much more xml tags than contents!), and, so far, the manuals I’ve seen in GNOME apps feel a bit… odd. When looking at them, I somehow get lost, I don’t feel a clear sense of hierarchy or chronology/gradual learning. That’s subjective of course. Maybe I just didn’t spend enough time actually using Yelp. Maybe I’m crazy.

Anyway. Take a look at this manual. See if it’s any good.

June 21, 2009 03:31 PM

Maemo Summit - help make it great

This year, I’ve been asked to help with the content selection for the Maemo Summit, which will be held in October, in Amsterdam. We’re aiming for a very cool conference with lots of tips, tricks, hacks and general hardware coolness over 3 days.

Nokia is organising the first day, and the second and third days are entirely organised by the community. After a round of discussion, myself, Valerio Valerio and Jamie Bennett will be choosing content for the summit from among presentations proposed by the community. We’re aiming for presentations which will target three main audiences: tablet users, application developers and platform developers.

You can read more about the call for content or how to submit a presentation on the Maemo wiki. We’ve agreed on a fairly novel way of filling the schedule - we are starting from an empty grid, with three tracks, a couple of plenary sessions, and some lightning talks. As great talks come in, we will add them directly to the grid. If we don’t think that talks are up to scratch, they will be rejected, the submission will move to the Talk page for the Submissions wiki page, and if we are hesitant, the proposals will stay in the Submissions queue.

This has some great benefits over the usual call for papers/deadline/selection/publish the entire schedule scheme of things. Most proposers will know straight away whether their talk has been accepted, rejected, or converted into a lightning talk. Attendees will see the schedule building up and be able to propose sessions to account for topics that are not yet accounted for. And we will be able to keep some small number of slots until quite late in the organisation cycle for “late breaking news” - those great presentations that arrive too late for your deadline, but which you would really love to see get onto the schedule. And it is a kind of auction system - you have a great interest in getting your presentation proposal in early, rather than waiting for the last minute.

Anyway - let’s see how it works. You can follow the progress of the schedule on the wiki as well.

Good luck to all!

June 19, 2009 04:50 PM

On In-Kernel Drivers

It’s pretty well-known that the Linux kernel developers advocate getting your drivers into the main line kernel tree. Doing so ensures that your driver always gets fixed to conform to the latest “correct” internal interfaces when they change, and in-kernel device drivers always get distributed with the kernel, so you get automatic end-user distribution for free.

While I agree with that (without touching the question of whether or not a stable driver binary API/ABI would be useful), I’m not entirely sure it’s the best thing in the world for some types of device drivers.

While reading a post by Carl Worth on recent (perceived?) driver stability issues with the Intel video driver for Linux, I came across this bit of insight:

It used to be that getting the latest Intel driver just meant updating an xf86-video-intel module or upgrading an xserver-xorg-video-intel package. But now it’s essential to get a recent kernel as well… And these fixes aren’t in a major kernel release until 2.6.30 which appeared only today.

This is a problem that perhaps highlights some types of drivers that may be served better by being maintained outside the main line Linux kernel tree. Of course, this is only true while the driver is actively maintained and maintainers are able to quickly update the driver for new kernels (without breaking backward compatibility) as in-kernel interfaces change.

He also notes that distribution maintainers tend to update critical parts of the system (like the kernel) less often than userspace portions (like X.org video drivers). Since the xorg-video-intel driver depends on an in-kernel driver, it’s easy for these two things to become out of sync on an end-user’s system without testing. Or, frustratingly, the maintainer of the userspace package for a video driver might be unable to update to a newer version of the userspace driver because the kernel packager doesn’t wish to upgrade the entire kernel to become compatible with that userspace package (which is an entirely reasonable position to take).

And with more video drivers expected to move toward having significant kernel portions, this problem can only get worse. What if the latest userspace package for drivers A and B both depend on kernel 2.6.30, and the maintainer of package A wants to update, but the package B maintainer doesn’t (perhaps there’s a bad bug in the latest version of B)? Even if the A package maintainer can convince the kernel maintainer to update, doing so might break things for other users.

Now, sure, having dependency issues like that is nothing new, but I submit that this is a bit different. The kernel contains so much “unrelated” functionality that it has the potential to be a root dependency of many unrelated packages. For example, if a video player depends on a particular version of a codec library, you can often update that codec library without causing issues with other video players (ignoring, for a moment, ffmpeg’s inability to maintain a stable API). But updating the kernel because a userspace video driver requires a new kernel version could potentially cause problems with anything ranging from a USB storage device, to a hard disk controller, to an audio card.

Now, of course, the Intel video driver has been undergoing some very large changes lately. In theory, these things will settle down, interfaces will stabilize, and you can expect the tight coupling between the kernel version and userspace package version to relax a bit. But perhaps during this transition period it might make sense to avoid merging kernel code like this at all, and instead do separate releases of (in this case) the DRM modules that are paired to the userspace package. I imagine it wouldn’t be too much of a burden for distro packagers to disable building the in-kernel versions of these drivers, and instead ship an extra module package that the userspace driver packages can depend on.

June 17, 2009 11:14 PM

I finally succumbed

And got myself a new telephone. When I was in Berlin for the KOffice Sprint, I get totally fed up with sms'ing with only a numerical keyboard. So I went to the shop and got myself something with a real keyboard: a Nokia E71.

My previous phone was actually the Motorola phone I received got the 2006 aKademy Award for Best Application. I clocked up about three hours of call time and about sixty sms messages since then -- I'm not a great phone user. But look what this phone can do:

Logging in with ssh on my home server!

Of course, no matter what you do, unless you get one given to you (and my daughters are now fighing over the Motorola phone), when you get a phone, you will feel ripped off. Did I get the best data plan? Shouldn't I have waited for another type of phone with just as good a keyboard, but full VGA resolution? Or maybe even got something that doesn't run S60?

Right now, I think this phone has great hardware, great design (with two minus points: the rubbery bits covering usb and micro-sd slot are tacky, and the screen resolution should be better.) and software that could be improved a lot.

June 14, 2009 03:12 PM

I feel dumb...

Because I cannot figure out what button to click in this dialog:

ETA: I feel doubly dumb now. I accidentally burned debian twice, because when I wanted to burn the kubuntu cd for the kids' computer, I clicked on the kubuntu iso image in k3b's file manager, and it popped up the burn image dialog -- and somehow had remembered that last time I had burned the debian image (for the server, though I doubt k3b knew that). Result: 2 debian cd's, no kubuntu cd.

June 14, 2009 01:47 PM

Ré-expédier un message dans Evolution

J’ai trouvé aujourd’hui une fonctionnalité très utile que je cherchais depuis longtemps dans Evolution. Fallait simplement pas s’attendre à ce que ce soit appelé “renvoyer le message” comme dans Groupwise.

The Evolution way of re-sending messages:

June 13, 2009 03:01 PM

Use Ogg

Just choose Ogg as your video-codec (ogg-theora) and audio-codec (ogg-vorbis) of choice, especially on webpages.

Why again this blatant advertising? - Because nobody here uses JPEG2000 either, and java or flash for video playback just sucks!

OK - you could put any codecs in the new < video > tag, since the web we know is OPEN and FREE, remember?

But tell me: which codec is so darn cool and

• plays out of the box in Firefox and Opera soon!
• is so tempting that even dailymotion can't hesitate to play around with it already!
• is natively supported in VLC!
• gets better all the time!
• is absolutely free!
• has a stoned fish on a crystal as a logo!

Nobody can compete with that - so why do you even THINK about limiting $$-crap that takes away your freedom to show people your useless stuff!? Take action and choose Ogg whenever YOU can. That's how mp3 became a standard; without any decision from the "big players".

[EDIT:] Check out this comparison, Ogg absolutely can compete with h.264!

June 12, 2009 07:45 PM