Die letzte Woche ist ein sehr positiver Trend zu erkennen. Sowohl Youtube als auch Vimeo stellen auf HTML5 <video> um. Somit sind die Tage von Flash hoffentlich gezählt.

Was allerdings bei beiden Diensten negativ auffällt ist die Fixierung auf H264. An sich ist es ein super Codec der qualitativ hochwertige und hochauflösende Inhalte bietet. Einen nachteil hat er allerdings: Der Codec verwendet patentierte Technologie. Dies ist auch der Grund warum Mozilla ihn nicht einsetzen will.

Robert O'Callahan erläutert die Gründe nochmals im Detail. Die Lizenzen für H264 sehen nicht nur Abgaben für Softwarehersteller wie Mozilla vor, die De- und Encoder entwickeln. Weiterhin sollen auch die Ausstrahlung mit einer Gebühr belegt werden.

Angesichts dessen ist es für mich noch weniger verständlich wieso Video Portale auf H264 setzen, wenn sie für die Ausstrahlung solcher Videos gebühren bezahlen müssen. Die Lizenzpolitik der MPEG-LA ist darüberhinaus sehr verwirrend und ändert sich Anfang nächsten Jahres grundlegend.

Besonders gefallen hat mir an Rocs Eintrag, dass Mozilla als Idealist hervorgehoben wird, dem die Freiheit des Web und dessen Benutzer am Herzen liegt. Noch ein Grund mehr, dass ich die Zweifel an mir selbst endlich überwinden muss und doch diese Richtung einschlagen sollte.

Die Kontakt- bzw. Rekrutierungsmesse an der FH am Donnerstag war interessant. Ich konnte einige technische Diskussionen mit Firmenvertretern führen. Alle samt waren sie daran interessiert technisch hochwertige Software zu schreiben und sagten, dass sie mitdenkende Mitarbeiter eher wünschen als welche die nur nach Befehlen handeln. Dennoch habe ich bei keinem der anwesenden Unternehmen eine Art Idealismus verspürt die (Software-)Welt in Richtung mehr Freiheit zu verändern.

Mein fünftes Semester dauert noch vier Tage lang, es stehen mir noch einige Klausuren bevor. Ich bin froh wenn es endlich vorbei ist. Leider habe ich größtenteils schlechte Gefühle wenn ich an mein bevorstehendes Praktikum denke.

Nun ist ja Jaunty Jackalope endlich offiziell fertig, und ich habe auch gleich meinem Laptop aktualisiert.

Mein Ersteindruck ist durchweg positiv. Boottechnisch ist es ein wenig schneller. Leider nicht so viel als ich erwartet hatte, aber auch über 10 Sekunden freue ich mich. Vergleicht man den neuen Bootchart mit dem von Intrepid sieht man, dass der Bootvorgang bis zum Login ungefähr gleich geblieben ist bei 40 Sekunden. Der Desktop lädt allerdings um knapp 10 Sekunden schneller.

Direkt nach dem hochfahren verbraucht das System weniger als 300MB RAM; was für ein 64bit System sehr gut ist. Nach einiger Zeit pendelt es sich bei 400-500 ein. Mit offenem Firefox und Thunderbird geht es auch bis 700 hoch. So viel verbraucht Vista direkt nach dem hochfahren, ohne laufende Programme.

Sehr positiv überrascht bin ich vom neuen Nvidia Treiber 180. Die 2D Leistung ist spürbar besser geworden.

Ich habe den Verdacht, dass der aktualisierte WLAN Treiber sogar etwas mehr Leistung aus der WLAN Karte herauskitzeln kann. Es werden mehr WLAN Netze als bisher erkannt, auch weiter entfernte.

Leider hat sich auch etwas verschlechtert: Sound. Zum Teil hört man leichtes Knistern beim abspielen von Musik und anderen Audiosignalen. Je nach Signal ist das Knistern recht störend. Ich weiß nicht genau, wie ich dieses Problem beheben kann.

Ich habe dieses Update auch genutzt um Firefox3.5 und Thunderbird 3.0 zu installieren. Die aktuelle Vorabversion des Firefox ist im offiziellen Paketmanager dabei und kann nachinstalliert werden. Für Thunderbird musste ich allerdings ein Personal Package Archive (PPA) benutzen.

Von Thunderbird 3.0 bin ich auch sehr positiv überrascht. Endlich fügt es sich visuell perfekt in den Restlichen Desktop ein.

Störend ist nur, dass es mich nun bei jedem Start nach meinem Master Passwort fragt. Auch verbraucht die neue Tab Leiste und die Nachrichten Details mehr Platz. Auf einem Breitbild Laptop Bildschirm wirkt das ganze dann etwas eingeengt. Dennoch finde ich TB3 einfach super.

Ich kann dieses Update also für jeden weiterempfehlen. Möglicherweise sollte man allerdings zuerst die LiveCD ausprobieren um mögliche Inkompatibilitäten frühzeitig zu erkennen.

Vor meinem Studium hätte ich nie gedacht, dass ich einmal so weit kommen würde. Ich weiß noch genau, wie ich bei meinem Aufnahmegespräch klare Ziele formuliert hatte. Ich hatte damals schon das Ziel später einmal im Bereich Offene Software Tätig zu sein. Am liebsten Mozilla hieß es da. Der Interviewführer hatte mich auch gefragt, ob ich denn schon Kontakte geknüpft hätte. Nicht so recht. Bis dahin hatte ich nur Fehlerberichte geschrieben.

Dann als ich gerade am C lernen war, habe ich mich an einen ersten Mozilla Patch getraut, der dann vor knapp einem Jahr in Firefox 3.1 (jetzt 3.5) gelandet ist. Meine Motivation ist nicht eingebrochen und ich habe über das Jahr weitere Patches geschrieben. Und heute habe ich sogar meinen ersten Push gemacht.

Ich habe es also geschafft. Anderthalb Jahre nach meiner ersten Berührung mit Mozilla Code bin ich jetzt ganz offiziell Mozilla Entwickler und habe direkte Schreibrechte auf die Versionskontrolle. Das macht mich sehr stolz :)

Wenn man genug Arbeit und Ehrgeiz investiert kann man also doch seine Träume verwirklichen.

Es liegen aber noch drei Semester Studium vor mir. Wer weiß, vielleicht werde ich nach dieser Zeit sogar Hauptberuflicher Mozilla Entwickler werden. Dies würde aber mehr Überwindung von mir abverlangen, denn die Mozilla Hochburgen sind quer über die Erde verteilt und nicht in der Nähe von Salzburg. In meiner momentanen Verfassung ist es mir nicht möglich um die halbe Erde umzuziehen.

Abwarten, wie es denn in weiteren Anderthalb Jahres aussieht. Oder ich finde bis dahin anderweitig eine Arbeit im Bereich Offene Software und/oder Mozilla in der Nähe von Salzburg oder zumindest im deutschsprachigem Raum.

Anstatt das udev Problem zu lösen, ist Scott James Remnant damit beschäftigt über Versionskontrollsysteme zu fluchen.

Er trifft es sehr gut, wenn er sagt, dass er solche Systeme gar nicht benutzen will. Aber es ist ein nötiges Übel wenn man Software entwickelt.

Er nennt eine Liste von Aktionen, für die ein Softwareentwickler ein Versionskontrollsystem braucht. Je mehr überflüssige Kommandos es gibt oder je mehr zusätzliche Parameter man den Kommandos mitgeben muss, umso höher steigt der Hass Index für das jeweilige System.

Ganz besonders verhasst ist für ihn das Kommando add. Er will nicht jede neue Datei einzeln hinzufügen müssen. Ich muss auch sagen, dass dafür ein Kommandozeilen System auch wenig Benutzerfreundlich ist, wenn man jeden Dateinamen einzeln eintippen muss. Dafür ein GUI nützlicher.

Ich persönlich habe sehr viele Dateien im Ordner der Versionskontrolle, die ich nicht versionieren will, von daher bin ich persönlich dafür ein add Kommando zu haben.

Folgende Aktionen nennt er als relevant: get, commit, push, pull, review, merge, log, diff und show.

Wenn ich mir seine Erläuterungen durchlese, merke ich, das Mercurial auf seiner Hass Liste eigentlich nicht sehr weit oben sein dürfte, denn für die genannten Aktionen stehen einfache und intuitive Kommandos zur Verfügung.

Get - Eine Kopie eines Quellcodes erstellen, um daran Veränderungen vorzunehmen. hg clone http://hg.mozilla.org/mozilla-central

Commit - Die aktuellen Änderungen speichern. hg commit -m"Kommentar". Falls nicht jede Datei einzeln hinzugefügt werden sollte, benutzt man hg commit -A -m"Kommentar", das ist nicht wirklich viel Aufwand.

Push - Die eigene Kopie des Quellcodes veröffentlichen. Das ist leider ein komplizierteres Thema. Ein hg push funktioniert nur, falls bereits ein Server installiert ist. hg clone ./ ssh://swatinem.de/var/www/hg/bla schiebt die Änderungen auf einen entfernten Server. Dennoch braucht man dafür leider einen konfigurierten Apache. hg serve erstellt temporär einen eigenen Webserver. Nun muss man allerdings die eigene IP benutzen um an die Daten zu kommen.

Pull - Das ist ein einfaches hg pull -u. Leider wird es komplizierter, sobald man selbst Änderungen seit dem letzten pull gemacht hat. Dann wird ein hg pull && hg merge daraus.

Review - Ein hg incoming listet die Änderungskommentare auf. hg incoming -p zeigt auch die Änderungen selbst an.

Merge - das selbe wie Pull eigentlich.

Log - hg log oder hg glog

Diff - hg diff

Show - hg export tip, wobei tip immer die aktuellste Version ist. Oder eben eine andere Version.

Ganz einfach ist Mercurial nun auch wieder nicht. Aber ich schätze mal, dass man gut damit zurecht kommen kann.

Ich benutze Mercurial leider in einem komplizierteren Szenario. Ich arbeite mit Patches, die ich zwischendurch ändern, aufsplitten und zusammenführen will. Außerdem will ich die Patches immer aktuell haben. Mercurial Queues, mq, macht es mir da nur bedingt einfach. Vor allem die Aufgabe Patches aktuell zu halten ist ein sehr komplizierter Prozess und sorgt immer wieder für Ärger.

Habe mich gerade etwas mit Diffstat gespielt. Das ist dabei rausgekommen:

swatinem@swatinux-mobil:~/mozilla-central$ rm -f tmpdiff; for rev in $(hg log -r 15340:tip --template "{rev} {author|email}\n" | grep arpad | cut -c1-5); do hg diff -r $(expr $rev - 1) -r $rev >> tmpdiff; done; diffstat tmpdiff
[...]
 753 files changed, 2184 insertions(+), 48492 deletions(-)

Nicht schlecht. Da erkennt man auch meine Lieblingsbeschäftigung wenn es um Mozilla geht: Veralteten ungenutzten Code entfernen. Somit müssen sich die Entwickler weniger mit Quellcodeleichen herumärgern und können sich auf das Wesentliche konzentrieren.