Jakoblog ...home of jpetso

As of half a day ago, Drupal's accepted student projects for the Google Summer of Code 2009 have been announced (and of course, also for the other participating organisations). We selected 18 wicked students with intriguing project proposals, and had a hard time sorting out which ones to take because the number of promising proposals was pretty high this time for Drupal. We still should be able to provide motivated students with mentoring even if they didn't make it to the final list, assuming Google's prize money was not the primary motivation to apply for SoC.

In addition to the official Drupal list, I also noticed a Drupal-related project hosted by Creative Commons. Also, former Drupal SoC alumni Allister Beharry (who worked on DAST in 2007) is now showing up with a project for upstream PHP. Other favorites of mine include the entirety of KDE and X.org projects, as well as my buddy klausi getting accepted for a Drupal/Rules project.

The coolest thing for me personally, though, is the selection of not one but an thrilling number of two awesome projects related to Version Control API: Marco Antonio Villegas Vega (a.k.a. marvil07) will work on internal API improvements and other stuff like SSH key authentication, while Daniel Hackney (a.k.a. chrono325) takes care of better VCS support and Rules integration. Both want to help with the transition of Drupal core to a distributed version control system such as Git, and will be mentored by Tony Narlock (skiquel), Sam Boyer (sdboyer) and of course me. With a little luck, we should be able to avoid the epic failure of last year's project and push Version Control API to the next level.

And of course, pushing it onto drupal.org is still on the plate and will be the first thing for me to work on after I finally submit my thesis in mid May.

Apart from Version Control API, I've also been working on another piece of code, and after a long time of fuzzing around with architecture and internals it's now slowly getting to a state where one can get excited about it. I didn't make it in time to show it off at DrupalCon DC, but now the module can be found on drupal.org: Say hello to Transformations, your favorite new uncut diamond for performing data transformations in Drupal (including, but not limited to import/export).

Experience has shown that starting with the underlying concepts always triggers the question "So what does it actually do?", so let's start with the use cases that lead to the module's inception:

• We [1] want to import CSV data into CCK nodes, mapping CSV columns to node title/body or CCK fields. Ok, that's easy: just take Node import and be done with it. But there's more...
• We want to take XML files conforming to given standardized XML schema, and map some of its fields to the CCK node just like one would do it with CSV fields. That's a bit more difficult, because it needs to deal with nested structures instead of a simple row/column based CSV table.
• Now it's getting fun: We want a single (nested) XML item to import as multiple nodes, for example, into a Pageroute collection.
• Oh right, and exporting all of those nodes into their original formats should be possible as well.
• Why stop with plain import and export? Combining those two, we could build a format bridge that (for example) converts between CSV and XML data, or between two different types of XML structures.
• Also, we've got a site with lots of content types and, consequently, lots of different CCK fields. There were several times when it was necessary to change the structure of these content types, or even split up one type of node into a collection of nodes. (Note the similarity to the Pageroute example above?) It's kinda tedious to write update routines for those "internal migrations" in code - why not map CCK fields to each other in a before/after fashion?
• Lastly, have you thought of the possibility that imported data doesn't come in the required format? For example, a date could be given as timestamp, as ISO date string, or as combination of three XML tags named <date><year>2009</year><month>04</month><day>10</day></date>. Maybe that data is not even the data that we want to import, but only references the actual data. There needs to be some way to convert formats on importing stuff, or use the available data to retrieve the actually desired data.

Now, I hear someone arguing like, "Scope creep! When you pack all that functionality into a single module, it will get bloated, hard to use and unmaintainable." And to a certain extent, I agree with that. As far as I can see, a major reason that Import/Export API failed is that it tried to establish a single common data format that described all possible information, and moreover, every data backend (Drupal nodes, CSV, XML) was required to cope with all that information. In other words, the architecture of Import/Export API might have required too much of a monolithic approach, which lead to the maintainability problems that were at least part of the reason why the project stalled.

Does that mean that generic import/export systems are unfeasible? I don't believe so, and I hope Transformations' architecture takes enough precautions to avoid the fate of Import/Export API.

The key idea to Transformations is that we'll never be able to capture all possible data formats and structures in a single module. What we can do, though, is to decompose that data into bite-size pieces, and define operations that can process those. (For example, operations transforming a Unix timestamp into an ISO date string or into a PHP DateTime object are pretty straightforward.) Building on that, we can assemble the pieces into larger pieces of data, and we can also define operations on those. (Extract the first three dates from a list of dates? Sure, easy enough.) In essence, importing and exporting data is nothing more than decomposing data, processing it according to a given set of rules, and reassembling it in a different form.

The key idea to Transformations is that we don't want to know all those rules upfront, there's just too many ways in which data can be decomposed, processed and reassembled. So instead of trying to cover all use cases, let's provide users with the necessary tools to define their transformations by themselves. Let's not define a single common data format that all data needs to conform to - all we need is a set of data formats, plus the knowledge which operations work on which data, plus a way to wire them up. If you think that wiring up operations sounds like Yahoo! Pipes, you're on the right track - only that Transformations can actually deal with structure information (schemas), and that my current user interface is way more crude than Yahoo's nice JavaScript wizardry.

The key idea to Transformations is that if we want a generic import/export module, it's important not to provide a solution but to provide a framework. Transformations is a framework for creating data transformation pipelines. ETL for Drupal, you might say - a braindead attempt to eliminate a whole class of import/export modules, and a potential basis for a Yahoo! Pipes clone on Drupal. Transformations provides the means for developers and users to build their own stuff.

Oh, and Transformations is incomplete, unpolished and (beware!) object-oriented. Until now, I worked to get the concepts right. Next step: building on the foundations, and extending it to enable more concrete use cases being built upon it. For now, it can be used for CSV import/export in a way that is more complicated than Node Import will ever be. But the flexibility of the framework also promises possibilities that go way beyond nodes and two-dimensional tables.

Still reading? Still interested? Then go and check it out.

[1] "We" as in "my company, Pro.Karriere", or more specifically, my boss and visionary entrepreneur, Klaus.

Since the Summer of Code of Version Control API's inception ended, there had always been one piece of cvs.module functionality that hadn't yet been ported to the new VCS-independent infrastructure. Incidentally, this was also one of the most visible and important features on drupal.org: packaging releases from CVS tags and branches by means of a simple two-step form.

Well, not anymore! Yesterday, I released Version Control API 6.x-1.0-rc1, which sports a number of important improvements under the hood, and versioncontrol_project 6.x-1.0-rc1, which makes use of these new features to provide release node integration and a release tarball packaging script, like the one found on drupal.org. The main difference is that the code is not CVS specific, and even though only the CVS backend supports the required functionality at the moment there is nothing holding up an implementation for SVN or the newly-revamped Git backend.

The latter has pretty much singe-handedly been ported by new contributor CorniI (a.k.a. Cornelius R.) to Drupal 6 and to API changes in Version Control API for 6.x-1.x. He's not yet done making sure that everything works as intended, but most importantly the Git backend runs again and can be played with. Good times coming for DVCS support!

So with Version Control API & friends being "feature-complete", the next step is to push it onto drupal.org and replace cvs.module. For that to happen, the primary task is to complete the migration scripts that pull data from cvs.module to Version Control API, If you want to help out with that, you can get in contact with me, dww and hunmonk - unless new cvs.module functionality is added in the meantime, the data migration is the last missing piece for getting deployed on drupal.org.

In general, the roadmap for Version Control API looks like this:

• Make the 6.x-1.x releases suitable for drupal.org, running on CVS only (like d.o does today). This is important so that improvements get contributed to Version Control API instead of cvs.module, which avoids porting more dozens of newly contributed features.
• Changes that make it possible to run drupal.org on other version control systems will go into a 6.x-2.x branch. That includes user authentication changes to enable SSH key or HTTP(s) authentication, and important non-CVS log parsing performance improvements that can be achieved by making the API object-oriented, and stuff that makes distributed version control systems work more nicely with Version Control API.

Hope to see you contributing soon!

Drupal related stuff, short and to the point:

• I'm back from DC too. That was one terrific DrupalCon there. (Imho, best DrupalCon ever!)
• Version Control API now has a proper handbook page, a (now marked as "official") SoC 2009 ideas list, and a new Git backend contributor. Way to go!
• I finally updated my blog to Drupal 6, which means I can use run Comment Count Image for my blog posts! Let's see if it shows up on Planet Drupal... and if it does, feel free to comment the crap out of this post in order to try it out! (I still reserve the right to delete obnoxious comments that slightly resemble spam.)

Version Control API is back! There's no stable 5.x-2.0 release yet, and the Drupal 6 version will only be tackled after that happens (i.e. next year), but we're alive and kicking again. And yes, I'm still determined to get it to replace cvs.module on drupal.org. Even if it might take another year until all the odds and ends come together.

Anyways, now is the time for potential contributors to jump in and create recipes on how to set up version control integrated sites, to port the Git and Mercurial backends, create a new one for Bazaar, to make the repository viewer work on previous revisions or to improve the CVS backend so that it's browsable like the SVN backend's development version. If you're ambitious, you might also try porting drupal.org's release scripts to the Version Control API so that automated releases can be made with Subversion and other version control systems.

Whatever the outcome, the era of cumbersome reinventions is over for the time being. Time to get started on features (and the D6 port, soonish) - let's push cvs.module into irrelevance and take version control integration with Drupal to the next level!

If you're passionate about version control systems, here's where you can make a difference!

It all started when I upgraded to the new Kubuntu 8.10, a.k.a. "Intrepid", which did a bunch of nice things to my laptop - most importantly, it resurrected my beloved suspend-to-RAM that went out of order in Hardy. I couldn't be more grateful for that. Intrepid even made the volume keys work... yay!

Of course, every Kubuntu update has its downsides as well. This time, the Wrath of Shuttleworth manifested as a series of interrelated X.org issues: stuttering videos (which played perfectly fine in Hardy), mouse cursor jumps once I keep the mouse quiet for a few seconds, and a curious lack of autoconfiguration for the VGA output - something that had mysteriously worked since the previous release, so I had not questioned it despite knowing that Xrandr 1.2 was not the most enthusiastically hyped area of KDE development known to mankind.

Not possessing or even requiring a projector or external monitor by myself, I was able to live with this for a month or so. But when I had to borrow a collegue's laptop for a university presentation last Friday - after not getting my own machine to spit out proper signals - the Time of Change had come. (And no, I don't mean a certain KDE release with that codename.) On that day, I was torn between no VGA output at all on the one hand, and resolution mismatch problems on the other hand. Neither did I know how this stuff even works, nor that I could have easily solved all of this with a few simple calls to the xrandr command line utility.

I had to get my VGA output working though, because this Tuesday I would throw a movie night at my place, with a nice projector borrowed from my parents, lighting the White Wall of Moving Pictures. I needed to get rid of both the playback stutter and the projector output uglyness. Step by step, I got to the root of all evil.

First step: Figuring out the bad guy. With Google as my weapon of choice, an Ubuntu forum thread about the playback stutter issue was to be found, strengthening my hopes of not suffering alone. The solution of switching to Fluxbox or GNOME is not one of my favorite plans though, but at least it helped determine that KWin is innocent (by making it work in a Fluxbox session, but not with Compiz in a KDE session). Another thread pointed out the amazing correlation between mouse jumps and video stutter.

So while writing all of this up in a bug report, I remembered a blog entry by nixternal pointing out that the "Detecting RANDR (monitor) changes" kded service (to be found in System Settings) was causing problems for people with external monitors. In a stroke of luck, disabling that service was indeed enough to get rid of both the stutter and the jumps. Terrific.

But I still had to get the connection with my projector to work. So I immersed myself in the skillful use of the xrandr command line utility, and went on a search for the 10-second timer that messed up not only my system but that of countless others as well. Turns out that the "Detecting RANDR (monitor) changes" service is not even a part of KDE proper - it's a semi-private branch of krandr by KWin maintainer Lubos Lunak. The thing that causes my video to stutter, my mouse to jump, but also causes other monitors to flicker or recalibrate: all of that is caused by recurring polling of X, in order to notice when external video outputs are connected. (Certain hardware is not able to notify applications in certain scenarios, so that polling would have been ok if it didn't cause havoc on so many systems.)

Second step: getting it all to work! For my movie night, the combination of disabled kded service and xrandr fuzzing was sufficient to get the film nicely rolling. However, it was a slight disappointment that KDE's own display configuration in System Settings ("Size & Orientation", a.k.a. krandr) failed so ungracefully. When it started up, it automatically switched my laptop screen ("LVDS") to some weird resolution (1360x768, I believe), and not for the Love of God would it enable the projector output ("VGA"). All of this while the seemingly trivial xrandr command line tool achieved those tasks rather nicely.

Needless to say, I wasted another day with diving into the krandr code, and fixing one issue after the other. So the net gain for you, dear reader, will be a System Settings screen configuration tool in KDE 4.2 that Mostly Works (TM). Unthinkable joy shall be your reward for reading this crap all the way down! Congrats for your persistence. Dual-monitor setups? Nope, sorry. But reliable mode switching that doesn't make you go OMG WTF BBQ and doesn't mess up your screens if you merely start it. That is what you'll get.

I also hope that Kubuntu will soon update to the 7-week-old latest revision of that notorious "Detecting RANDR (monitor) changes" service, because that version already (already?) has the 10-second fuck-up timer disabled. I only would have hoped that the merging of unreleased hacks into the default setups of every Kubuntu user out there was not taken so lightly, but hey - I still haven't switched to Fedora or OpenSUSE so it can't be that bad. (...right?)

Third step: getting to know the latest trends. Seems like Plasma in 4.2 will feature a new screen management library called kephal, which is going to replace krandr in the near future. Chances are KDE and Plasma get decent multi-head support soon, but that's not quite my area of expertise - I'm just the occasional janitor, whereas Aike or Aaron have a much better grasp what the future holds for the neverending construction site that is screen management. Personally, I'm looking forward to getting my now-working configuration tool not broken until the next Surge of Technology sweeps through the lands of X.org.

Yeah, you might have read about the AutoBrace KTextEditor plugin which I introduced two weeks ago on this blog. You might even have tried it out, but it didn't work for you because it crashed under certain circumstances, it messed up pasted text, it broke undo functionality and it didn't do additional indentation although that would have been useful. You know who to blame for all of these shortcomings! (Right, that would be me.)

But fear not! I found ways to fix all of these, and it now works brilliantly and without a glitch. Unlike last time, I'm now even using the plugin myself. And on top of that, I even created an Oxygen icon (yay!) to display in the "Extensions" listing:

Now this makes you want to use Kate (or KDevelop) with AutoBrace just sooo badly, doesn't it? Heh, I knew it.

Hi Planet KDE!

You might already know me from 2006 or 2007, but currently I'm gone from KDE because of other commitments. So technically you shouldn't hear from me right now; however, my buddy klausi drove me to it.

Surprising high amounts of KDE coders use non-KDE technology like vi or emacs to hack on KDE, and mostly they've got good reasons to do so. The only option to get those people use Kate or KDevelop is to continually improve those. The respective developer teams are doing awesome work in that regard, while my contribution for today is just a small KTextEditor plugin. (Which means you can use it in Kate, KDevelop or whatever KatePart-based editors exist out there.)

The plugin is called AutoBrace and, frankly, an uninspired clone of the best feature that you'll find in Eclipse (apart from the compile-as-you-go automatism and sheer infinite amounts of complexity). Right, it's the automatic insertion of a closing brace ("}") after you ended a line with an opening one ("{"). Kate's standard insertion of parentheses, brackets and braces is simply too obtrusive for me, so even if I tried it several times I always had to disable it again because I can't stand it. So here's how AutoBrace works.

1. You, the developer, are writing a line of code, and want to open a new block delimited by braces. Looks like this:

1. If you press Enter and AutoBrace is enabled, it will insert your favorite new brace where it belongs. Looks like this:

It's no big deal in the code - actually, I should be embarrassed to blog about such a minor thing when other people are continuously rocking KDE with stuff like SVG support in KHTML (new), a whole new power management solution for KDE (relatively new), or a window manager that's just terrific (not new, but still awesome).

But I've got no scruples, so here's your blog post anyways. You can get AutoBrace right now for your current Kate, you just need to compile it beforehand. Here is where I put it. See you some other time!

So Google Chrome is out. Features and developer implications aside, it's another major step for Google in order to push the operating system and its desktop applications into irrelevance, and replace them by web applications. Because the web is where Google has its business. As a nice side effect, we get an open source browser, a fancy new JavaScript engine and a push for wider usage of web standards.

Now I'm a member of that hardliner fraction that emphasizes the "Free" aspect of Free Software (or Open Source, whatever), because it empowers users to choose which tools I can use to operate on any given set of data - as long as that data is available at all and follows open standards. I'm delighted that, nowadays, I can run my system on an open kernel with open drivers, get 3D accelleration from an open X Window System, and have it all fall into place with the wonderful KDE 4.1 desktop (shameless plug). It's all software that I can trust, because the Open Source development model guarantees that the code won't be stripped of crucial features or spiced up with indiscrete phone-home functionality and advertisements. I know that I'll be able to swap applications while still keeping all the important data, and I know that if something goes wrong, everything will still be alright in the end.

Open source web frameworks like Drupal do the same thing for web site creators: they provide a base that you can trust to go into the right direction, because that's the nature of genuine Open Source and in everyone's own interest, too. However, it does not provide the same level of trust to its end users: they only get HTML/JavaScript output without being able to hack the application and control the data that they put on the web page. Users can only delete data if the corresponding permissions are set, they can neither control nor modify the information that is logged about them, and they can only migrate to another system if the web site provides explicit export functionality or a suitable API.

With a tad of worry, I watch the trend of people giving away lots and lots of personal data to the web, in exchange for comfort or reliability. Mails keep being stored by GMail or other mail providers with fancy web interfaces, pulling them away and on one's own system with POP3 is a dying practice. Life is being captured in Blogger, Facebook and Twitter. If I want to browse through my friends' photo albums, I need to register on StudiVZ (German Facebook rip-off) because that's where they store them. Those services are provided by people who I do not trust to do the right thing, because even if the web sites run Free Software, the way it works does not guarantee that my data is safe and my interests are being followed - it might just not match the business model of the web site providers.

If you think that sounds like a lot of paranoia, you're probably right. Still, the point that I'd like to make is that we had all of this before: the user depending on proprietary software that controls what happens to the data, and thus creating vendor lock-in - which is a network effect, and causes more people to use the same software. As the desktop is slowly being freed from lock-in, the exact same thing is now being shifted onto the net. Instead of having to trust Microsoft for their office data, people now have to trust Facebook for their social online life. The only difference is that MS Office costs lots of money while Facebook is free (as in beer), because of their business model.

As of today, the web is not open. The GPL is the new BSD, and the web is the new freeware (not to be confused with Free Software). In order to let users keep the freedom that is now available (and usable) on the desktop, open source web software must work on decentralizing the web. Users should be able to keep their own web presence like they keep their desktop system: personal, trusted and only passing data around when that is desired. It shouldn't be necessary to have a single huge web site where the data of all different users comes together; instead, users would have their own data store that, for example, sends out twitter updates to the data stores of all the intended receivers. Instead of a central site that's in charge of everything, lots of small sites would communicate with each other, and the user would be in control of the data.

If the web replaces the desktop, it should be judged by the same criteria, and that goes not only for bling and usability but also for openness. Personally, I think that centralized, data-centric web applications are the biggest threat for openness and self-determined choice of client software since MS Office came around, and Google is doing well covering that issue by supporting Open Source where it doesn't hurt their main strategy. But at least they're being honest about it and try to do it nicely: I'm still a big fan of the Summer of Code and GHOP programs :P

In other news, both my Japan/India trip and Drupalcon were a blast, and I'm finally going into stealth mode now. See you later!

Weil ich nicht den ganzen Tag an dem blöden Uni-Projekt werkeln kann (ZAAACH!) hab ich mir die Zeit kurz mit meinen allseits bekannten RSS-Feeds vertrieben. Diesmal ist was besonders Lässiges dabei, und zwar nicht nur lässig (gibts durchaus öfters) sondern auch herzeigbar für die interessierte Masse.

Ein Screencast nämlich. Rafael Fernández López alias ereslibre hat sich die Zeit genommen und ein achtminütiges Video von KDE 4.1 und dessen geballter Ladung an netten Features zusammengestellt. Endgeil, sozusagen :P

Und nebenher kann ich auch von mir selber behaupten, eins der vielen kleinen Räder zu sein, die die neue 4.1er-Version so supercool machen. Rückblickend betrachtet geht auf meine Kappe eh so einiges: das Speichern der Textdatei-Sortierungen in Kate, die besser gezeichnete Anzahl von Mails (für KMail) und Feeds (für Akregator) in der Systemtray, das jetzt wieder richtig funktionierende automatische Verkleinern von Tabs im Konqueror, wenn sie mehr als die Fensterbreite brauchen, und natürlich weitere Fortschritte in Sachen desktop-übergreifende Iconsets.

Für KDE 4.0 hatte ich damals die Dateinamen der Icons kompatibel zur Icon Naming Specification umbenannt, nur hat das Umschalten der Iconsets an sich nicht wirklich funktioniert. Dieser Umstand ist in KDE 4.1 behoben, plus noch ein paar andere Feinschliffe, so dass man GNOME-Icons naht- und mühelos genauso für KDE verwenden kann. Das Einzige, was jetzt noch an Arbeit bleibt, ist das Koordinieren der ganzen spezifischen Icons für einzelne Programme mit GNOME (und XFCE).

Verglichen zu den unzähligen anderen Verbesserungen sind das natürlich nur Erdnüsse, und in Summe kommt dabei das beste KDE raus, das es je gegeben hat. KDE 4.0 war noch nicht ganz reif für die große böse Welt. KDE 4.1 wird euch umhauen. Jetzt auch mit Kontact, Kate und und Konqueror für Windows.

Achja, es ist ja noch gar nicht erschienen. Sorry, da bleibt also nur warten bis Ende Juli... oder beta-testen und selber die eine oder andere Verbesserung bewirken. (Nein, man muss nicht zwingend programmieren können!) Zumindest aber den Screencast reinziehen. Und alle: K - D - E! K - D - E!

(ok ok ok, ich hör schon auf.)

Der Google Summer of Code geht wieder los. Diesmal allerdings ohne mich (zumindest bin ich nicht als Student dabei), primär weil ich den ganzen Juli für einen Drei-Länder-Trip eingeplant hab. Nächste Woche wird das dann genauer ausgearbeitet, oder so.

Nichtsdestotrotz verspricht es, sowohl für Drupal als auch für KDE und überhaupt sonst auch wieder ziemlich interessant zu werden. Vielleicht kann ich sonst irgendwie aushelfen und motivierten Studenten unter die Arme greifen (hab mich jetzt für Drupal als möglicher Zweit-Mentor angeboten), jedenfalls bin ich gespannt was dieses Mal rauskommt. Traditionellerweise sind ja nur ein kleiner Teil der angefangenen Projekte tatsächlich von Nutzen für die Open-Source-Projekte, das Spannende ist also, wie viele der angekündigten Großtaten sich diesmal zu einer wertvollen Spende an die Community entwickeln werden.

Ansonsten, ja, ehm, frohe Ostern!

Also es gibt schon Zufälle, aber dieser hier kommt nicht allzu oft vor: von gestern auf heute sind gleich drei meiner Lieblings-Open-Source-Projekten mit neuen Versionen herausgekommen.

Kubuntu

Diese Release war lange geplant und abzusehen. Kubuntu 7.10, auch bekannt als Gutsy Gibbon (oder einfach nur Gutsy für die ganz Schnellen), wurde plangemäß veröffentlicht und kann wie sonst auch immer als CD-Image von den diversen Servern und als Bittorrent heruntergeladen werden.

Beta wie ich so bin, hab ich Gutsy natürlich schon seit einem Monat bei mir laufen, und ich kann (fast) nur Gutes darüber berichten:

• Die Energiespar-Features wirken sich endlich aus und verursachen eine merkbare Verlängerung der Batterielaufzeit.
• KNetworkManager hat endlich sein Update auf Version 0.2 gekriegt und ist jetzt deutlich besser, wenn auch immer noch nicht perfekt. Unter anderem kann er jetzt auch VPN- bzw. PPTP-Verbindungen, was die Abhängigkeit der Heimbewohner von meinen selbstgestrickten Verbindungs-Skripten lösen sollte. (Jemand sollte das allerdings ausprobieren und ein HOWTO dafür schreiben.)
• Nach langem Bangen und Hoffen funktioniert mit Gutsy endlich das Suspend to RAM, sprich der schnellere der beiden Tiefschlafmodi. Damit ist mein Computer jetzt innerhalb weniger Sekunden weg und wieder da, und braucht in der Zwischenzeit so gut wie keinen Strom.
• Mein neuer MP3-Player (Samsung YP-U3, wie schon mal erwähnt) funktioniert fast mit dem neuen Ubuntu. (Die dafür zuständige libmtp-Bibliothek hat ein mittelgroßes Update spendiert bekommen.) Verbinden, Songs auflisten und Löschen funktioniert anstandslos, nur mit dem Überspielen gibts irgendwie noch leichte Probleme :-S ...naja, aber mit ein bisschen Nachforschen kann ich vielleicht den libmtp-Entwicklern die nötigen Informationen zum Beheben des Problems liefern, und dann geht das auch.
• Und vieles mehr! Das waren jetzt nur die Sachen, die mich persönlich betreffen, wo anders hat sich sicher genauso viel getan.

Alles in allem ca. das upgradewürdigste Kubuntu bisher, meiner Meinung nach. Und für alle, die lieber mit dem GNOME-Desktop fahren, haben sie sozusagen als Beiprodukt außerdem auch das Ubuntu ohne K herausgegeben.

Drupal

Mein bevorzugtes Content Management Framework ist noch nicht ganz bei Version 6 angelangt, hat aber dafür die 5.3er unter die Leute gebracht, welche ein paar Sicherheitslücken bereinigt. Und weil die 6er auch nicht mehr lang braucht, gibts davon eine neue Testversion (Drupal 6 Beta 2) mit weniger kritischen Problemen als noch vor einem Monat mit der ersten Beta.

Also, Leute mit Drupal-5-Seiten sollten am besten gleich updaten, um mögliche feindliche Übernahmen zu verhindern, und können sich inzwischen auf Drupal 6 freuen, das wieder mal mit einem großen Haufen Verbesserungen an allen Ecken und Enden aufwarten wird.

KDE

Nachdem KDE 4 ja bekanntlich auch schon bald am Fertigwerden ist (das aktuelle Zieldatum ist irgendwann im Dezember), haben sie heute die dritte Beta-Version von KDE 4 zum Download freigegeben. Und als Bonus die Alpha 4 von KOffice, welches in der generalüberholten Version eine ernstzunehmende Alternative zu OpenOffice sein wird. Insbesondere auch für Windows und OS X, aber das gilt ja sowieso für den Großteil der KDE-4-Programme.

Als Beta- bzw. Alpha-Release sind diese zwei halt nur für Hardcore-Enthusiasten und Tester vorgesehen, fallen aber in die heutige Release-Statistik genauso hinein. (Vor ein paar Tagen ist eh auch schon KDE 3.5.8 als Bugfix-Release herausgekommen, das mit kleinen Eingriffen ein paar Bugs für das aktuell stabile KDE behebt. Ist allerdings zu spät fürs neue Kubuntu herausgekommen, so dass dort standardmäßig noch 3.5.7 dabei ist.)

Da tut sich doch einiges, gell? Mit Blick auf die revolutionär neuen KDEs und Drupals dieser Welt dürfte die Zeit um Weihnachten herum auch ohne spezifische Beachtung der üblichen Geschenke interessant werden :D

Dumdidum... nachdem Dell offensichtlich nicht nur imageträchtigen, sondern auch kommerziellen Erfolg mit seinen Linux-Laptops hat, greift das Fieber jetzt endlich um sich. Voraussagen von Steven J. Vaughan Nichols zum Trotz (welcher auf HP getippt hatte), scheint Lenovo mit ihren von IBM übernommenen Thinkpads die nächste Firma zu sein, die den Weg des auf Laptops vorinstallierten Linuxes gehen wird.

Trotz einiger Vorbehalte, die noch überwunden werden müssen, fragen sie auf den Lenovo-Blogs schon nach der gewünschten Distribution für ein zukünftiges Angebot. Was mit ziemlicher Sicherheit wieder Ubuntu werden wird.

Langsam, aber sicher. Besten Dank an Dell.

Yay, drei Blogeinträge in einer Woche... ich bin wieder da! Und weil die guten Neuigkeiten nicht wirklich aufhören wollen, hier gleich noch eine.

AMD will Entwicklung freier 3D-Linux-Treiber fördern

Diejenigen unter euch, die vielleicht nicht ganz perfekt aufgepasst oder es schon wieder vergessen haben (ist ja auch schon wieder ein Jahr her, oder so) werden sich vielleicht fragen, was AMD mit 3D-Linux-Treibern zu tun hat, weil die ja eigentlich hauptsächlich Prozessoren produzieren. Zur Erinnerung also: AMD hat damals ATI übernommen, welche ihrerseits im Linux-Grafikkartentreiber-Jammerspiel seit jeher das schwarze Schaf schlechthin waren.

Intel hat funktionierende, stabile Open-Source-Treiber (bravo!), nVidia hat proprietäre, aber zumindest schnelle und auch halbwegs stabile Treiber, und ATI hat proprietäre, instabile und für die Leistung der Grafikkarten phänomenal langsame Treiber. Keine der drei Firmen hat bisher Spezifikationen zu ihren Grafikkarten veröffentlicht, die einen unabhängigen Linux-Treiber mit relativ wenig Aufwand (ja, also, wie gesagt, relativ) ermöglichen würden. Das ist bei Intel nicht so schlimm, weil sie ihre Treiber eh als Open Source veröffentlichen - bei nVidia und ATI ist der Zustand allerdings fatal und sorgt für einen großen Haufen an unnötigem Arbeitsaufwand für die engagierten Entwickler, die für diese Karten einen zumindest mit 2D funktionierenden Open-Source-Treiber schreiben wollen.

Insofern ist diese News ein großer Paukenschlag, der mit einem Mal die komplette Grafikkartenlandschaft verändert - vom Linux- und sonstigen Open-Source-Standpunkt aus betrachtet, versteht sich. AMD/ATI gibt nämlich, nach einem Jahr voller enttäuschter Hoffnungen, die Spezifikationen für sämtliche Grafikkarten der r500- und 5600-Serien frei. Das sind im Prinzip alle mit einem "X" plus Zahl dahinter, und die neueren "HD" und noch was. Also die neueren, die seit zwei oder drei Jahren auf dem Markt sind. Für die älteren gibts eh zum größten Teil schon funktionierende Open-Source-Treiber, für die neuen werden die Linux-Hacker von Red Hat und Novell mit Hilfe der nun veröffentlichten Spezifikationen einen passenden Treiber entwickeln. Wird halt noch ca. ein Jahr dauern (das geht auch so nicht schneller), aber ab dann kann sich jedermann und -frau guten Gewissens eine ATI-Grafikkarte zulegen.

Alle, die also einen Computer mit einer solchen ATI-Grafikkarte haben (sorry Emil), können sich also massiv über weniger Aufwand beim Installieren und weniger Abhängigkeit vom Herstellertreiber freuen. Und alle anderen zucken aus vor Freude, weil mit diesem bahnbrechenden Großereignis die Auswahl an linuxfreundlichen Computern in unbekannte Dimensionen steigt. Mit ein bisschen Glück sieht dann vielleicht auch nVidia ein, dass ihre aktuelle Geheimniskrämereipolitik zu nichts führt, und veröffentlicht ebenfalls die Grafikkarten-Spezifikationen.

So lange der neue Open-Source-ATI-Treiber noch nicht veröffentlicht ist, bleibt also von meiner Seite alles beim Alten (Intel ok, nVidia und ATI ungut). Wer allerdings trotzdem viel Grafikpower zu brauchen glaubt, sollte sich ab jetzt eine AMD/ATI-Karte nehmen. Als Belohnung für die richtige Entscheidung, und weil die Treiber-Situation in absehbarer Zeit viel besser wird, während nVidia weiter die Bösen sind.

Dass nebenbei auch noch eine neue Version des Grafikservers X.org mit der schönen Versionsnummer 7.3 herauskommt, was insbesondere das Ein- und Ausstecken von Beamern ohne Einstellungen und Ärgernisse einfach funktionieren lasst, erscheint dabei schon fast nebensächlich.

:D

So, das ist jetzt der letzte Eintrag für die nächsten paar Tage, damit hab ich mein Pensum wieder mal erfüllt. (Sorry, es gibt so viel zu berichten!) Erfreuliche Ereignisse sind übrigens wieder stark im Kommen, wie man folgenden Artikeln entnehmen kann:

Red Hat veröffentlicht die "Liberation Fonts"

Die Überlegung war, dass Microsoft das Weiterverbreiten der allgegenwärtigen Schriftarten Arial, Times New Roman und Courier New keiner anderen Organisation erlaubt, und deshalb viele von Windows kommende Office-Dokumente unter Linux nicht originalgetreu ausschauen, weil die Schriftmetriken der frei verfügbaren Schriftarten (also der Platz, den die einzelnen Zeichen brauchen) nicht mit den Windows-Schriftarten übereinstimmt.

Also ist Red Hat jetzt hergegangen und hat eine Schriftarten-Firma damit beauftragt, für diese drei Windows-Schriften einen Ersatz mit gleicher Metrik zu erstellen, folglich schauen die Schriften (zumindest für den Laien wie mich) auch aus wie ein exakter Klon von Arial, Times New Roman und Courier New. Im Blog von Daniel Robitaille (Ubuntu-Mensch) gibt's einen Eintrag mit Screenshots der Schriftarten.

Und das ist eine gute Sache, weil jetzt können wir uns nämlich das Nachinstallieren des msttcorefonts-Pakets sparen, das ein Hintertürl nutzt, um rechtlich einwandfrei die Schriften direkt von einem Microsoft-Server zu installieren. Mit Vista haben sie das Hintertürl sowieso abgedichtet, und die neuen Vista-Schriftarten können wir sich woanders hinschmieren.

Wieder eine Abhängigkeit weniger! Man kann annehmen, dass die Liberation Sans, Liberation Serif und Liberation Mono ab der jeweils nächsten Release in allen Distributionen Einzug findet. (Wem das zu langsam ist, der kann sie jetzt auch schon downloaden.) Danke, Red Hat!

"KDE 4.0-alpha1 released: 'Knut'"

Irgendwann kommt die Zeit, da alle Projekte fertig werden müssen, sonst werden sie nie fertig. Für KDE ist nun die Zeit des Fertigmachens angebrochen, und mit der ersten Alpha-Release beginnt der letzte Anlauf zum Stabilisieren und Fertigmachen von KDE 4.0, der dann bis Oktober oder so dauern wird.

Nett dabei ist, dass es auch eine Live-CD gibt, mit der man den derzeitigen Stand von KDE 4 ohne großartige Installation austesten kann, aber nichtsdestotrotz ist es immer noch eine für die Massen ungeeignete Entwicklungsversion, deren Zielgruppe Programmierer und Tester mit dickem Fell sind. Wer sich also mal einen ersten Eindruck verschaffen will, nur zu, aber auf keinen Fall Schlüsse auf die Qualität der endgültigen 4.0er-Version ziehen.

Wie auch immer, es ist gut zu wissen, dass die Entwicklung halbwegs nach Plan verläuft und KDE 4 großartig wie erwartet sein wird. (Inzwischen bin ich Optimist.) Danke, KDE!

"Digitaler Globus: NASA World Wind als Java-Version"

Dass die NASA eine recht fähige Open-Source-Alternative zu Google Earth hat, dürfte sich inzwischen ja schon ein bisschen herumgesprochen haben. Blöd war bisher allerdings, dass es dieses World Wind nur als Windows-Version gab, was für Leute wie mich, dich oder es nur einen sehr beschränkten Nutzen hatte.

Umso erfreulicher, dass das Programm jetzt auf Java portiert wurde, und letzteres dank der "write once, run everywhere"-Philosophie auch auf Linux, Mac OS, Solaris und den diversen BSDs läuft. Ganz zu schweigen davon, dass Java seit Kurzem selber Open Source ist - Jakoblog berichtete :D

Wer also Java-Anwendungen auf seinem Computer ausführen kann, kann sich ab sofort an NASA World Wind erfreuen. Ich hab's noch nicht ausprobiert, und eigentlich brauch ich so ein Zeugs nicht wirklich, deshalb werd ich schier noch warten, bis es in der nächsten Ubuntu-Release komfortabel paketiert wurde und leicht vom Adept aus installierbar ist. Danke, NASA!