IMHO: Die AusweisApp und Linux: Ein Trauerspiel!

Mitte des Jahres war es endlich so weit: Die Linux-Version der AusweisApp für Linux wurde nach langem Warten veröffentlicht. Seit dem sind knapp 6 Monate vergangen und zu den damals veröffentlichen Paketen für Debian und Ubuntu hat sich zwischenzeitlich nur ein Paket für OpenSuse gesellt. Pakete für andere Distributionen aus den Top-10 von Distrowatch sucht man hingegen nach wie vor vergebens.

Ebenfalls wenig Vertrauenerweckend sind auch folgende Sätze, die man auf der Download-Seite lesen „darf“:

Hinweis für Nutzer von Ubuntu 11.04 und 11.10
Der Fenstermanager unity wird nicht unterstützt (siehe FAQ-Eintrag).

Oder etwa

Die aktuelle Version 1.5 der AusweisApp für Windows unterstützt den Internetbrowser Firefox 7. Eine Lösung für die Linux Distributionen wird derzeit erarbeitet.

Auch wenn man über Unity geteilter Meinung sein darf, so gibt es doch kein sehr gutes Bild ab, wenn eine Anwendung (aus welchen Gründen auch immer) eine oder mehrere Benutzeroberflächen nicht unterstützt.

Aber auch der Umstand, das es bei der Linux-Version einer anderen „Lösung“ bedarf, als bei der Windows-Version, um die Anwendung zum Firefox 7 kompatibel zu machen, wirkt nicht wirklich professionell. Zumindest, wenn es darum geht, Software für mehrere Plattformen parallel zu entwickeln. Das die Linux-Version zumindest bei den Versionsnummern hinterherhinkt, fällt da schon nicht mehr arg ins Gewicht.

Liebes BIS, so wird das nix mit der gewünschten Akzeptanz des ePerso. Warum sollte ich mir diesen ach so tollen Personalausweis früher als nötig zulegen, wenn ich ihn nicht mit dem Betriebssystem meiner Wahl nutzen kann? Für die fälligen 29 Euro findet sich garantiert eine bessere Verwendung :mrgreen:

Vielleicht sollte Fedora-Blog.de eine Presseanfrage1 an das verantwortliche BSI richten, ob und wann weitere Distributionen unterstützt werden oder wie man sich als Nutzer einer (noch) nicht unterstützten Distribution verhalten soll, wenn man den ePerso im Internet nutzen möchte 😉

  1. oder zumindest eine Anfrage im Namen von Fedora-Blog.de []

Fedora führt /run schon mit Fedora 15 ein

Wie die Kollegen von Pro-Linux berichten (>>klick), wird Fedora bereits mit der kommenden Version ein neues Verzeichnis /run einführen. Dieses Verzeichnis soll das bislang existierende Problem von /var/run lösen, das /var/run zum Teil während des Boot-Vorgangs noch nicht verfügbar ist, da es u.U auf einer anderen Partition liegt. Um dieses Problem zu umgehen, gab es bislang viele mehr oder weniger unsaubere Workarounds.

OpenSuse, Debian und Ubuntu haben bereits angekündigt, /run ebenfalls mit den nächsten Versionen in ihre Distributionen einzuführen.

Kein Unity in Fedora & openSUSE

„Vorerst“, müsste man der Überschrift eigentlich noch hinzufügen.
Im Umfeld der großen Distributionen Fedora und openSUSE hatten in den letzten Monaten Entwickler erste Bestrebungen gezeigt, Canonicals Oberfläche „Unity“ zu portieren. Diese Bemühungen scheinen nun vorerst gescheitert zu sein.

Laut Fedora-Entwickler Adam Williamson, liegt dies zum einen in der persönlichen Motivation begründet, zum anderen an einem Bug seitens der Unity-Entwickler. Dieser sollte eigentlich nach Weihnachten in Angriff genommen werden, aber selbst auf Williamsons erneute Anfrage von Ende Januar gab es keine Reaktion.

Bei Nelson Marques von openSUSE, dem Äquivalent zu Williamson, sieht es recht ähnlich aus. Er beschreibt Probleme mit Compiz als Hauptpunkt auf der technischen Seite, die ihn zwingen seine Arbeite vorerst einzustellen. Marques beschreibt die Arbeit als ziemlich frustrierend, stellt jedoch gleichzeitig klar, dass er das Projekt wieder aufnehmen wolle, sobald die Probleme bei Compiz in Griff bekommen wurden. In der Zwischenzeit wende er sich nun lieber Dingen zu, die „weniger seine Motivation auffressen“.

Damit ist und bleibt Ubuntu vorerst die einzige Distribution mit Unity als Desktop-Oberfläche, wenn auch beide Entwickler die Fortsetzung ihrer Arbeit offen ließen und anboten, hilfsbereiten Maintainern den Code zu überlassen.

Btrfs wird Standard in Fedora 16

„Alles ist in Butter.“

Natürlich muss ein Artikel über das Dateisystem btrfs („Butter FS“) mit einem flauen Wortspiel aus dem Bereich der Milchprodukte beginnen. Natürlich. Dabei hat das recht junge Dateisystem diese schlechten Witze gar nicht verdient, wird es doch als Nachfolger für Ext3/4 gehandelt. Diese werden momentan als Standard in allen großen Distributionen eingesetzt, haben momentan also noch einen Vorsprung.

Dieser Vorsprung ist im vergangenen Jahr stärker unter Bedrängnis gekommen, bieten doch neben Fedora auch Ubuntu und OpenSUSE in ihren aktuellen Versionen bereits bei der Installation an, btrfs einzusetzen – wenn auch nicht als Standard. Mit einem Blick auf die Fähigkeiten des Dateisystems, ist diese Entwicklung auch nachvollziehbar:

  • Datenkompression (mit zlib und lzo)
  • integriertes RAID
  • internes inkrementelles Backup
  • Partitionsgrößen im Livebetrieb ändern
    (Weitere siehe Wikipedia)

Hier setzen nun die Entwickler an: Josef Bacik kündigte auf der devel-Mailingliste an, man wolle als erste Distribution das moderne Dateisystem als Standard für root-Partitionen einsetzen. Zusätzlich solle das Subvolume Management von btrfs den bisherigen Volume Manager LVM ersetzen. Geplant sei dies mit Fedora 16, das im November 2011 erscheinen wird.

Welches Dateisystem verrichtet denn auf eurer Festplatte seinen Dienst? Werdet ihr in absehbarer Zeit wechseln?

RPM bekommt Soft-Dependencies

Wie die Linux Community berichtet, haben sich im Rahmen der OpenSuse Konferenz Mitte September auch einige RPM Entwickler getroffen.

Im Rahmen dieses Treffens wurde unter anderem beschlossen, die von OpenSuse entwickelten und bereits genutzten Soft-Dependencies in die offizielle RPM Distribution zu übernehmen. Soft-Dependencies schlagen im Gegensatz zu "normalen" Dependencies zusätzliche Pakete nur vor, setzen diese aber nicht zwingend für die Installation des eigentlichen Paketes voraus.

Ebenfalls in die offizielle RPM Distribution übernommen werden sollen die von Mandriva entwickelten und bereits eingesetzten Filte-Triggers, die viele Scriptlets überflüssig machen sollen. Hier soll jedoch eine andere Implementierung als die von Mandriva verwendet werden.