Der Ubuntu-Wochenrückblick braucht dich!

Eigentlich ist es kaum verwunderlich, dass der als Community-Projekt aufgezogene Ubuntu-Wochenrückblick mal wieder vor dem Aus steht. Bei seinen beiden Vorgängern war es ja nicht anders und der Grund ist immer der Gleiche gewesen: Die Mitarbeit der Community ist bald mit jeder Ausgabe rückläufig. Meist rettet man dann die folgende Ausgabe durch einen Aufruf, von Dauer ist das dann aber auch nicht.

Im Folgenden ein paar schnelle unausgegorene Gedanken zur Verbesserung der Situation:

Wahrscheinlich wäre es wohl wesentlich effektiver die Community als größten Contributor fallen zu lassen und mehr auf ein festes und vor allem größeres Team zu setzen.

Eine kleine Auswahl von Helfern, die derzeit gesucht werden, die Mathias in seinem Blog gepostet hat:

Was der UWR zum Überleben braucht:

• Helfer, die Links mit kurzen Zusammenfassungen versehen
• Helfer, die beim Übersetzen und korrigieren mitwirken
• Helfer & Team-Mitglieder, die regelmäßige Tätigkeiten (Erstellung neuer Wiki-Seiten, Moderieren des Forum, Veröffentlichung, Pflege des Bereichs im Wiki…) wahrnehmen und dem UWR den letzten Feinschliff vor der Veröffentlichung verpassen
• Einen oder mehrere Team-Mitglieder, die all das koordinieren (sozusagen Teamleiter)

Das ist eine ganze Menge Holz, die vor allem aber auch notwendig ist um die Lasten zu verteilen. Wie oben erwähnt würde ich nicht mehr auf Helfer setzen, sondern auf feste Team-Mitglieder. Könnte mir gut vorstellen, dass sich durch die freiwillige Verpflichtung mehr ergibt.

Daniel Holbach veröffentlicht alle Tage lang Einträge, Videos über Wege wie man Patches einbringt. Soetwas in der Art könnte ich mir auch gut für den UWR und Ikhaya vorstellen, sodass die Leute regelmäßig erfahren, dass sie und auch wie sie Nachrichten in den UWR und Ikhaya bringen können.

Es ist eben ein ganzer Batzen Arbeit, der da im Moment an wenigen hängt und der nur sehr wenig gewürdigt wird. Auch ich glänze nicht mit Beiträgen zum UWR, worüber ich mich ganz und gar nicht freue. Wenn der Feedreader auf Vordermann gebracht ist, werde ich zusehen regelmäßig dabei zu sein und das solltet ihr vielleicht auch tun

In diesem Sinne wünsche ich noch fröhliche Weihnachtsfeiertage!

Flash-Müll mit Cron entfernen

Alle Welt redet über Cron und was es so schöne Sachen kann. Ich hatte es bis jetzt immer erfolgreich vermieden mich mit Cron zu beschäftigen.

Angeregt von Rorschachs etwas in die Kritik geratener Uhrzeit-Synchronisierung per Anacron habe ich mir daher ein kleines Skript geschrieben, um die unerwünschten Überreste des Flash-Players von Adobe zu entfernen, die durch dessen Benutzung entstehen:

$ cat /etc/cron.daily/cleanFlash
#!/bin/sh
#
# This script deletes Flash Player garbage files.
# settings.sol won't be deleted.
#
/bin/rm -R $(/usr/bin/find /home/*/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys/ -type d ! -name "*sys")
/bin/rm -R $(/usr/bin/find /home/*/.macromedia/Flash_Player/#SharedObjects -type d ! -name "*#SharedObjects")


Das Ganze in /etc/cron.daily gestopft und es sollte Ruhe sein. Die Einstellungen des Players bleiben dabei erhalten.

Endlich einfaches Host Interface Networking

Eben habe ich etwas durch das Handbuch des gestern erschienenen VirtualBox 2.1 geblättert und mir sind beinahe die Augen aus dem Kopf gefallen.

Ich konnte im Abschnitt über Host Interface Networking keine Bash-Befehle mehr entdecken. Also habe ich mal genauer nachgelesen und tatsächlich:

Host Interface Networking works has been completely rewritten with VirtualBox 2.0
and 2.1, depending on the host operating system. From the user perspective, the main
difference is that complex configuration is no longer necessary on any of the supported
host operating systems. (Abschnitt 6.5 Seite 81)

Um die virtuelle Maschine an das lokale Netzwerk anzuschließen genügt es nun, in der Netzwerk-Konfiguration Host Interface statt NAT und das zu verwendende Netzwerk-Interface des Hosts (normalerweise eth0) auszuwählen.

Einfach sagenhaft!

bzr upload spart Zeit und Traffic

Über die bessere Versionsverwaltung, wie Subversion, Mercurial, git und wie sie alle heißen, lässt sich sicherlich streiten. Derzeit nutze ich allerdings vornehmlich Bazaar. Einige kennen es wahrscheinlich von Launchpad, wo es als Versionsverwaltung von den einzelnen Projekten eingesetzt wird. Auch bekannte Projekte wie apt oder mailman nutzen bereits Bazaar für ihre Versionsverwaltung.

Für mich zeichnet sich Bazaar vor allem aus zwei  Gründen besonders aus:

1. Es benötigt keinen Server, der das Repository verwaltet und

2. Bazaar spricht als einzigstes mir bekanntes VCS ftp.

So kann man jeden beliebigen Webspace mit FTP-Zugang für seine Versionsverwaltung missbrauchen.  Auf den FTP-Server wird dabei nur der Branch, aber keine Klardaten abgelegt. Die richtigen Zugriffsrechte gesetzt und die Daten sind nicht via HTTP abrufbar (mein Hoster hatte das schon erledigt). Je nach Daten könnte das nützlich sein.

Die Bazaar User Reference bietet eine umfassende Übersicht, für Ungeduldige gibt es das Mini-Tutorial.

Um aber auf den Titel zurückzukommen: Für Bazaar gibt es ein kleines Plugin namens bzr-upload. Es erweitert die Funktionalität von Bazaar um eine Upload-Möglichkeit für die Klardaten der aktuellen Revision. Nach einem Commit ausgeführt werden nur die seit dem letzten Upload geänderten Dateien auf den Webspace geladen.

Webauftritte lassen sich damit wunderbar verwalten und es ist jedesmal ein Genuss diesen Befehl zu verwenden, wenn man viele Dateien in diversen Ordnern verändert hat.

Intrepid bringt schon ein fertiges Paket gleichen Namens mit. Unter Hardy muss man es sich per Hand installieren, wobei man lieber die letzte Version aus dem Launchpad-Branch verwenden sollte. Die Version, die auf der Bazaar Homepage angeboten wird, läd Dateien noch mit festgelegten Rechten hoch, was zu Problemen führen kann und auch tut. Die Installation erfolgt dann wie auf der Bazaar Homepage beschrieben.

Wenn man nicht jedesmal das Passwort des FTP-Servers eintippen mag, kann man dies in der Datei ~/.bazaar/authentication.conf wie in der User Reference beschrieben festlegen. Leider ist die in der Readme des Plugins beschriebene auto-Funktion nicht verfügbar – wahrscheinlich gab es damit ein paar Probleme. Alles in allem aber eine sehr nützliche Erweiterung.

Ich sollte öfter ins Wiki schauen…

Ein Problem, das mich schon seit Monaten gequält hat, scheint nun endlich gelöst. Der Quälgeist war der bekannte prop. Nvidia-Treiber. Seit Hardy, wenn mich meine Erinnerungen nicht betrügen, hatte der Treiber die seltsame Eigenschaft, direkt nach der Installation zu funktionieren und nach einem Neustart seinen Dienst zu versagen. Was mir natürlich erst neuerdings auffiel, war, dass dieser Fehler nur auftrat, sollte man es gewagt haben, den Treiber direkt von Nvidia zu beziehen.

Während Hardy aktualisierte ich in der Hoffnung, der Fehler würde bald gefixt, regelmäßig den Treiber, gab es doch die letzten Tage in sehr kurzen Abständen sehr viele Bugfix-Releases seitens Nvidia. An einen Konflikt dachte ich erst gar nicht, da das Problem immer nur recht zufällig aufzutreten schien. Nach der Aktualisierung auf Intrepid, noch während der Beta-Phase, war das Problem urplötzlich verschwunden. Natürlich hatte ich das Ubuntu-Paket des Treibers installiert, wie mir jetzt erst bewusst wurde.

Im Zuge meines Downgrades auf Hardy war mir der Treiber in den Repos wieder mal zu alt und ich installierte die aktuellste Version. Das Problem trat natürlich wieder auf, nur dieses mal sehr regelmäßig. Um genau zu sein, nach jedem Reboot. Irgendwann wurde mir das dann doch zu viel und ich deinstallierte den Treiber und versuchte den Treiber aus den Repos zum Laufen zu bringen, was wiederrum nicht klappte. Ursache war eine unsaubere Mixtur aus Nvidia-Treiber, Repo-Treiber und den linux-restricted-modules. Also alle deinstalliert und den Repo-Treiber installiert, dann ging er endlich.

Heute zog es mich doch aufgrund einiger Bugs wieder zu einem neueren Treiber, wieder das gleiche Problem. Schließendlich stellte ich fest, dass es sich durch Deinstallation der restricted-modules beheben ließ. Scheinbar bestand hier der Konflikt, denn das Modul für den Repo-Treiber war in genau diesem Paket. Das alte Modul wurde geladen und konnte mit den neuen Treiber-Dateien nichts anfangen. Das neue Modul ließ sich dann scheinbar nicht laden, spuckte aber auch keinen Fehler in der Konsole aus.

Zu einfach wäre es gewesen, wäre das schon die Lösung. Jetzt ging meine Wlan-Karte nicht, denn die läuft mit dem prop. Treiber von Broadcom. Ein Neubau der restricted-modules in meinem PPA kam mit 150MB Quellpaket auch nicht in Frage.

Lange Rede, kurzer Sinn. Es besteht die Möglichkeit einzelne Module aus den linux-restricted-modules nicht zu laden. Dazu muss man in der Datei /etc/default/linux-restricted-modules-common folgende Eintragung machen: DISABLED_MODULES="nv" Damit werden dann gleich alle drei Treiber (legacy, glx, glx-new) deaktiviert.

Und der Treiber lief nach dem Neustart!

Und natürlich schaue ich ins Ubuntuusers Wiki und stelle fest, dass ich nur vorher hätte mal hinein schauen müssen. Aber was wäre das Leben ohne solche Geschichten…

Flash 10 x86_64 Prerelease unter Hardy

Im Zuge meines Umstiegs auf Hardy steht nun die Aktualisierung/Installation einiger Anwendungen an, darunter auch Adobes Flashplayer, der jüngst für 64-Bit Linux-Systeme in einer frühen Alpha veröffentlicht worden ist.

Installiert war das Flash-Plugin noch von meiner Intrepid-Installation. Insofern hätte es im besten Falle eigentlich problemlos funktionieren müssen. Wie hätte es auch anders sein sollen, tat es das nicht. Flash-Videos bestanden hauptsächlich aus Rucklern in Bild und Ton. Das Problem ließ sich dann relativ schnell auf einen alten Bekannten zurückführen und beheben:

sudo apt-get install libflashsupport

Bisher läuft wider Erwarten alles problemlos und dem ungetrübten 64-Bit „Flash-Genuss“ steht nun auch unter Hardy nichts mehr im Wege. Im Adobe Bug System scheint das Problem an sich bekannt zu sein, auch wenn ich keinen Report speziell für diesen Fall entdecken konnte. Eventuell kann ich mich im Laufe des Tages ja noch dazu durchringen mich dort zu registrieren und das Problem zu melden, auch wenn es nur zu Resonanz-Zwecken ist.