Nach Update auf KDE 4.6.2 fährt PC nicht mehr herunter

EDIT: Mit dem am 10.04.2011 veröffentlichten Update von kdebase-workspace auf 4:4.6.2a-0ubuntu1~maverick1~ppa3 wird der Bug behoben.

Stattdessen landet man auf dem Terminal, idR tty1, und wird mit dem Login-Prompt begrüßt. Grund für dieses merkwürdige Verhalten ist ein Bug in den Standardeinstellungen von KDM. Dem shutdown-Befehl wird dabei ein falscher Parameter übergeben, der unter Ubuntu/Debian nicht funktioniert.

Um das Problem einfach zu lösen, muss man über Systemeinstellungen->Anmeldebildschirm im Tab „Herunterfahren“ den Befehl für’s Herunterfahren des Systems auf

/sbin/shutdown -h now

ändern. Danach abmelden und den X-Server neu starten und fortan lässt sich der PC wieder wie gewohnt aus KDE herunterfahren.

KDE 4.6: Drag & Drop im Plasma-Applet „Ordner-Ansicht“ funktioniert nicht mehr

Manchen mag es nach einem Update auf KDE 4.6 genauso gegangen sein wie mir: In der Ordner-Ansicht auf der Arbeitsfläche lassen sich Dateien und Ordner nur noch markieren, aber nicht mehr per Drag & Drop verschieben. Ein ziemlich „nerviges“ Problem.

Mittlerweile ist es lokalisiert und es tritt dann auf, wenn in den Dolphin-Einstellungen „Doppelklick zum Öffnen von Dateien und Ordnern“ ausgewählt ist:

Als Workaround kann man auf „Einfachen Klick“ umstellen oder aber warten, bis ein Update draußen ist. Der Bug wurde nämlich mittlerweile gefixt.

Edit: Just ein paar Stunden später nach Verfassen des Artikels standen für Kubuntu Maverick schon die Update-Pakete zur Verfügung und der Bug wurde behoben!

Recompile all kernel modules using DKMS

With the Dynamic Kernel Module Support (DKMS) framework compiling modules is very comfortable. However, one major drawback is the lack of rebuilding all modules at once. One has to specify each module, each version and each kernel. The following lines let you recompile all modules for the current kernel:

[bash]
for mod in `dkms status | cut -d, -f1 | uniq`;
do for ver in `dkms status | cut -d, -f2 | uniq`;
do dkms remove -m $mod -v $ver -k `uname -r` && dkms build -m $mod -v $ver -k `uname -r` && dkms install -m $mod -v $ver -k `uname -r`;
done;
done
[/bash]

Mit DKMS alle Kernelmodule neu kompilieren

Mit dem Dynamic Kernel Module Support (DKMS) Framework kann man zwar alle Module komfortabel kompilieren lassen, jedoch lassen sich nicht alle Module auf einmal neu kompilieren. Ferner muss jedes Modul und jede Modulversion, inkl. des Kernels jedes mal separat angegeben werden. Die folgenden Zeilen bringen DKMS jedoch dazu, alle Module für den aktuellen Kernel neu zu kompilieren.

[bash]
for mod in `dkms status | cut -d, -f1 | uniq`;
do for ver in `dkms status | cut -d, -f2 | uniq`;
do dkms remove -m $mod -v $ver -k `uname -r` && dkms build -m $mod -v $ver -k `uname -r` && dkms install -m $mod -v $ver -k `uname -r`;
done;
done
[/bash]

Amarok 2.4 doesn’t import all MP3s into collection

If you have updated to Amarok 2.4 you may have noticed that some of your MP3 files are missing in Amarok’s collection. This happens because Amarok seems to be unable to handle MP3s that have an UFID tag. A workaround is to remove the UFID tag. This is done by simply submitting the following command:

[bash]
find -name "*.mp3" -exec id3v2 -r UFID ‚{}‘ \;
[/bash]

After that be sure to do a „Full rescan“ of your collection. Just „Update Collection“ didn’t work for me. Now you should have all your MP3s back in your collection.

Thanks to the KDE community for this solution: http://forum.kde.org/viewtopic.php?f=115&t=93124

Amarok 2.4 importiert nicht alle MP3s in die Sammlung

Wer auf Amarok 2.4 upgedated hat, wird vielleicht bemerkt haben, dass in der Sammlung nicht mehr alle MP3s zu finden sind. Schuld daran ist das UFID-Tag. Irgendwie scheint Amarok damit nicht klarzukommen. Als Workaround hilft es, das UFID-Tag zu entfernen. Relativ simpel geht das mit dem Einzeiler:

[bash]
find -name „*.mp3“ -exec id3v2 -r UFID ‚{}‘ \;
[/bash]

Danach nochmal die Sammlung erneut scannen (nicht aktualisieren!) lassen und es sollten wieder alle MP3s da sein.

Vielen Dank an die KDE-Community für die Problemlösung: http://forum.kde.org/viewtopic.php?f=115&t=93124

Wenn Open Source-Projekte sich auf ihren Lorbeeren ausruhen (Teil 2)

Wie versprochen kommt heute der zweite Teil. Während es im Teil 1 um den Musikplayer Amarok ging, widme ich mich heute dem Open Source CMS Joomla.

Joomla, der einstige Fork des kommerziellen Mambo CMS, hat sich in den letzten Jahren beständig weiter entwickelt. Mittlerweile wird es oft im privaten Bereich eingesetzt und wurde durch positives Feedback aus der Community und durch Preise ziemlich gehätschelt. Das hat dem Projekt wohl nicht so gut getan.

Ich war meinerzeit ebenfalls Joomla-Anwender, was damals vor allem dem Mangel an Alternativen geschuldet war. Die Einführung von Joomla 1.5 erschien viel versprechend und so habe ich es auch für den professionellen Einsatz verwendet. Das stellte sich im Laufe der Zeit jedoch als großer Fehler heraus. Mir wurde in dieser Zeit bewusst, dass ein ordentliches Qualitätsmanagement (QM) auch für Open Source-Software unabdingbar ist. Doch ein QM war bei Joomla nicht vorhanden, was sich einmal mehr als bemerkbar machte:

Mit Version 1.5.13 kam ein kritisches Sicherheitsupdate heraus. Die Empfehlung war natürlich, sofort ein Update durchzuführen. Gesagt getan und gleich bereut, denn mit dem Update wurden zwei Bugs eingeführt, die die Benutzung des Systems nahezu unmöglich machten. Ok, es kann ja mal passieren, dass Bugs durch ein Update eingeführt werden. In dieser Situation hofft man, dass danach gleich ein zweites Update nachgeschoben wird, dass die Bugs ausmerzt. Die Probleme waren dem Entwicklerteam bekannt, doch es geschah nichts.

Was waren also die Alternativen? Ein Downgrade und damit riskieren, dass die Sicherheitslücke ausgenutzt wird oder beim Update bleiben und ein kaputtes System haben? Erinnert an die Wahl zwischen Pest und Cholera. Denn die Sicherheitslücke war wirklich gravierend:

Tiny browser included with TinyMCE 3.0 editor allowed files to be uploaded and removed without logging in. (Quelle)

Erst nach langen acht Tagen kam das ersehnte Update.

This release contains fixes for two material bugs that were introduced in version 1.5.13 and one low level security issue. Instead of waiting for a normal 6 to 8-week release cycle, this release is being made available to users now. It has been eight days since Joomla 1.5.13 was released on July 22, 2009.

Beim Lesen dieser Ankündigung fielen mir fast die Augen aus. Vielleicht bin ich da ein bisschen anfällig oder habe zu hohe Ansprüche. Aber mal ehrlich: Der User steht vor der Wahl zwischen Pest und Cholera, was mein Fehler war und muss acht Tage auf ein Update warten und dann brüste ich mich damit, dass ich aus dem normalen Release-Zyklus ausbreche, frei nach dem Motto „Ihr könnt euch glücklich schätzen, dass ihr das Update jetzt kriegt und nicht erst in 6-8 Wochen“. So geht’s nicht! Leider war es nicht das einzige Mal, dass ein Update mehr Probleme verursachte, wie das es Probleme behob.

Doch das war nicht die einzige Enttäuschung. Im Einsatz waren auch Plugins, deren Entwickler die selbe Mentalität an den Tag legten. Einige dümpelten Jahre nach Veröffentlichung von Joomla 1.5 noch im Kompatibilitätsmodus herum. Professionelle Einstellung: Fehlanzeige. Kaum ein Plugin funktioniert ohne Eingriff in den Code. Oftmals wurden Plugins mit falschen Features angepriesen und waren derart schlampig programmiert, dass einem schlecht wurde. Es konnte ja jeder einfach ein Plugin im Repository veröffentlichen, ein QM, dass ein Mindestmaß an Funktionalität und Sicherheit erfordert, existiert(e) ja nicht.

Joomla hatte viel Potenzial, ein gutes CMS zu werden, das man hätte auch professionell einsetzen können. Doch stattdessen verzichtete man auf ein ordentliches QM und auch die Entwickler einiger Plugins machten es nicht anders. Einige widersetzten sich diesem Trend. So war FacileForms eine richtig professionelle Extension. Doch dann entschied dessen Entwickler sein Engagement für Joomla einzustellen. Die Gründe kann man auf seiner Website nachlesen. Kritikpunkte, die ich mit ihm teile. Genau wie er entschied ich mich zur selben Zeit, mich von Joomla zurückzuziehen und nach einem anderen CMS umzuschauen.

Ich möchte nicht falsch verstanden werden, ich weiß, dass es sich bei Open Source oft um freiwillige Projekte handelt und man nicht die Maßstäbe kommerzieller Produkte anlegen kann. Doch diese Maßstäbe sollten das Ziel sein. Potenzial ist oft da, es wird nur nicht richtig genutzt. Oder man verfällt aufgrund der bisherigen Erfolge in Lethargie und ruht sich auf den Lorbeeren aus. Das tut dem gesamten Projekt nicht gut und rächt sich irgendwann.

RT2870 compile error under (K)Ubuntu Maverick (10.10)

Yesterday the next version of Ubuntu was released. It comes with kernel 2.6.35 which can make problems if you want to compile the RT2870 driver provided by Ralink. The reason for me to compile the driver rather than using the one shipped with the kernel is that the latter reduces my WLAN speed from 130 MBit/s to 54 MBit/s.

If you start compiling the Ralink driver you will soon get the following error message:

CC [M]  2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.o
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c: In function ‘RTMPAllocUsbBulkBufStruct’:
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c:52: error: implicit declaration of function ‘usb_buffer_alloc’
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c:52: warning: assignment makes pointer from integer without a cast
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c: In function ‘RTMPFreeUsbBulkBufStruct’:
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c:78: error: implicit declaration of function ‘usb_buffer_free’
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c: In function ‘RTMPFreeTxRxRingMemory’:
make[2]: *** [2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.o] Error 1
make[1]: *** [_module_2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-2.6.35-22-generic'
make: *** [LINUX] Error 2

The cause for these errors is that the driver makes use of the functions usb_buffer_alloc() and usb_buffer_free() which got renamed in kernel 2.6.35. This is stated in the Changelog:

    USB: rename usb_buffer_alloc() and usb_buffer_free() users

    For more clearance what the functions actually do,

      usb_buffer_alloc() is renamed to usb_alloc_coherent()
      usb_buffer_free()  is renamed to usb_free_coherent()

So to get rid of the error messages all you have to do is to rename the function in include/os/rt_linux.h. To make it easier you can download a patch here. Just run the following command in the driver directory:

patch -ul -p0 -i path/to/patch

Or use the one-liner:

wget -qO- http://www.linuxcrew.de/wp-content/uploads/2010/10/rt2870sta_usb_kernel2635.patch | patch -ul -p0

After patching you can compile the driver without errors again.

RT2870-Kompilierungsfehler unter (K)Ubuntu Maverick (10.10)

Gestern wurde die neue Version der beliebten Linux-Distribution veröffentlicht. Mit im Gepäck der Kernel 2.6.35. Wer wie ich im Besitz eines WLAN-Sticks mit dem RT2870-Chipsatz ist, stellt das erst mal vor Probleme. Ich nutze nicht den mitgelieferten Treiber rt2870sta, da dieser meine WLAN-Übertragung von 130 MBit/s auf 54 MBit/s drosselt.

Abhilfe schafft da den aktuellsten Ralink-Treiber zu kompilieren, was aber mit dem neuen Kernel 2.6.35 zu folgendem Fehler führt:

CC [M]  2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.o
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c: In function ‘RTMPAllocUsbBulkBufStruct’:
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c:52: error: implicit declaration of function ‘usb_buffer_alloc’
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c:52: warning: assignment makes pointer from integer without a cast
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c: In function ‘RTMPFreeUsbBulkBufStruct’:
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c:78: error: implicit declaration of function ‘usb_buffer_free’
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c: In function ‘RTMPFreeTxRxRingMemory’:
make[2]: *** [2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.o] Fehler 1
make[1]: *** [_module_2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux] Fehler 2
make[1]: Verlasse Verzeichnis '/usr/src/linux-headers-2.6.35-22-generic'
make: *** [LINUX] Fehler 2

Schuld daran ist der Rückgriff auf die Funktionen usb_buffer_alloc() und usb_buffer_free(). Diese wurden umbenannt, was sich auch der Changelog des Kernels entnehmen lässt:

    USB: rename usb_buffer_alloc() and usb_buffer_free() users

    For more clearance what the functions actually do,

      usb_buffer_alloc() is renamed to usb_alloc_coherent()
      usb_buffer_free()  is renamed to usb_free_coherent()

Alles was man also tun muss ist die entsprechenden Funktionen in der include/os/rt_linux.h umzubenennen. Einen entsprechenden Patch könnt ihr hier runterladen. Einfach folgendes Kommando im Treiberverzeichnis ausführen:

patch -ul -p0 -i pfad/zur/patchdatei

Oder bequem per Einzeiler:

wget -qO- http://www.linuxcrew.de/wp-content/uploads/2010/10/rt2870sta_usb_kernel2635.patch | patch -ul -p0

Danach lässt sich der Treiber wieder problemlos kompilieren.

Wenn Open Source-Projekte sich auf ihren Lorbeeren ausruhen (Teil 1)

Heute ist mal Zeit, sich mit etwas Negativem zu beschäftigen, was auch vor Open Source-Projekten keinen Halt macht. Man kann es vielfach betiteln: Überheblichkeit, Hochmut oder aber sich auf seinen Lorbeeren ausruhen.

Es geht mir speziell um zwei Projekte, bei denen ich vermute, diese „Krankheit“ diagnostiziert zu haben. Das ist zum einen der Musikplayer Amarok, zum anderen das CMS Joomla. Aber der Reihe nach. In Teil 1 geht es um den (noch) beliebten Musikplayer Amarok.

Amarok

Amarok war der beste Musikplayer, den es für Linux gab. In seiner Version 1.4 war einfach alles drin, was man sich denken konnte. Er war benutzerfreundlich und herrlich durchdacht in seiner einfachen Anwendung.

Ich benutze hier bewusst die Vergangenheit, denn nach 1.4 kam 2.0 und es war vorbei mit allem. Plötzlich hatte mein ein Stück rudimentäre Software in den Händen, das fragil war und in seiner Benutzerführung seltsam anmutete. Dachte man anfänglich noch, dass sich das bis zur Version 2.1 wieder einkriegt, so wie es seinerzeit bei KDE 4.0 war, so wurde man mit Erscheinen der Version 2.1 doch eines Besseren belehrt. Alte Funktionen aus 1.4 blieben weiterhin verschollen und neue „Spielereien“ hielten Einzug. Lange musste man gar auf die iPod-Unterstützung warten. Selbst globale Hotkeys blieben verschollen.  Meta + X, das einen Song erneut von Anfang startet, war einfach nicht mehr implementiert. Warum?

Ich weiß nicht, wie oft ich mich das gefragt, mich gewundert oder geärgert habe. Warum hat man überhaupt darauf verzichtet, alle Funktionen von 1.4 erst zu portieren und dann alles weiter zu entwickeln? 1.4 war ein Player für die Massen, ausgereift und solide, mit viel Erweiterungsmöglichkeiten. Diese Entscheidung habe ich bis heute nicht nachvollziehen können. Die Moral von der Geschichte war jedenfalls für mich immer die selbe. Weg mit Version 2.X und willkommen 1.4. Zum Glück gab es genug Möglichkeiten, Amarok 1.4 für die aktuellen Ubuntu-Versionen zu installieren (PPA, Kompilieren). Hätte es diese Möglichkeit nicht gegeben, wäre ein Großteil der (Ubuntu-)Amarok-Gemeinde sicher verzweifelt.

Der Aufschrei der Gemeinde war jedenfalls groß. Egal bei welchem Release, die User-Kommentare zu den Ankündigungen sprachen Bände. Es wurde bemängelt, empfohlen und seinem Ärger Luft gemacht.

Was taten nun die Entwickler? Sie blieben ihrer Linie treu. Keine bis schleppende Portierung alter Funktionen aus 1.4, dafür immer neuer Schnickschnack und weitere Gimmicks, die kaum einer braucht.  In der Wirtschaft nennt man so etwas „am Kunden vorbeientwickeln“. Dort hat es nicht häufig zur Konsequenz, dass Unternehmen Einbußen hinnehmen müssen. Mitunter existenzbedrohende. Beispiele dafür gibt es genug. Wie verhält es sich nun bei Open Source-Projekten? Nun, da fließt kein Geld, aber es fließen Nutzer und zwar weg! Im schlimmsten Fall kann es aber auch hier das Aus bedeuten. Bei Amarok kam es meiner Meinung nach nicht so weit, weil es möglich war, weiterhin Version 1.4 zu benutzen, ohne irgendwelche Einbußen hinnehmen zu müssen.

Die Entwickler von Amarok scheinen jedenfalls immer noch jeglichen Kontakt zu ihren Usern verloren zu haben, was bezeichnenderweise auch folgendes Zitat verdeutlicht:

We have lately received quite a lot of requests for a cross-fading feature, so I think we’ll move this higher on our priority list. Maybe we can get it done in cooperation with the Phonon developers (which consists partly of Amarok developers anyway).

Stay tuned 🙂

Quelle: http://amarok.kde.org/en/releases/2.3.2#comment-13320

Ich weiß nicht, wie oft ich den Wunsch nach Cross-fading in Kommentaren und Foren etc. schon gelesen habe. Abgesehen davon, liebe Leute: Ist es so abwegig, einen Player mit Cross-fading auszustatten? An dieser Stelle frag ich mich dann immer, ob den Entwicklern denn überhaupt noch bewusst ist, dass es dort draußen eine Menge User gibt, die Software nutzen wollen. Es ist ja nicht so, dass diese sich nicht äußern. Kann man also so blind durch die Gegend gehen? Man braucht ja nur die Kommentare zu den Ankündigungen zu lesen, um sich ein Bild zu machen.

Es wird dringend Zeit, wieder den Kontakt zu den Usern herzustellen. Was nützt mir die Entwicklung einer Software, die keiner nutzt. Da kann ich mich noch so ins Zeug legen und „tolle“ Funktionen implementieren. Es ist ja noch so, dass es keine Alternativen zu Amarok gäbe.

Vor zwei Tagen gab es nun endlich ein kleiner Lichtblick. Mit der Veröffentlichung von Version 2.3.2 kehren weitere 1.4-Features zurück und ein Umstieg könnte sich nun endlich lohnen. Auch wenn die Benutzerführung weiterhin nicht als ausgereift angesehen werden kann. Ich hoffe jedoch, dass das noch verbessert wird und Amarok zu seiner alten 1.4-Stärke zurückkehrt. Ich bin nicht der einzige, der auf Version „1.5“  wartet, auch wenn die bei den Entwicklern wohl eher die Versionsnummer 3.6 tragen wird.

Weiter geht’s in den nächsten Tagen mit Teil 2 und Joomla.