synapseninferno

Die Aufgabe war eigentlich ganz einfach: Für einen Verein sollte ein Rundschreiben an alle Mitglieder gemacht werden. Die Adressdaten dazu lagen in einem OpenDocument Spreadsheet vor (ODS). Der Brief war eine einzige Seite A4. Als Liebhaber von OpenSource haben wir dazu natürlich im ersten Ansatz OpenOffice verwendet. Ist auch nicht die erste Aufgabe dieser Art, die sie und ich zu lösen hatten. Aber: Es gestaltete sich dieses Mal besonders wiederspenstig. Und langwierig: Alleine bis die Briefe in OpenOffice aus der Vorlage und den Adressdaten (ca. 650 Datensätze) erstellt wurden, vergingen zwei Stunden. Und weil ein Fehler drin war, gleich nochmal zwei Stunden. Dann sollte alles in ein PDF, damit es der Dienstleister bequem drucken und versenden kann. Das dauerte dann nochmal ein paar Stunden und brach kurz vor Ende mit einem nicht weiter definierbaren Fehler ab.

Ihr wurde es dann zu bunt. Also ein Windows XP in einer VirtualBox gestartet, das da drin installierte Microsoft Office 2008 angeworfen und der Serienbrief war bis zum fertigen PDF eine Sache von weniger als einer Stunde. Und das, obwohl Sie zum allerersten Mal ein Microsoft Office 2008 in der Hand hatte.

Leider keine Loorbeeren für OpenOffice. Bei der Erstellung von (technischen) Präsentationen habe ich damit auch immer wieder meine Schwierigkeiten. Und bisher leider keine Zeit gefunden, die Präsentationsvorlage der Firma nach beamer zu portieren.

Vergangenen Montag war also das erste Treffen von MUCOSUG, der Munich OpenSolaris User Group. Bei Sun. Gleichzeitig mit dem regelmäßigen Treffen der sage-muc@guug aka Sysadminstammtisch. Getarnt als Vortrag über die News zu OpenSolaris 2008.11 (PDF). Insgesamt konnten wir etwas über 40 Personen hin locken, die meisten sind auch noch zur kurzen Tour durch das Sun Vision Center geblieben. Zum Fliegerbräu haben dann noch so 20 Leute gefunden, Fachsimpelei garantiert.

What next? Die MUCOSUG soll sich in Zukunft wenigstens einmal im Monat treffen zum Erfahrungs- und Meinungsaustausch, zum Abgleich der neusten Neuigkeiten, und zum Tüfteln am Gerät. Wer mitmachen will, ist hiermit aufgerufen, bei Doodle über die bevorzugte Woche im Monat und den bevorzugten Wochentag innerhalb dieser Woche abzustimmen.

Updates gibt es über die ug-mucosug@opensolaris.org Mailingliste, über die Webseite http://www.mucosug.org/, oder über die Twitterstreams von mucosug, Constantin oder mir.

Constantin und ich freuen uns über eine rege Beteiligung beim nächsten Treffen :-)

In eigener Sache: Die German Unix User Group sucht noch Beiträge für das Frühjahrsfachgespräch, das Mitte März 2009 in Karlsruhe stattfindet. Wir suchen nach interessanten Themen aus dem weiten Feld der Systemadministration unter Unix/Linux. Der Call for Papers läuft offiziell noch bis Mitte Dezember 2008. Beiträge können in Form von Abstracts direkt auf der Webseite eingereicht werden.

Ich freue mich auf interessante und spannende Beiträge!

Am Wochenende habe ich meinem Cowon iAudio X5L eine neue Firmware verpasst. Zuerst ein Update der Cowon-Firmware. Außer einer eingedeutschten Oberfläche und bunteren Icons keine wesentliche Änderung feststellbar. Allerdings war das Update straight forward: Firmware auf den Player in das passende Verzeichnis kopieren (taucht im Linux als USB-Platte auf), Player durchbooten und schon installiert sich die neue Firmware.

Weil das so einfach war, habe ich mich dann noch gleich an Rockbox gewagt. OpenSource. Genauso einfaches Update: Man kopiert das Firmware Binary und einen Verzeichnisbaum mit den zugehörigen Helper Files auf das Gerät, durchbooten, done.

Boah! Was ist das!? Rockbox bootet in einem Bruchteil der Zeit. Sie hat Berge von lustigen, teilweise sicher überflüssigen Features (Schach, Tetris und allerlei andere Spiele, einen Taschenrechner, Metronom, VU-Meter etc.). Der Equalizer ist eine Wucht (einstellbar in 10Hz-Schritten!). Mitgeliefert werden allerlei Themes, neue Themes können nachgeladen werden. Und Rockbox hat endlich eine MP3-Datenbank. Mit der originalen Firmware konnte man lediglich durch's Filesystem browsen und tat gut daran, Musik passend abzulegen, wenn man sie wiederfinden wollte. Mit Playlists habe ich noch nicht gespielt, aber auch das scheint auf den ersten Blick sehr viel besser zu funktionieren als bei der originalen Firmware.

Die Belegung der Tasten ist etwas gewöhnungsbedürftig. Sofern man vorher lange und viel mit der Cowon-Firmware gearbeitet hat. Insgesamt habe ich den subjektiven Eindruck, dass die Tasten und der Joystick zuverlässiger und exakter reagieren. Man sagt der Firmware außerdem nach, dass sie batteriesparender arbeiten soll. Dazu kann ich noch nichts sagen. Aber ich war auch mit der Akkulaufzeit der originalen Firmware nicht unzufrieden. MP3s haben leider immer noch ein Gap zwischen Tracks, was bei Liveaufnahmen und Konzeptalben durchaus störend ist. Obwohl ich die Option Puffer vorzeitig füllen auf 1min stehen habe. Immerhin ist das Gap mit der Rockbox-Firmware sehr klein. Und wer weiss, was in zukünftigen Releases passiert :-)

Sun setzt die mehrere Monate alte Ankündigung um und veröffentlicht den Source Tree von Solaris als Open Solaris. Gut gelungen finde ich persönlich den webbasierten Source Browser. Natürlich kann man das Zeug auch einfach runterladen. Allerdings ist es wohl im Moment nicht das komplette Solaris sondern im wesentlichen Kernel und Netzwerkdienste. Das würde auch erklären, dass das tar.bz2 gerade mal 44MB gross ist...

Sun wird Solaris in der zweiten Jahreshälfte 2005 unter der CDDL (Common Development and Distribution License) veröffentlichen. Die Webseite dazu ist bereits online.Vorab gibt es dort schonmal den Source zu DTrace. Die DTrace-Programmierer Bryan Cantrill und Adam Leventhal geben in ihren Blogs wertvolle Hinweise zum Source. Lesen lohnt sich.

Sun bringt -- leider erst mit einem späteren Update von Solaris 10, noch nicht mit dem First Customer Ship – ein neues Filesystem namens ZFS (Zettabyte Filesystem). Neben den üblichen Features (Journaling, Online-Resizing etc.) wird es einen Adressraum von 128bit geben. Das ist eine Menge. Welche Menge das ist, versucht ein Sun-Ingenieur rechnerisch zu erläutern. Ausserdem versucht er zu begründen, warum man 128 Bits zur Adressierung braucht. Grund für mich, die etwas andere Begründung zu übersetzen:

Eine faire Frage: Warum ist ZFS ein 128-bit Dateisystem? Was um alles in der Welt bringt uns dazu anzunehmen, dass das notwendig sei? Und woher wissen wir, dass es genug ist?

Beginnen wir mit dem einfachen Teil: woher wissen wir, dass es notwendig ist?

Einige [Sun-]Kunden haben bereits Datenbestände im Petabyte-Bereich, also 2⁵⁰ Bytes. Die 64-bit Grenze von 2⁶⁴ ist nur noch 14 Verdoppelungen entfernt. Moores Gesetz für Storage sagt, dass die erforderliche Kapazität sich alle 9-12 Monate verdoppeln wird, was bedeutet, das die 64-bit Grenze in etwa einer Dekade erreicht ist. Speichersysteme [Anm.: insbesondere Filesysteme] sind für gewöhnlich mehrere Dekaden in Betrieb, also wäre es schwachsinnig etwas Neues zu kreieren ohne auf Bedürfnisse einzugehen, die während der projektierten Lebenszeit sicher auftauchen werden.

Wenn 64 Bits nicht genug sind, ist der nächste logische Schritt 128 Bits. Das ist genug, um Moores Gesetz solange zu überleben, bis ich [Anm.: der Sun-Ingenieur) tot bin. Aber es stellt sich die Frage: was sind die theoretischen Grenzen der Speicherkapazität?

Obwohl wir alle gerne hätten, dass sich Moores Gesetz ewig fortsetzt, birgt die Quantenmechanik einige fundamentale Grenzen für Verarbeitungsgeschwindigkeit und Kapazität eines beliebigen physikalischen Geräts. Es wurde gezeigt, dass 1 kg Materie begrenzt auf 1 Liter Rauminhalt bestenfalls 10⁵¹ Operationen pro Sekunde ausführen oder bestenfalls 10³¹ Bits an Information speichern kann [vgl. Seth Lloyd, "Ultimate physical limits to computation." Nature 406, 1047-1054 (2000)]. Ein voll belegtes 128-bit Speichersystem würde 2¹²⁸ Blocks = 2¹³⁷ Bytes = 2¹⁴⁰ Bits enthalten; die minimale Masse, diese Bits zu speichern wäre (2¹⁴⁰ bits) / (10³¹ bits/kg) = 136 Millarden kg.

Das ist eine ganze Menge.

Um jedoch an der Grenze von 10³¹ bits/kg zu arbeiten, muss die gesamte Masse eines Rechners in Form reiner Energie sein. Aufgrund E=mc² ist die Ruheenergie von 136 Millarden kg etwa 1,2x10²⁸ J. Die Masse der Ozeane liegt bei etwa 1,4x10²¹ kg. Um 1 kg Wasser um 1 °C zu erwärmen, braucht es etwa 4.000 J, somit also ca. 400.000 J um das gleiche Kilogramm vom Gefrierpunkt zum Kochen zu bringen. Latente Wärme für die Verdampfung bringt weitere 2 Millionen J/kg dazu. Die Energie um die Ozeane zum Kochen zu bringen ist also etwa 2,4x10⁶ J/kg x 1,4x10²¹ kg = 3,4x10²⁷ J. Also würde ein komplett gefüllter 128-bit Storage-Pool buchstäblich mehr Energie brauchen, als ein kochender Ozean.

Eine schön sinnlose Rechnerei. Dem habe ich absolut nichts mehr hinzuzufügen :-)

In einem früheren Eintrag habe ich auf den Blog-Eintrag eines Sun-Programmierers verlinkt, wo er einige Eigenschaften und Key Features des neuen Filesystems ZFS beschreibt, das in Solaris 10 integraler Bestandteil sein wird. Nachdem Sun dazu auch eine Feature Story auf deren Website veröffentlichte, hat auch Slashdot das Thema aufgegriffen: ZFS, the Last Word in File Systems? Sind einige interessante Threads dabei.

Und bekommt es auch: In Solaris 10 wird ZFS Einzug halten. Derzeit steht das für Zettabyte File System. Was das Marketing-Department bei Sun am Ende draus macht, werden wir sehen. Vielleicht sowas wie Sun Java Enabled N1 Enterprise File System. Egal, bei den richtigen Leuten wird das zukünftig und auf immer und ewig ZFS heissen. Fertig. Ein paar Details zur Funktionalität im Blog von Matthew Ahrens, Kernel-Entwickler bei Sun: Journaling, natürlich POSIX compliant, 128 (!) bit adressierbar (das sind so grob 3.4x10^26 TB!), ACLs, eingebaute Snapshots und Clones, natürlich Quota, Reservierung und Komprimierung. Alles, was man von einem modernen Filesystem halt erwartet.

Ich bin auf jeden Fall auf das nächste Solaris Espress Release gespannt, da sollte ZFS dann mit drin sein.