Wie ich zu Fedora kam…

Ich hatte gerade eine Unterhaltung via identi.ca über meine Fedora Anfänge. Da sich das aber schlecht in 140 Zeichen pressen lässt, will ich nochmal hier ausführlicher darauf zurück kommen. Vielleicht findet es der eine oder andere ja interessant.

Als ich meinen ersten Kontakt mit Fedora hatte, war ich eigentlich glücklicher ubuntu User. Ich glaub, ich war sogar Mitglied beim ubuntuusers.de-Team. Kann auch sein, dass das erst später kam. So genau kann ich mich nicht erinnern. (/edit: march hat offenbar ein besseres Gedächtnis als ich: Ich war damals im Ikhayateam. Danke für den Hinweis.) Ich war also mehr oder weniger glücklich mit der Distribution meiner Wahl. Allerdings war ich auch neugierig, was andere Distributionen denn so anders machten. Ich war noch relativ neu in der Linux-Welt und so ganz klar, dass die alle auch nur mit Wasser kochen, war mir das noch nicht.
Also war der Plan schnell gefasst: Eine Partition zu testen sollte her. Ich wollte ja eigentlich nicht wechseln, zumindest hatte ich das nicht vor.
Aber welche Distribution? Es gibt ja nicht gerade wenige und mir fehlte (und fehlt) die Zeit jede zu testen. Also überlegte ich mir ein paar Auswahlkriterien.

Es sollte für den Anfang eine der sogenannten Major-Distributionen werden. Die haben (meist) den Vorteil, dass sie über große Repositories verfügen und man muss nicht alles aus den Quellcodes backen. Worauf ich damals keine Lust hatte. Wie gesagt, ich war noch relativ neu in der Linux-Welt. Ein weiterer Vorteil, so dachte ich mir, sei, dass diese Distributionen eine große und aktive Community haben. Das war mir wichtig, damit ich zur Not Fragen stellen konnte und auch eine Antwort bekommen würde.
Und ich wollte eine Distribution, die RPM Pakete einsetzt. Nicht weil ich debian Pakete doof fand, sondern weil ich es schlicht ausprobieren wollte. So blieben im Prinzip nur openSUSE und Fedora. Aber openSUSE wollte ich nicht. Ich hatte schon bevor ich ubuntu einsetzte unschöne Erfahrungen mit openSUSE gemacht. Bevor mich jemand schlägt: Ja, es war mein Fehler, nicht der von openSUSE. Trotzdem wollte ich kein openSUSE. Das schien (und scheint) nicht zu mir zu passen.
Blieb nur noch Fedora. Und nachdem ich mich ein wenig „schlau“ gelesen hatte (das deutsche Fedorawiki hat einen schönen Vergleichsartikel), ging es dann auch los.
Die damals vorliegende Version hieß Fedora 9 „Sulphur“. Ist also schon eine kleine Ewigkeit her. Und die Hälfte von dem, was unter ubuntu funktionierte, lief unter Fedora nicht oder nicht so, wie ich es erwartet hatte. Und natürlich lief mein blöder Broadcom-WLAN-Chip nicht. Aber das Problem hatte ich erwartet und wusste, was ich tun musste. Stichwort: rpmfusion. Und Fedora machte unter der Haube einiges anders als ubuntu. Und das gefiel mir. Fedora machte das nicht besser, sondern anders. Besonders angetan hatte es mir die Ausgabe von yum. Yum listet Pakete in einer schnieken Tabelle auf, während apt-get optisch gesehen die raus rotzt. Das stört mich heute noch.

Wirklich vermisst habe ich nur die apt-get Option ‘autoremove’. Das yum PlugIn remove-with-leaves war nur ein schwacher Ersatz. Um so glücklicher war ich als die Option „clean_requirements_on_remove“ eingeführt wurde. Das funktioniert im Prinzip genauso wie ein ‘apt-get autoremove’, nur dass man es nicht extra ausführen muss.
Fedora wirkte auf mich ein ganzes Ende rustikaler als ubuntu. Aber ich fand das gut. Und als dann Fedora 10 erschien, entschied ich mich von ubuntu zu verabschieden und Fedora als Hauptsystem einzusetzen. Und dabei bin ich bis Heute geblieben.

P.S.: Ich hab noch einen Screenshot von Fedora 9 gefunden. Das sieht so gruselig aus, dass ich wundere, wie ich es geschafft habe zu wechseln. Wahrscheinlich sah ubuntu auch nicht besser aus. ;)

Screenshot von der Fedora 9 LiveCD mit Gnome 2.2

Screenshot von der Fedora 9 LiveCD mit Gnome 2.2

Gnome 3.4: Bitte kein ‚Application Menu‘

Eigentlich wollte ich ja nach dem letzten Eintrag etwas positives schreiben. Da kam mir der Link zu den geplanten Features für Gnome 3.4 gerade recht. Also schnell geöffnet und voller Begeisterung angefangen zu lesen. Doch dann stolperte ich über den Punkt: „Application Menu / Actions“. Das jeweilige Anwendungsmenü soll demnach als Kontextmenü des jeweiligen Icons im Panel integriert werden. Man betrachte sich einfach mal die Mockups dazu.

Mockup des Application Menu
Application Menu

Und das ist der Zeitpunkt an dem ich wieder meckern muss, denn das ist genau der Punkt, der mich auch an unity stört. Unity hat das bereits und es nervt mich wirklich. Hat man nämlich eine Anzahl von Anwendungen, die nicht maximiert sind, dann wird der Weg zum Menü echt lang. Vor allem wenn diese Anwendungen auf dem 2. Bildschirm liegen! Wenn so was bei unity eingeführt wird, ist mir das relativ egal. Unity gibt es nur bei ubuntu und ich hab kein ubuntu. (Nur ganz nebenbei, meine Freunde von unity: Es freut mich, dass ihr das gut findet oder zumindest damit leben könnt, aber versteht, dass es nicht mein Geschmack ist.)
Aber es gibt Hoffnung. So ist als einer der Punkte Folgendes aufgeführt:

„The app menu needs to be dynamic (…), to accomodate sensitivity changes of actions, and e.g. window state (fullscreen / not fullscreen)“

So könnte es sein, dass eine nicht maximierte Anwendung ihr Menü behält, damit man eben nicht die virtuellen Kilometer abreißen muss.
Auch ein weiterer Satz stimmt mich vorsichtig optimistisch. Wenn es da bei den Programmen, die dieses Feature wahrscheinlich nicht in naher Zukunft übernehmen können, heißt:

„This is not a problem – it is fine for such applications to keep their traditional menus“

Daraus schließe ich einfach mal, dass den jeweiligen Programmen ihr Menü nicht zwangsenteignet wird.
Es sieht bei näherer Betrachtung nicht ganz so gruselig aus, wie am Anfang. Oder wie meine Oma zu sagen pflegte: „Nix wird so heiß gegessen, wie’s gekocht wird!“

Die Frage nach btrfs, Fedora und dem ganzen Rest

„It’s called Butter FS or B-tree FS, but all the cool kids say Butter FS“
Valerie Henson

Wieviele Dateisysteme gibt es für Linux? Dem geneigten Umsteiger dürfte die Antwort wohl am leichtesten fallen: „Zu viele!“. Da gibt es die Klassiker der ext-Familie: 2, 3 und 4. Dann noch ReiserFS und Reiser4. Gar nicht zu sprechen von den Dateisystemen fremder Betriebssysteme, die Linux aber unterstützt wie FAT16/32, NTFS, XFS, etc.. Der Geneigte hat also genügend Auswahl. Das neueste Mitglied dieser illustren Gruppe ist btrfs. Was kann also btrfs, was andere Dateisysteme nicht können? Und wie sieht es mit der Unterstützung unter Fedora aus?

btrfs: Die Vorteile

Fangen wir mit ein paar Grundinformationen zu btrfs an. Es ist eine Entwicklung aus dem Hause Oracle und steht für B-Tree FS oder Butter FS. Die Veröffentlichung erfolgte Anno Domini 2007. btrfs unterstützt natürlich die Rechteverwaltung, die erweiterte Access Control List (ACL) und Journaling. Die einzelnen Dateien dürfen ebenso wie die Partitionen dürfen ein maximale Größe von 16 EiB haben, wobei Dateinamen nicht länger als die üblichen 255 Bytes sein dürfen und weder das Nullzeichen noch den / enthalten dürfen. Soweit also zu den Standardübungen eines brauchbaren Dateisystems.
Aber btrfs wäre nicht der neue, aufgehende Stern, wenn es nicht noch mehr könnte. Womit wir auch schon bei den Vorteilen wären. btrfs bietet eine Funktion zur Erstellung von snapshots an. Um die Datensicherheit weiter zu erhöhen, bringt das Dateisystem noch ein integriertes, inkrementelles Backup mit. Natürlich geht ein vernüftiges Backup nicht ohne ein Prüfsummen-Funktion, aber keine Panik auch das bietet btrfs. Und als Sahnehäubchen: ein integriertes RAID-System, das die RAID 0, RAID 1 und RAID 10 unterstützt.

btrfs: Die Nachteile

Ein altes Sprichwort sagt: „Wo viel Licht ist, da ist auch viel Schatten.“. Und die Schattenseite von btrfs ist, dass es sich noch in der Entwicklung befindet. btrfs hat noch Bugs und Bugs bei einem Dateisystem bedeuten meistens schlechte Nachrichten für den Benutzer. So kann auf Grund eines Bugs Fragmentierung auftreten und damit die Partition schneller füllen, als sie müsste. Aber das wäre ja noch ein geringeres Problem. Der schnöde Verlust von Daten ist da schon problematischer. Daher sind selbst progressive Entwickler meist etwas vorsichtiger, was den Einsatz von Dateisystemen, die sich in Entwicklung befinden, angeht. Butter FS scheint jedoch aus den gröbsten Nachwehen eines initial-releases raus zu sein. So weit sogar, dass sowohl ubuntu als auch Fedora überlegen, btrfs als Standarddateisystem in mittlerer Zukunft zu übernehmen.

Die Vergangenheit von btrfs in Fedora

Fedora versucht seit jeher Wegweiser bei neuen Technologien zu sein. So überrascht es natürlich nicht, das Fedora bereits in der Version 11 eine Möglichkeit vorsah Butter FS zu benutzen. Die Option war noch versteckt und sie zu aktivieren erinnerte mehr an einen Cheat-Code: ‚icantbelieveitsnotbtr‘ hieß der Eintrag für Anaconda. Aber danach stand btrfs bei der Partitionierung zur Verfügung. Allerdings benötigte man noch eine seperate ‚/boot‘-Partition, da grub-legacy nicht in der war (und auch wohl nie sein wird, da die Entwicklung eingestellt ist) von einer btrfs-Partition zu booten.
Mit Fedora 13 wurde der Cheat-Code durch den Begriff ‚btrfs‘ ersetzt. Außerdem konnte man nun über ein yum-Plugin ein Rollback machen. Leider war die Ausführung noch etwas kniffelig, da diese Aufgabe Palimpsest übernehmen sollte, nur war Palimpsest zur Veröffentlichung von Fedora 13 noch nicht so ausgereift wie gewünscht. So blieb dem User nur der Weg über das grub Menü.

Zukunft

Da sich im Bezug auf btrfs bei Fedora 14 nicht viel getan hat, springen wir gleich in die Zukunft. Was erwartet uns da? Nun, in Fedora 15 soll die Installationsoption ‚btrfs‘ entfernt werden. Anaconda wird dann standadmäßig btrfs anbieten können. Dazu soll, laut Red Hat Entwickler Josef Bacik ein Patch für Grub2 kommen, der es ermöglicht von btrfs-Partitionen zu booten. Laut diesen Einträgen auf ubuntuusers.de soll der Grub2-Patch aber schon fertig sein.
Der sich ergebende Status soll dann für 2 Releases gehalten werden und dann wäre es durchaus möglich, dass Butter FS zum Standarddateisystem von Fedora wird. Oder wie es Rahul Sundaram schreibt: „The future is butter and it is better.“