Linux

Tja, da melde ich mich zurück aus der Blog-Eiszeit hier, und ich hoffe, hier in Zukunft wieder mehr und häufiger berichten zu können. Das Thema dieses Beitrags ist auch gleichzeitig der Hauptgrund, der mich in den letzten Monaten von einem regelmäßigen Bloggen abgehalten hat: das SEP. SEP steht für Softwareentwicklungspraktikum und jeder Informatikstudent der TU durchläuft dieses irgendwann einmal. So auch ich im vierten Semester, das jetzt zumindest vorlesungs- und praktikums-, aber noch nicht prüfungsmäßig abgeschlossen ist.

Beim SEP setzen Studenten Softwareprojekte, die von den Instituten der Informatik vergeben werden, in Teams von mehreren Studenten um.
Ich habe hierbei mit Stephan, Henning und Oli ein “Ad-Hoc-Chatsystem für mobile Netze” beim IBR (Institut für Betriebssysteme und Rechnerverbund) umgesetzt. Parallel haben dies noch drei weitere Gruppen, ebenfalls bestehend aus jeweils vier Leuten, getan.

Die Wahl auf dieses Thema fiel bei uns aus zwei Gründen: Zum einen reizte uns die Problemstellung. Ich programmiere gerne Software, die Probleme löst, für die es praktisch noch keinen verbreiteten Lösungsweg gibt, wo man also beim Programmieren Probleme lösen muss, für deren Lösung noch keine “Handlungsanweisung” existiert, wie z. B. beim mittlerweile trivialen, weil gut erforschten Sortieren bis hin zur stumpfen Programmierung einer Benutzeroberfläche. Letzteres fiel bei uns natürlich auch an, es hat aber bei weitem nicht einen Großteil der Lösung ausgemacht.
Zum anderen war dieses Projekt das einzige, bei dem eine freie Wahl der Programmiersprache möglich war. Henning und Stephan wollten ihr SEP-Projekt unbedingt in Haskell, einer funktionalen Programmiersprache, absolvieren, und auch Oli und ich hatten durch die Indoktrination der beiden immer wieder einmal die Reize dieser Programmiersprache kennen gelernt. Und letztendlich konnten wir auch beim Institut die Überzeugung wecken, dass es in Haskell zu schaffen ist, und dass wir auch wissen, wovon wir reden
Die anderen drei Gruppen haben das ganze zwei Mal in Java und einmal in C++ umgesetzt.

Die Aufgabenstellung

Detailliert bedeutete das Projekt für uns, dass wir ein gegebenes Protokoll umsetzen, also implementieren sollten, das speziell für die Verwendung in Ad-hoc-Netzen entwickelt wurde - also Netzwerken (in der Regel WLAN) ohne bestehende Infrastruktur, wie Access Points oder Server, und mit starken Fluktuationen in der Struktur. Gegeben war hierzu ein Internet-Draft, der verschiedene Grundprinzipien des Protokolls (Sicherheit, Wegefindung, etc.) und das Protokoll an sich, also die einzelnen Nachrichten spezifiziert.

Der Entwicklungsprozess

Der Entwicklungsprozess folgte dabei dem Wasserfall-Modell in all seinen Details. Jede der Phasen war mit einem Abgabetermin für Dokumente und/oder Code abgeschlossen, und die Ergebnisse wurden in einem Projekttreffen aller Gruppen präsentiert.
Dies hieß nun für uns, dass wir die ersten fünf bis sechs Wochen damit verbrachten, Anforderungen, Anwendungsfälle (sog. Use Cases) und Geschäftsprozesse herauszuarbeiten, die das Verhalten unserer Software beschreiben. Um diesen Anforderungen gerecht werden zu können, wurde dann eine Softwarearchitektur und schließlich die detaillierte Realisierung der einzelnen Komponenten spezifiziert. Nebenbei entstanden in unserer Gruppe auch schon die ersten Code-Schnipsel, meist Proof-of-Concepts, also kurze Prototypen einzelner Funktionalitäten.

Die Implementierung

Nach der Entwurfsphase ging es dann in die Implementierung. In dieser Phase werkelten wir oft bis spät in die Nacht an unserem Code, des öfteren jeder für sich an seinen Komponenten, manchmal auch bei Treffen unserer Gruppe alle zusammen. Es gab oft (auch hitzige) Diskussionen, entweder, wenn man sich im parallel laufenden Vorlesungsbetrieb gesehen hat, oder aber auch in unserem eigens gegründeten IRC-Channel, denn nicht nur sollte unsere Implementierung schön in jedem Aspekt werden (und nicht nur “irgendwie” hingefrickelt, dass es passt), sondern wir hatten uns auch die ein oder andere Bürde selbst auferlegt: Jedwede gespeicherte Daten im Programm sollten nicht redundant geführt werden, begonnen bei der internen Nachrichten-Struktur bis hin zu den verschiedenen Info-Modulen, die Informationen über Benutzer und das Netzwerk verwalten. Ein weiterer Punkt war, dass die Benutzeroberfläche einfach und (relativ) intuitiv zu benutzen sein sollte. Und so gab es einige Punkte, die wir haben wollten, weil wir sie für eine schöne Umsetzung für unabdingbar hielten.

Natürlich galt es bei der Implementierung neben den scheinbar für jedes Projekt symptomatischen Zeitproblemen auch das ein oder andere vorher nicht erwartete Problem zu umschiffen: So taten sich noch einige Spezifizierungsfehler im Protokoll auf, die teilweise durch eine Revision des Drafts behoben wurden, teilweise aber auch von uns einfach durch Einigung auf einen Standard mit den anderen Gruppen gelöst wurden.

Letztendlich war es dann aber doch geschafft und das Programm war fertig. So weit, so gut, doch nun ging es in ...

Die Testphase

In der Testphase wurde die geschriebene Software auf Herz und Nieren getestet. Das hieß, dass wir zum Teil einzelne Komponenten und zum Teil auch das Verhalten der Software ausführlichst auf Korrektheit überprüft haben. Hat man hierfür noch kleine Testprogramme schreiben können, oder kleine Netzwerkstrukturen selbst mit dem eigenen Programm aufgebaut, war der weitaus größere Brocken die Interoperabilitätstests. Bei diesen Tests wurde die fehlerfreie Zusammenarbeit unserer Software mit der der anderen Gruppen geprüft. Und hier taten sich die weitaus größeren Probleme auf: An der einen Stelle hat die eine Gruppe das Protokoll anders interpretiert, an der anderen Stelle waren bestimmte Vorgänge noch fehlerhaft, teilweise gab es Fehler, die bei zwei Instanzen des gleichen Programms nicht auftraten, wohl aber bei der Kommunikation mit einem anderen Programm.

Der Endspurt

Nachdem wir nach vielen, vielen Tests, aber bei weitem nicht allen möglichen auch diese Phase abgeschlossen hatten, bauten wir die finalen Versionen der Software zusammen, aktualisierten noch einmal die letzten Dinge in den Entwürfen und verfassten ein Benutzerhandbuch zur Software. Dann sollte unser Projekt “nur” noch abschließend präsentiert werden. Hierzu wurde noch ein DIN-A0-Poster erstellt, und ein Flyer gedruckt, und damit bewaffnet ging es dann auf den alljährlichen TU-Day, unser “Campus-Fest”, bei dem allerlei interessante Projekte und ähnliches vorgestellt werden, und abschließend zum “Tag der neuen Softwareentwickler”, einem Nachmittag, an dem alle am SEP teilnehmenden Gruppen im Mittelpunkt standen und die Ergebnisse der letzten drei Monate Arbeit präsentierten - zunächst nur einem universitätsinternen Publikum, später aber auch der interessierten Öffentlichkeit, wie z. B. Vertretern von IT-Firmen.

Noch mehr Informationen

Wer jetzt noch mehr wissen möchte oder einfach sich für das Programm interessiert, den lade ich herzlich auf unsere Projekt-Homepage ein. Dort gibt es neben sämtlichen Dokumenten, wie Entwürfen, Präsentationsmaterialien, etc. auch die finalen Versionen vorcompiliert und als Quellcode zum Download. Veröffentlicht wird der Code übrigens unter der GPL in Version 3. Es gibt dort bei Interesse auch einen Link zum Institut und von dort weiter zu den anderen Gruppen.

Und zuguterletzt gibt es auch noch Fotos vom “Tag der neuen Softwareentwickler” zu bestaunen.

I searched for a long time for a convenient way to minimize Thundirbird into the tray under Gnome. Thunderbird itself does not offer this option.

The first try was to use the extension moztraybiff. moztraybiff utilizes the standard systray as specified by freedesktop.org thus supporting Gnome, KDE and IceWM. moztriffbay shows additionally to the “normal” Thunderbird window a systray icon that is also able to indicate new mails. The problem I had was that the Thunderbird was still in the taskbar and the window list when switching windows via Alt-Tab.

So I looked for another approach and found kdocker. kdocker is able to minimize any application to the systray of Gnome, KDE, XFce, fluxbox, ... . Unfortunately it depends on qt, so you might not like it when pou have to pull in qt just to use kdocker. To use kdocker with Gentoo Linux and then Gnome (my personal favorites), this is the way:
Download the ebuild for kdocker and place it in your portage overlay. For a detailled manual how to do this see this article in the Gentoo Wiki. There is only one pitfall you have to take care of: The ebuild was saved with windows newlines that at least cause errors with recent testing portage versions. So just run this command first before starting with the above howto:

Then the ebuild will be ready. After you installed kdocker, you can add the command kdocker -e -b -l thundirbird to your Startup Programs in Preferences - Sessions. This will automatically launch thunderbird at gnome startup. From now on, thundirbird lives in your systray as desired.

The disadvantage of this solution is, that there is no notification of new mails and that you cannot use the close button of the Thunderbird window to minimize it to the systray (as you might be used to in other applications) since this closes Thunderbird and kdocker. Just use the minimize button instead.

I had a problem for a long time that prevented me from watching any videos or DVDs under Linux on my laptop. Now I found a solution and I want to share it. The videos that I played with MPlayer were distorted in a strange way that was obviously caused by my weird resolution of 1280x800 pixels which is a ratio of 16:10. The solution for mplayer is as simple as efficient: Just add this line to your ~/.mplayer/config:

Now everything should work as you expect it.

Ich mag es nicht, wenn Software so tut, als sei sie intelligenter als ich. Aktuell habe ich das so bei Gnome erfahren. Erläuternd dazu sei erwähnt, dass sog. “Templates” bei der (professionellen) Webseiten-Entwicklung in der Regel eine wichtige Rolle spielen. Und in der Regel enden diese auf .tpl. Templates sind HTML-Vorlagen, die z. B. durch PHP-Skripte dynamisch mit Inhalten gefüllt werden.

Versucht man in Gnome jetzt so eine Datei in nautilus zu öffnen, erhält man folgende schöne Meldung anstatt des Editors:

D. h. die Dateiendung sagt Gnome, die Datei wäre ein “tpl Document”, während die Dateianalyse ergeben habe, sie wäre ein “plain text document”. Aha. Aber das beste ist, dass ich nur “Cancel” anklicken kann. Oder ich wähle den Umweg über Rechtsklick - “Open with” - “gVim” – viel zu umständlich ... . Oder ich ändere die Endung in .txt, was aber keinen Sinn macht.
Ein Weg, diese Meldung zu deaktivieren, oder Gnome das richtige beizubringen, war nicht sofort ersichtlich.

Also habe ich lange, lange nach einer Lösung gesucht, denn diese Fehlermeldung hat mich stark bei meiner täglichen Arbeit behindert, und über Umwege über .local/share/mime/packages/Override.xml (die sollte man in solch einem Fall benutzen - laut irgendeinem Blog) auch gefunden: Unter “Applications” - “Settings” - “File types and programs” habe ich einfach zu den MIME-Typen text/html, text/plain und text/xml (als solche werden die Templates immer erkannt - je nachdem was in ihnen steht) die Dateiendung tpl hinzugefügt, ein killall nautilus und siehe da, nautilus beschwert sich nicht mehr und schmeißt direkt gVim an. Warum nicht gleich so. Und warum keinen Hinweis auf diese Lösung schon in der oben gezeigten Fehlermeldung?

Gerade beim Compilieren vom aktuellen GIMP gesehen:

Schnuckelig, oder? Also, am besten heute noch wechseln

Ja, die Überschrift ist sensationsgeil, aber genau so ist es Jeff Ayars, Vizepräsident von Realnetworks, der Linux auf dem Desktop-Markt den Tod prophezeit, sollte es nicht (bald) DRM-Techniken unterstützen:

The consequences of Linux not supporting DRM would be that fixed-purpose consumer electronics and Windows PCs would be the sole entertainment platforms available. [...] Linux would be further relegated to use in servers and business computers, since it would not be providing the multimedia technologies demanded by consumers.

Jeff Ayars, vice president at RealNetworks, in a talk at LinuxWorld in Boston

Meine Meinung dazu: Nein, wird es nicht. Eher wird die zunehmende Zahl von Linux-Nutzern die Musikindustrie zwingen, geeignete Formate auch für Linux-Nutzer zu entwickeln. Denn nur weil der Markt für den Vertrieb DRM-geschützter Musik über das Internet wächst und diese (soweit ich weiß) nur unter Windows (im Falle von Itunes auch auf Macs) abspielbar sind, heißt dies nicht, dass sich Nutzer von Linux abwenden, nur weil dort entsprechende Player fehlen. Wer Linux nutzt, nutzt es, weil er größere Schwächen an Windows, MacOS, ... hasst.

Und warum müssen sich die Entwickler von Linux darum bemühen, DRM zu unterstützen? Die zahlreichen Player unter Windows z. B. von Musicload oder Apple (Itunes) werden ja auch von den Firmen finanziert. Und die Zielgruppe der Linux-Nutzer, die auch Musik über das Internet beziehen wollen, scheint ja (zukünftig) nicht zu unterschätzen zu sein. Deshalb ist es meiner Meinung nach dann auch bei Linux eine Sache der Firmen die entsprechende Software unter den entsprechenden Lizenzen (LGPL, GPL, ...) für Linux oder aber zumindest finanzielle Unterstützung für die entsprechenden Entwickler bereitzustellen. (Ich weiß, dass Widows Vista auch ohne solch eine Unterstützung einige DRM-Technologien unterstützen wird, aber im Moment, werden viele Programme neben dem Windows Media Player auch von den Firmen selbst angeboten, siehe Itunes.)

Und überhaupt gibt es viele Fragen bzw Unsicherheiten, die bis jetzt bei DRM-geschütztem Content ungeklärt sind. Was passiert, wenn die Software, mit der ich diesen (ich sag es jetzt einmal allgemein) Content öffnen kann, nicht weiterentwickelt wird? Dann weiß ich, dass ich das Recht habe den Content zu öffnen, ..., nur können tu ich es nicht mehr, toll. Eine “gute, alte” CD dürfte da schon mal länger halten, und sollten CDs dann doch einmal nicht mehr uptodate sein, gibt es sicherlich Möglichkeiten, sie auf dem neuen Musikdatenträger unterzubringen. Die Musik auf CDs ist sehr langlebig (man denke nur an Kassetten oder Schallplatten, beides lässt sich heute einfach digitalisieren und auf CDs verewigen). Dateiformate und Software sind da bisweilen kurzlebiger.

Abschließend möchte ich noch kurz eine ganz andere Idee für DRM anreißen: Henning hat mir einmal von (ich nenn’s jetzt mal so) Social DRM erzählt. Die Idee ist folgende: Jeder Content (Musik, Filme, ...) enthält DRM-Informationen. Man kann weiterhin Lizenzen für den Content erwerben und ihn dann ohne Restriktionen öffnen. Außerdem kann man den Content auch per Tauschbörsen legal weitergeben. Der Clou ist dann, dass, wenn man Content öffnet, für den man keine Lizenz hat, vom Programm eine dicke Information kommt a la “Sie haben keine Berechtigung, bla”. Und jetzt stelle man sich einmal vor, wie toll es kommt, wenn man Freunden von dieser ach so tollen neuen Band erzählt, ihnen das heruntergeladene Lied ohne eine Lizenz vorspielt und sie sehen dann diese Information. “Wie, du findest die Musik toll, unterstützt die Band aber nicht?” Dieses DRM beinhaltet also wesentlich mehr Freiheiten, den Content zu nutzen, und setzt gleichzeitig auf sozialen Druck, soziale Ächtung von “illegalem Contentbesitz”. Ich finde, dies ist eine tolle Idee, die durchaus sehr gut funktionieren kann. (Den genauen Link zu dem Urheber dieser Idee bleibe ich im Moment noch schuldig, der kommt aber noch.)

[via zdnet]