Das Ende

Vielleicht habt ihr euch auch schon gewundert, dass heute keine Asteroiden vom Himmel fallen und keine freundlichen Borg-Drohnen an eure Tür klopfen. Die Apokalypse ist mal wieder völlig überraschend verschoben worden. Das gilt zumindest für die Welt, nicht aber für diesen Blog.

Denn das hier wird das letzte Posting sein. Ich habe fertig. Wenn ihr mal im Archiv blättert, werdet ihr feststellen, dass ich dieses Jahr ganze fünf Beiträge veröffentlicht habe. Das gleiche gilt für 2011. 2010 wars dann so monatlich und 2009 habe ich noch alle paar Tage was gepostet, das waren dann über hundert Postings im Jahr. Ich habe einfach keine Zeit mehr, regelmäßig hier was zu posten, und in Zukunft werde ich eher noch weniger Zeit hierfür haben. Die Motivation hat auch nachgelassen, muss ich gestehen, inzwischen hab ich mehr Lust, mal wieder andere Sachen zu machen als zu bloggen.

Es fing alles 2008 an, damals noch auf Blogger, dem Blog-Hosting Dienst von Google. Rein zufällig stieß ich auf einige Blogs, las sie, fand das Konzept interessant und dachte mir, hey, das musst du auch mal versuchen. Also Adresse registriert und fröhlich drauflos geschrieben. Als dann irgendwann die ersten Leser kamen, fielen mir schnell die Limitierungen der Plattform auf, es gab keine Möglichkeit, sich bei neuen Kommentaren benachrichtigen zu lassen und auch keine Trackbacks. Also bin ich zu WordPress.com umgezogen, meine Inhalte vom alten Blog importiert und eine Weiterleitung eingerichtet. Die Besucherzahlen stiegen immer weiter, vor allem durch die Aufnahme des Blogs in den Planeten von ubuntuusers. Bei JUICEDBlog schrieb ich meinen ersten Gastbeitrag (danke, Daniel). Auf Twitter habe ich mich auch einige Zeit versucht, es dann aber mangels Mehrwert wieder aufgegeben. Es lief eigentlich recht gut, besonders beliebt waren meine Beiträge zur Synchronisation zwischen iOS und Linux. Gefreut haben mich immer die vielen Kommentare und angeregten Diskussionen über kontroverse Themen, die trotzdem sehr gesittet und ohne verbale Entgleisungen abliefen.

Damit ist jetzt aber Schluss. Das Blog hier wird wohl weiterhin online bleiben, als Archiv, aber hier kommt nichts neues mehr. Generell werde ich nicht mehr als FERNmann auftreten. Wird Zeit für einen neuen Namen; da werde ich dann vorher überprüfen, ob es nicht schon irgendwelche Gangsta-Rapper auf MySpace gibt, die genauso heißen ;-).

Mal schauen, vielleicht mach ich irgendwann wieder einen Blog, vielleicht über andere Themen. Vier Jahren warens, sie waren schön, aber alles hat mal ein Ende. Ich hoffe, mein Geschreibsel war für euch nützlich und unterhaltsam. Danke fürs Lesen und für die vielen Kommentare.

$ exit
Connection to the world closed.

Von formfaktorübergreifenden Betriebssystemen

Seien wir mal ehrlich: Mischsysteme sind nicht das wahre. Es erzeugt immer einen Mehraufwand, wenn man verschiedene Betriebssysteme, verschiedene Browser oder verschiedene Office-Lösungen gleichzeitig nutzt. Auch wenn Standards theoretisch für Kompatibilität sorgen könnten, so ist es meist einfacher, für dieselbe Aufgabe immer dieselbe Lösung zu nutzen. Vor diesen Problem stehen auch die Benutzer von Tablets und Smartphones: die dort verfügbaren Betriebssysteme sind nicht kompatibel mit denen, die auf Desktops und Notebooks laufen. Anwendungen können nur mit großem Aufwand so geschrieben werden, dass sie sowohl auf klassischen als auch auf mobilen Betriebssystemen laufen, vor allem da die mobilen Systeme oft sehr restriktiv sind, was die Wahl der Entwicklungswerkzeuge betrifft. Da man auf beiden Betriebssystemvarianten nun unterschiedliche Anwendungen nutzt, ist auch die Synchronisation von Einstellungen schwerer als sie sein müsste.

Microsoft muss sich das auch gedacht haben: Windows 8 läuft auf Desktops, Notebooks, Tablets und Smartphones. Damit ist es möglich, Anwendungen zu schreiben, die auf jedem Gerätetypus laufen, und zwar ohne auf mehrere Betriebssysteme portieren zu müssen. Der Nutzer kann überall die gleichen Anwendungen nutzen, Einstellungen werden über den Microsoft-Account synchronisiert, und man muss sich dieselbe Apps nicht zweimal kaufen, denn auf jedem Gerät hat man denselben Windows Store.

So die Theorie. Leider hat Microsoft nichts weiter getan, als seine Windows-Phone-Oberfläche auf Windows NT zu portieren, sodass dort dann beide Oberflächen parallel laufen. So hat man bei der Benutzung von Windows 8 das Gefühl, mit zwei Betriebssystemen zu arbeiten, die irgendwie aneinandergeflickt wurden. Zwar ist es unter Linux auch möglich, mehrere Oberflächen zu installieren und zu benutzen, aber da entscheidet der Nutzer, welche er nutzen will – unter Windows 8 entscheidet die Anwendung. Ja, tatsächlich die Anwendung, was den nervigen Effekt hat, dass man ständig zwischen Metro und dem Windows-Desktop hin- und herwechselt, je nachdem, was für eine Anwendung man gerade benutzt. Das halte ich für eine Usability-Katastrophe. Am Tablet stellt man z.B fest, dass der Metro-Systemsteuerung irgendeine Option fehlt, die man gerade braucht, sodass man dann auf dem Touchscreen die winzigen Icons der Desktop-Systemsteuerung bedienen darf. Auf einem Desktop-Rechner hingegen muss ich dann Fullscreen-Anwendungen mit riesigen Buttons benutzen. Das Wechseln zwischen Anwendungen funktioniert auf beiden Oberflächen anders, beide haben unterschiedliche UI-Patterns (Drag&Drop vs Charmbar, Rechtsklick öffnet Kontextmenü oder das Hauptmenü). Desktop-Anwendungen kann ich aus beliebigen Quellen installieren, Metro-Anwendungen nur aus dem Store. Desktop-Anwendungen speichern ihre Daten als Dateien im Benutzerverzeichnis ab, Metro-Anwendungen haben ihren eigenen Bereich für das Speichern von Daten. Auch für Entwickler wird es nicht unbedingt einfacher, die ganze alte Win32-API sowie .NET gibt es weiterhin, zusätzlich gibt es jetzt WinRT für die Metro-Oberfläche. Nur bei Windows Phone ist es anders, da haben sie den ganzen Desktop-Teil weggelassen.

Etwas wie Windows 8 könnte man auch in der Linux-Welt schaffen, indem man etwa unter Android einen X-Server installiert, der parallel zur Android-Oberfläche läuft und z.B Unity ausführt. Dann hätte man auch ein System, das auf allen Formfaktoren läuft, aber eigentlich hat man nur zwei verschiedene Systeme zusammengeflickt und als Neuheit verkauft. Nein, wenn man ein System haben will, das auf Desktops und Tablets gleichermaßen funktioniert, dann muss es natürlich auch nur ein System sein. Natürlich können Anwendungen nicht auf allen Formfaktoren die gleiche Oberfläche haben, aber sie könnten jedoch ihre Oberfläche je nach Formfaktor anders anzeigen. Entwickler können für ein System programmieren und müssen nur die UIs anpassen, denn bei einen Tablet muss die UI größere und weniger Elemente haben, auf dem Desktop hingegen kann man den Platz und die präzisere Bedienung durch die Maus ruhig ausnutzen. Anwender hätten überall die gewohnten Anwendungen mit den gewohnten Einstellungen, und könnten in nur einem Store einkaufen. Das wäre eine elegante Lösung.

Canonical, wenn ihr tatsächlich vorhabt, Ubuntu für Tablets und Smartphones zu herauszugeben, dann macht kein Me-too-Produkt. Macht es anders, bietet ein gescheites SDK für die Entwickler und sorgt dafür, dass man auch immer die passende Oberfläche benutzen kann. Und wenn das nicht klappt, dann treibt Ubuntu for Android voran. Das schlägt zwar im Prinzip in die selbe Kerbe wie Windows 8, denn es laufen ja auch zwei Systeme auf derselben Hardware, aber immerhin habe ich auf dem Smartphone ein Smartphone-GUI (Android) und auf dem Desktop ein Desktop-GUI (Unity). Zumindest für Convertibles wäre dies eine gangbare Lösung, ändert sich der Formfaktor, ändert sich auch das System. Dadurch kann man wenigstens die Daten austauschen – wenn auch mit unterschiedlichen Anwendungen und Stores. Unter Windows 8 hingegen hab ich bei nur einem Formfaktor zwei Systeme, von denen ich eines gar nicht brauche. Worin darin wohl der Sinn liegen mag?

Die Kinder des Gnoms

Vor etwa anderthalb Jahren begann es. GNOME 3.0 wurde veröffentlicht. Ubuntu ging nicht mit und setzte auf Unity. Linux Mint entwickelte Cinnamon, einem Fork der GNOME Shell, und GNOME 2 wurde unter den Namen MATE geforkt. Das alte Gnomenreich gibt es nicht mehr, es ist zerfallen und die neuen Herrscher haben alle eine andere Meinung, wie ihr jeweiliger Teil am besten zu regieren ist.

Dieser Separatismus hat seine Vorteile, bietet er doch die Chance, neue, verschiedene Bedienkonzepte auszuprobieren, ohne den Zwang, alles unter einen Hut bringen zu müssen. Problematisch ist jedoch, dass viele Komponenten zwischen den Projekten immer noch geteilt werden und Änderungen entweder eine Absprache oder eine Ausweitung des Forks bedarf. Ersteres ist schwierig, zweiteres führt zu Inkompatibilitäten und doppelter Arbeit. Wohin wird das ganze also führen, und welche langfristigen Ziele verfolgen die einzelnen Projekte eigentlich?

Fangen wir mit MATE an. Die Entwickler haben für ihr Ziel, den traditionellen GNOME-Desktop zu erhalten, den aufwändigsten, wenn auch konsequentesten Weg gewählt: Es wurde das komplette GNOME geforkt, nicht nur der eigentliche Desktop, auch die Anwendungen und Bibliotheken. Das Forken der Bibliotheken, also der für die Anwender nicht sicherbarer Teil, war ein Fehler, denn dies erzeugt viel Arbeit, da alles an den Rest der sich verändernden Linux-Welt angepasst werden muss, und man gleichzeitig die neuen Bibliotheken von GNOME 3 mit MATE verwenden können muss, will man neue Anwendungen einsetzen, die neuere Versionen der Bibliotheken wie etwa GTK+ 3, GSettings usw. benötigen. Daher denke ich, dass MATE ähnlich wie Trinity (KDE 3 Fork) langsam verschwinden wird, da sich nicht genügend Entwickler finden werden, um den großen Aufwand zu stemmen, einen Sack alter Technologien auf modernen Systemen am laufen zu halten.

Das Forken der Anwendungen scheint sich jedoch als richtig zu erweisen. Die GNOME-Entwickler beschränken sich mit ihren Ideen nicht nur auf die GNOME Shell, sondern nehmen auch die Anwendungen ins Visier. Auf der Apps-Seite im GNOME-Wiki sieht man, welche Art von Anwendungen die GNOME-Entwickler künftig mit ihrem Desktop ausliefern wollen. Reduzierte Benutzeroberfläche, standardmäßig im Vollbildmodus, keine Menüs – optimiert für Touchscreens (erinnert an das Elementary-Projekt). Dieses Apps sind teilweise schon Realität geworden, das Adressbuch und die Dokumentenanwendung kamen als erstes, das waren zusätzliche Anwendungen, die man ignorieren konnte. Ab GNOME 3.4 ging es jedoch bestehenden Anwendungen an den Kragen: Epiphany wurde zu “Web” umbenannt und die neue Oberfläche wurde schon teilweise implementiert. Ein Lesezeichenleiste gibt es etwa nicht mehr, die Tabs sollen in Zukunft durch Vorschaubilder ersetzt werden, wie man es etwa von Safari unter iOS kennt. In GNOME 3.6 ist Nautilus an der Reihe, er heißt dann “Files” und bietet keine Baumansicht (da nicht für Touchscreens geeignet), keine kompakte Ansicht (siehe Diskussion in der Mailingliste) und keinen Zwei-Fenster-Modus mehr. Weitere entfernte Features sind “Type Ahead Find”, also die Möglichkeit, den Inhalt eines geöffneten Verzeichnisses zu durchsuchen, indem man einfach zu tippen anfängt, etwas, was in vielen GTK+-Anwendungen funktioniert, außerdem die Dateivorlagen sowie das gesamte Menü. Man kann sich darauf einstellen, dass in den nächsten GNOME-Releases ähnliches passiert.

Konsequenz: Die Jungs von Linux Mint haben Nautilus 3.4 unter dem Namen “Nemo” geforkt und wird wahrscheinlich in zukünftigen Versionen von Mint als Standarddateimanager eingesetzt werden. Hier bietet sich die Chance für Ubuntu, da mit einzusteigen, denn wahrscheinlich werden weitere Forks notwendig sein, die Mint allein nicht stemmen kann. Cinnamon und Unity könnten sich Code teilen, auf denen dann ihre jeweiligen Shells laufen. Für Unity ist etwa die Abschaffung der Menüleiste (was eigentlich den GNOME Human Interface Guidelines widerspricht) in den GNOME-Anwendungen tragisch, hat Unity doch eine elegante Weise Weise gefunden, mit Menüs umzugehen: Da man sie meistens sowieso nicht braucht, werden sie im oberen Panel versteckt, wie unter OS X, was Platz spart. Sie lassen sich nach Drücken der Alt-Taste durchsuchen, was die Möglichkeiten der Tastaturbedienung stark erweitert, besonders auf Notebooks (das Gedrückhalten der Windows-Taste zeigt übrigens die möglichen Tastenkombinationen).

Vor 16 Monaten wurde Ubuntu 11.04 mit Unity veröffentlicht. Viel fragten sich, welchen Sinn Unity hätte, es gäbe ja bereits die GNOME Shell. Ich sah den Grund in Differenzen zwischen Canonical und den GNOME-Entwicklern in der Frage, wie ein guter Desktop auszusehen hatte – schon damals begannen die Entwickler, Features zu entfernen (wie die Möglichkeit, den Rechner auszuschalten, geht heute immer noch nicht ohne Tricks). Damals wie heute gebe ich Unity den Vorzug gegenüber der GNOME Shell.

Die Aufgabe einer Benutzerschnittstelle ist es, dem Benutzer die Funktionalität des Programms zugänglich zu machen, dabei soll der Benutzer möglichst wenig Aufwand mit der Schnittstelle haben und die Funktionalität der Programms möglichst effizient nutzen können.

GNOME 3 erfüllt diese Aufgabe zur Hälfte. Es ist zwar einfach zu erlernen, aber es gibt auch nicht viel zu erlernen. Was bringt mir ein schönes, übersichtliches Interface, wenn die notwendige Funktionalität nicht vorhanden oder umständlich zu erreichen ist? Die GNOME-Entwickler scheinen die Absicht zu haben, GNOME Tablett-tauglich zu machen. Das hat aber zur Folge, dass Funktionalität entfernt werden muss (weil sie sich auf einem Touchscreen nicht umsetzen lässt) oder dass die Funktionen versteckt werden, das Programmfenster wird in mehrere Perspektiven aufgeteilt, wobei man nur eine gleichzeitig sehen kann. Bei Touchscreens ist das nötig, bei größeren Bildschirmen führt es nur zu längeren Mauswegen, denn dort kann man auch Menüs und geteilte Ansichten benutzen. Weiterhin bleibt die Frage, wer ein GNOME für Tabletts eigentlich braucht, es gibt ja bereits Android, das iPad und Windows 8. Oder wozu man Tabletts überhaupt braucht.

KDE erfüllt die Aufgabe einer Benutzerschnittstelle zur anderen Hälfte. KDE bietet eine ganze Menge an Funktionalität, Features werden nicht entfernt, sondern höchstens optional gemacht. Durch den modularen Aufbau und die vielen Konfigurationsmöglichkeiten läuft KDE etwa auf Desktops, Netbooks und mittlerweile auch Tabletts, für jede Geräteklasse gibt es das passende Plasma-Interface und auch die Anwendungen werden teilweise angepasst – ähnlich wie bei Webseiten, wo man über CSS für unterschiedliche Geräteklassen ein unterschiedliches Layout vergeben kann. Das hört sich alles toll an, weil niemand zu kurz kommt, denn der Nutzer hat die Wahl. Der Nachteil besteht natürlich dann darin, dass manch ein Nutzer durch die vielen Möglichkeiten überfordert ist, viele Features werden vielleicht gar nicht benötigt und stehen im Weg, die riesige Konfigurationsdialoge sind zu unübersichtlich. Hinzu kommt, dass all die verschiedenen Konfigurationsmöglichkeiten das System fehleranfälliger machen, ein wenig konfigurierbares Programm lässt sich wesentlich leichter testen als ein hochmodulares. Gerade die komplexeren Komponenten in KDE wie Akonadi sind meiner Erfahrung nach ziemlich widerspenstig.

Wie sieht eine perfekte Schnittstelle denn nun aus? Ich weiß es nicht. Das ist die Kunst bei der Sache: Ein Schnittstelle zu entwickeln, welche die geforderte Funktionalität bereitstellt, und zwar möglichst effizient, ohne dabei überfrachtetet und verschachtelt zu sein. Was meiner Meinung nach wohl nicht gehen wird, ist die Bereitstellung einer GUI sowohl für Tastatur + Maus als auch für Touchscreens. Da sind einfach andere Anforderungen und Nutzungsszenarien vorhanden, da auch dann bitte getrennte Oberflächen. Gerne auch auf dem selben Gerät, siehe Ubuntu for Android. Derzeit scheint mir Ubuntu mit Unity das ausgewogenste Konzept zu fahren. Es ist nicht überfrachtet und kann daher auch von Einsteigern gut bedient werden, aber unter anderen dank HUD und Compiz gibt es auch Features für erfahrene Benutzer. Verbesserungen gibt es hin und wieder mal, auch kleine “Papercuts” wie das Ayatana-Projekt, ohne gleich alles über den Haufen zu werfen. Ubuntu 12.04 LTS läuft gut auf meinen Geräten, ich werde wohl eine Zeit lang dabei bleiben und dabei zusehen, wie sich das ganze entwickelt.

Hürden auf dem Weg zu Linux

In vielen Bereichen ist Linux etabliert oder sogar dominierend, nur nicht auf dem Desktop. Oft wurde das “Jahr des Linux-Desktops” angekündigt, und es wurde nichts daraus. Warum ist da so? Liegt es an den zu vielen Distributionen? Fehlende Kernel-Schnittstellen? Hässliche GUIs? Fehlende Dokumentation und Software? Treiber? Teilweise. Viele dieser Probleme wurden gelöst, es kommt aber immer noch nicht wirklich vorwärts.

Um diese Frage zu klären, müssen wir erst einmal betrachten, wie ein Benutzer überhaupt zu Linux kommt. Jemand, der einen Computer benötigt, kauft ihn im Laden, da ist Windows vorinstalliert, betriebsbereit. Dies müsste vom Benutzer durch Linux ersetzt werden, es besteht aber kein akuter Bedarf nach einem Betriebssystem. Was muss nun passieren, damit dieser Benutzer trotzdem Linux installiert?

1. Man muss wissen, was ein Betriebssystem ist.

Wissen die meisten Nutzer nicht. Wollen viele gar nicht wissen. Die sind froh, wenn der Computer überhaupt funktioniert. Wenn sie gefragt werden, welches Betriebssystem sie verwenden, gucken sie einen unverständlich an und weisen darauf hin, dass sie sich nicht auskennen und es sie auch nicht interessiert. Vielleicht haben manche im Discounter gesehen, dass die Computer von Apple irgendwie eine andere Oberfläche haben, halten das Betriebssystem aber vielleicht für einen Teil der Hardware. Manche glauben, dass Windows das Ding ist, was kommt, wenn man den PC anmacht. Solche Leute werden niemals ein anderes Betriebssystem installieren können und können damit auch nicht Linux benutzen.

2. Man muss wissen, dass es Linux gibt und überzeugt sein, dass es für einen besser geeignet ist.

Einige Leute, die sich vielleicht ein bisschen mehr für Computer interessieren, wissen, was ein Betriebssystem ist, dass Windows und Linux Betriebssysteme sind und dass man sich ein anderes Betriebssystem installieren kann. Wahrscheinlich haben sie selbst schon einmal Windows neu installiert. Aber das reicht noch nicht, die Leute müssen denken, dass Linux für ihre Bedürfnisse besser geeignet ist als Windows. Dies ist nicht immer der Fall, so benötigen viele Leute Software, die nicht unter Linux läuft. Die übrig gebliebenen Leute, denen Linux besser gefallen würde, denken oft, Linux sei ein kompliziertes System, nur für Hacker und Nerds und ignorieren es daher. Einige kommen vielleicht über Computer-Zeitschriften oder das Internet auf den Geschmack.

3. Man muss die Entscheidung treffen, Linux zu installieren. Und es installiert lassen.

Diese Leute müssen sich dann für eine Distribution entscheiden. Jene Hürde wird öfter angeführt, ist aber nicht so hoch, da meistens die Distribution genommen wird, die überall als nutzerfreundlich deklariert wird, also Ubuntu, Mint oder Suse. Dann muss man sich die Zeit nehmen, tatsächlich die gewählte Distribution zu installieren, aber die meisten Leute haben andere Dinge zu tun und nur wenig Zeit zu Verfügung. Funktioniert irgendwas nicht so wie gedacht, fliegt Linux wieder vom Rechner, die meisten probieren nur die Live-CD aus. Wenige installieren sich ein Linux-System wirklich (meist parallel zu Windows) und beginnen, damit zu arbeiten, vielleicht Linux bald als Haupt-System zu verwenden.

4. Man muss die Probleme lösen, die beim Benutzen auftreten.

Durch die hohe Verbreitung von Windows läuft viele Hardware und Software nur unter Windows. Die Leute wollen sich nicht für Linux neue Hardware kaufen und können oft nicht auf andere Software umsteigen. Vielleicht haben die Daten in Formaten gespeichert, die mit Linux-Programmen nicht gelesen werden können. Außerdem ist Linux nicht Windows, man muss sich bei einigem umgewöhnen, manchmal fehlt die notwendige Dokumentation und man hat nicht den Kumpel, der einen bei PC-Problemen immer hilft.

5. Man muss sich von Windows lösen.

Mal ehrlich: Dual-Boot ist nicht praktikabel für normale Anwender. Niemand will ständig zwischen zwei Systemen wechseln und diese pflegen müssen. Das ist was für Linux-Enthusiasten, es ist eine Notlösung und nicht dauerhaft praktikabel. Wenn man nicht alles, was man tun kann, mit Linux erledigen kann, wird der durchschnittliche Benutzer bald wieder zu Windows zurückwechseln. Linux ist nur dann ein Konkurrent zu Windows, wenn es Windows nicht braucht.

Und nun?

Betrachtet man diese Punkte, dann ist es erstaunlich, dass Linux überhaupt einen wahrnehmbaren Marktanteil hat. Es muss also ziemlich gut sein :-). Schätzt man die Menge der Nutzer ab, auf die all die Anforderungen zutreffen, kommt man auch auf den Linux-Marktanteil. Wie erhöht man ihn?

Schauen wir uns mal die Segmente an, in denen Linux erfolgreich ist. Das ist entweder da, wo die Entscheidungen von Leuten getroffen werden, die sich auskennen, da sollte es nur noch auf die technischen Eigenschaften von Linux ankommen, oder da, wo der Anwender Linux nicht installieren muss, wie bei Smartphones und Tablets. Hier dominiert Android, eine Linux-Distribution, gefolgt von iOS, einem UNIX-Systemen. Windows spielt nur eine geringe Rolle. Will Linux nun auch auf Desktops erfolgreich werden, dann muss Linux vorinstalliert werden!

Aktuell gibt es ja die Diskussion um UEFI Secure Boot, was die Installation von Linux auf einem Computer deutlich erschwert, da man einen eigenen Schlüssel generieren und sein System signieren muss, oder man schaltet Secure Boot ab, wenn das überhaupt möglich ist. Fedora und Ubuntu haben sich bereits Workarounds ausgedacht, aber es sind eben nur Workarounds, die wahrscheinlich wieder Probleme bereiten werden, mindestens muss sich der Nutzer mit Secure Boot beschäftigen und das wird noch mehr Nutzer abschrecken.

Diese Probleme hätte man nicht, wenn es endlich Computer zu kaufen gäbe, auf denen eine Linux-Distribution vorinstalliert ist. Secure Boot gäbe es nicht oder es wäre der Schlüssel der Distribution vorinstalliert, und die Distribution können den Hardware-Herstellern zur Vorgabe machen, die Möglichkeit zu schaffen, eigene Schlüssel hinzufügen zu können, damit man auch selbst-kompilierte Kernels nutzen kann. Ein Firma wie Canonical hätte die Möglichkeit, nach dem Vorbild der Open Handset Alliance mit den Hardware-Herstellern zusammenzuarbeiten, um Computer mit vorinstalliertem Ubuntu anzubieten. Mit Windows 8 experimentiert Microsoft ohnehin, dass wäre eine Chance, eine Alternative zu offerieren. Die größten Hürden, 1-3, würden irrelevant werden, und mit der steigenden Verbreitung würden auch 4+5 verschwinden.

Aber wo sind sie denn, die Linux-Computer? Wo kann ich sie kaufen? Manche kann man irgendwo im Internet bestellen, aber wenn man nicht gezielt danach sucht, kommt man nicht damit in Berührung. Arbeitet mit Hardware-Herstellern zusammen, oder baut eure eigene Hardware (Mark hätte ja das nötige Kleingeld). Bietet Dinge, die es woanders nicht gibt, Ubuntu for Android ist doch schonmal ein Anfang, dann werden die Leute bald Ubuntu auch auf ihrem normalem Computer haben wollen (oder ihr Smartphone wird ihren alten Windows-PC ersetzen). Wir haben schöne GUIs, gute Dokumentation (wiki.ubuntuusers.de), es gibt tolle Anwendung für Linux, es wird mehr Hardware unterstützt als je zuvor, der Ruf des Freak-Systems verschwindet langsam (gut, dass wir es nicht Freax genannt haben); es wird Zeit, dass Linux auch in die Regale kommt.

Eclipse Color Theme Plugin

Nicht jedem gefällt das Standard-Farbschema von Eclipse. Dies kann man zwar feinsäuberlich anpassen, auch für jeden Operator und Keyword einzeln, macht man aber nicht gerne, da nicht besonders spannend und zeitaufwendig, vorallem, wenn manche Plugins wie PyDev extra konfiguriert werden müssen.

Mit dem Plugin Eclipse Color Themes hat man das Problem nicht mehr, denn damit kann man zwischen verschiedenen Farbschemata hin- und herschalten, die Änderungen gelten für alle Sprachen, egal ob Java, Python oder HTML. Das Plugin lässt sich über den Marketplace installieren, wer noch Ganymede oder älter benutzt, der fügt einfach das Repository

http://eclipse-color-theme.github.com/update

hinzu und installiert das Plugin von dort.

Einige Farbschemata werden mit dem Plugin mitgeliefert, über die Webseite http://eclipsecolorthemes.org/ besteht jedoch die Möglichkeit, weitere Farbschemata herunterzuladen, man erhält dann eine XML-Datei, die man über das Plugin importieren muss. Alternativ kann man sich die Farbschemata auch als EPF-Datei besorgen, dem Format, in dem Eclipse seine Einstellungen speichert, diese über File->Import->General->Preferences importieren und auf das Plugin verzichten, jedoch ist es dann nicht möglich, zwischen verschiedenen Farbschemata zu wechseln.

Ich persönlich benutze das Schema Tesla, es ist angenehm zu lesen und sieht bei allen Sprachen die ich benutze gut aus, aber es gibt noch viele mehr und wer will, kann auch seine eigenen Schemata hochladen.

Aktuellen Autobuild von Xonotic über die Paketverwaltung installieren

Über den First-Person-Shooter Xonotic berichtete ich ja bereits. Seitdem hat sich vieles getan, es wurden mit 0.5 und 0.6 weitere Releases veröffentlicht. Viele neue Features kamen hinzu, so kann man jetzt Flug- und Fahrzeuge steuern, es gibt neue Waffen und Maps, neue Game-Modi, neue Bewegungssteuerung, Online-Statistiken für Spieler sowie Client-Side networked players, was die Latenzen bei Netzwerk-Spielen verringern soll.

Wer nun Ubuntu-User ist und das Spiel in der aktuellen Version installieren will, der wird natürlich erst mal zur Paketverwaltung greifen. Mit PlayDeb gibt es auch die passende Paketquelle für. Jedoch befindet sich Xonotic in aktiver Entwicklung, häufig gibt es neue Funktionen, die ausprobiert werden wollen, sodass auf den meisten Servern ein aktueller Snapshot aus dem Development-Repository läuft. Daher ist es ratsam, dieselbe Version einzusetzen, schon um Kompatibilitätsprobleme zu vermeiden. Doch das dauernde Kompilieren des Quellcodes kostet Zeit und nervt irgendwann.

Daher gibt es die Autobuilds, welche das Kompilieren überflüssig machen: Die Xonotic-Server selbst kompilieren den aktuellen Quellcode aus dem Development-Repository für verschiedene Architekturen und bieten das Ergebnis zum Download an. Der User divVerent hat dazu ein Skript geschrieben, welches diese Dateien über rsync herunterlädt. Somit spart man sich Zeit, die für das Kompilieren draufgeht, und hat trotzdem eine tagesaktuelle Version. Zudem lädt rsync nur die Dateien herunter, die sich zur Version auf der Festplatte geändert haben, sodass ein Update blitzschnell vonstatten geht.

Nun gibt es da noch einen Schönheitsfehler: Die Paketverwaltung kommt nicht zum Zug, man muss sich Startskript und Menüeinträge selbst erstellen und alle Dateien an den richtigen Ort kopieren. Also habe ich schnell ein Debian-Paket (.deb) gebaut, welches dies erledigt.

Das Paket installiert folgende Dateien:

  • /usr/games/xonotic: Skript zum Starten des Spiels
  • /usr/local/share/applications/xonotic.desktop: Dazugehöriger Menüeintrag
  • /usr/local/share/pixmaps/xonotic.svg: Icon von Xonotic
  • /usr/local/sbin/update-xonotic: Das eigentliche Update-Skript von divVerent, angepasst von mir, damit es die Dateien nach /opt/xonotic/ installiert.

Nach der Installation wird automatisch update-xonotic aufgerufen, hier wird das eigentliche Spiel das erste Mal heruntergeladen; dies kann, jede nach Internet-Verbindung, ziemlich lange dauern. Das Update erfolgt jedoch wesentlich schneller, einfach

$ sudo update-xonotic

aufrufen und rsync lädt die geänderten Dateien herunter. Wenn das Paket deinstalliert wird, dann wird das Verzeichnis /opt/xonotic und die anderen Dateien wieder entfernt. Im Grunde funktioniert das Paket nicht anders wie flashplugin-installer, ttf-mscorefonts-installer oder nautilus-dropbox, nur dass dort das eigentliche Programm aus lizenzrechtlichen Gründen nicht dem Paket beiliegt, sondern von der Hersteller-Website heruntergeladen wird.

Das Paket funktioniert mit x86 und x86_64, weil für diese Architekturen Autobuilds gebaut werden. Die verwendete Architektur wird vom Skript automatisch erkannt.

Viel Spaß damit.

[Download]

Endlich da, aber eigentlich zu spät: Multiarch-Support

Man glaubt es kaum, aber es gibt einige Sachen, die unter Ubuntu nicht perfekt implementiert sind. Manchmal sind andere Systeme besser ;-). Die parallele Unterstützung von Prozessor-Architekturen auf einem System zum Beispiel. Einige Architekturen, wie x86_64, sind in der Lage, über einen Kompatibilitätsmodus alte x86-Programme auszuführen, ohne das eine Neuübersetzung erforderlich wäre. Andere, wie Itanium, schaffen das zumindest durch Hardware-Emulation.

Jedoch muss auch das Betriebssystem dieses Feature unterstützen. Windows kann es, Mac OS X kann es, und Ubuntu kann es eigentlich auch. Allerdings war es unter Ubuntu (und unter Debian, allgemein mit dpkg) bisher nicht sehr einfach, ein für x86 gedachtes Paket einfach so unter x86_64 zu installieren. Nun, wenn es nur *ein* Paket war, dann konnte man es mit der Option –force-architecture trotzdem installieren. Aber normalerweise hängen Pakete von anderen Paketen ab (z.B shared libraries), und ein 32-Bit-Programm benötigt natürlich 32-Bit-Bibliotheken. Die restlichen 64-Bit-Programme benötigt aber 64-Bit-Bibliotheken, womit man von einigen Bibliotheken beide Varianten installieren müsste. Dies gibt sowohl auf der Ebene des Dateisystems als auch auf der des Paketmanagers Probleme.

In der Vergangenheit gab es mehrere Hacks, um dieses Problem zu umgehen. Manche richteten sich ein 32-Bit-chroot ein und ließen ihre 32-Bit Software darin laufen. Die Maintainer paketierten 32-Bit-Bibliotheken für 64-Bit-Systeme, etwa in dem Sammelpaket ia32-libs (oder einzelne lib32*-Pakete), die an andere Orte wie /lib32 und /usr/lib32 installiert wurden. Die – meist proprietären – 32-Bit-Anwendungen wurden dann ebenfalls neu paketiert, um diese Bibliotheken nutzen zu können. Für Browser-Plugins wie Flash wurden Wrapper geschrieben, um 32-Bit-Plugins in einem 64-Bit-Browser benutzen zu können. Aber eine richtige Lösung war das nicht.

Unter Windows war es noch nie ein Problem, 32-Bit-Anwendungen unter 64-Bit-Windows zu installieren. Das ist sogar eher die Regel als die Ausnahme, Software-Hersteller beschäftigen sich nur mit 64-Bit, wenn es signifikante Vorteile bringt, ansonsten wäre es nur sinnlose Ressourcen-Verschwendung, die Anwendung läuft auch als 32-Bit-Binary unter 64-Bit. Man installiert die Anwendung einfach, ohne sich um die Architektur zu kümmern. Und Apple? Die haben schon mehrere Architekturwechsel hinter sich, von 68k auf PowerPC, x86 und schließlich x86_64. Durch Emulation (getauft Rosetta) konnte man die alten Anwendungen auf der neuen Architektur weiterverwenden, sogar Code für mehrere Architekturen in einer Datei verpacken.

Unter Debian und Ubuntu wird all das jetzt mit dem neuen Multiarch-Support möglich. Ab Ubuntu Oneiric und Debian Wheezy wird er mit dabei sein. Multiarch ermöglicht es, Anwendungen und Bibliotheken zu installieren, die für eine Architektur gebaut wurden, die entweder als Fallback von der eigenen Architektur oder von einem Emulator (wie QEMU) unterstützt wird.

Auf Dateisystem-Ebene bedeutet das: Bibliotheken werden nicht mehr einfach nach /lib bzw. /usr/lib installiert, sondern mit architekturspezifischen Präfixen, etwa /lib/i386-linux-gnu oder /usr/lib/x86_64-linux-gnu – gleiches gilt für Header-Dateien. Dadurch kommen sich die Bibliotheken nicht mehr in Konflikt und können parallel existieren. /lib/32, /usr/lib32, /lib64 und /usr/lib64 fallen weg. Anwendungen, Build-Systeme und Compiler müssen natürlich diese Features unterstützen.

Auch der Paketmanager muss gleichzeitig Pakete mehrerer Architekturen verwalten können. Im Augenblick kann in der Datei /etc/dpkg/dpkg-cfg.d/multiarch eingestellt werden, welche Architekturen neben der Nativen berücksichtet werden sollen. Synaptic zeigt dann die fremden Pakete nach dem Schema <paketname>:<architekturname>, also zum Beispiel adobe-flashplugin:i386 an. Das Software-Center von Ubuntu zeigt jedes Programm nur einmal an und nimmt die native Variante wenn möglich, ansonsten eben das architekturfremde Paket.

In den Meta-Daten der Pakete kann über die Option Multi-Arch angegeben werden, wie es sich auf fremden Architekturen verhalten soll.

  • same bedeutet, dass es mit Multiarch kompatibel ist und parallel zum nativen Paket installiert werden kann (z.B Bibliotheken),
  • foreign heißt, dass das Paket nicht parallel installiert werden kann (z.B Systemdienste oder auch ausführbare Programme)
  • und allowed meint, dass ein architekturfremdes Paket davon abhängen darf.

Aber die ganze Sache hat auch Nachteile. Zum einen ist der Multiarch-Support noch nicht standardisiert und eine reine Debian/Ubuntu-Geschichte. Ob andere Distributionen mitmachen, die mitunter schon eigene Lösungen haben, bleibt abzuwarten. Zum anderen fördert die Multiarch-Unterstützung das Verharren auf alten Architekturen, wie man das unter Windows beobachten kann. Viele Software gibt es nur als 32-Bit, weil das ja auch auf 64-Bit läuft. Damit muss man letztendlich noch ein halbes 32-Bit-System mitinstallieren und im Arbeitspeicher halten, mit reinen 64-Bit-Anwendungen entfällt dieser Schritt komplett.

Außerdem ist das Thema langsam gegessen. Denn die Nicht-Verfügbarkeit von 32-Bit-Software unter 64-Bit hat dazu beigetragen, dass fast jedes Linux-Programm auch als 64-Bit verfügbar ist. Bei Open-Source-Programmen sowieso; den Firefox zum Beispiel gab es lange für 64-Bit-Linux, schon bevor Mozilla vor kurzem angefangen hat, selbst 64-Bit-Binaries bereitzustellen. Proprietäre Anwendungen gibt es auch nur noch wenige, die nicht für 64-Bit verfügbar sind, wie etwa Flash. Aber auch hier hat Adobe vor, mit Version 11 64-Bit Support einzuführen.

Den Vorteil von Multiarch sehe ich in Cross-Compilation in Kombination mit QEMU. So wird etwa das Erstellen von Binaries für ARM unter einem leistungsfähigen x86_64 -System transparent und out-of-the-box möglich sein, anschließend ließe sich das Kompilat mittels QEMU gleich ausprobieren.

Und was ändert sich für den normalen Nutzer? Nur, dass er keine Fehlermeldung mehr kriegt, wenn er versucht, ein 32-Bit-Programm unter seinem 64-Bit-System zu installieren – es funktioniert einfach.

Bis es soweit ist, muss noch ein weiter Weg gegangen werden – schließlich bedeutet Multiarch eine radikale Umstellung des Dateisystems und die Konvertierung von vielen Paketen, sowie möglicherweise Kompatibilitätsprobleme mit älteren Distributionsversionen und anderen Distributionen.

Android 2.3.3 auf dem iPod touch 1G installieren mit Ubuntu

Ich mag es nicht, alte, aber funktionierende Geräte wegzuwerfen. Für meinen drei Jahre alten iPod touch hat Apple den Support schon seit einiger Zeit eingestellt, iOS 4 gab es nicht und iOS 5 wird es erst recht nicht geben. Für die 3er-Serie gibt es auch keine Sicherheitsupdates mehr, was auch den Browser Safari einschließt, der in dieser Version noch zahlreiche bekannte Sicherheitslücken hat.

Deswegen habe ich entschieden, die Lebenszeit des iPods mit Android ein wenig zu verlängern. Vielleicht werde ich mir ja in Zukunft mal ein “echtes” Android-Gerät kaufen, sodass ich Android hier auf dem iPod touch gleich mal testen kann. Jetzt werden einige vielleicht sagen: Android? Auf einem Apple-Gerät? Geht das? Klar geht das. Die Jailbreak-Szene hat mehr zu bieten als nur einen alternativen App Store und damit Apps, die Apple nicht in den Kram passen, es ist auch möglich, gleich ein anderes Betriebssystem zu installieren. Was bei konventionellen Computern geht, sollte auch bei mobilen Geräten machbar sein, denn selbstverständlich darf jeder auf seinem Gerät das Betriebssystem seiner Wahl installieren.

Da Apple natürlich keine Möglichkeit anbietet, ein alternatives Betriebssystem zu installieren, bedarf es einiger Tricks. Glücklicherweise haben einige Hacker OpeniBoot entwickelt, eine freier Bootmanager ähnlich wie GRUB oder LILO, nur eben für iOS-Geräte. Man kann dann ein beliebiges System parallel zu iOS installieren und beim Start zwischen diesen wählen, in meinen Fall ist das zweit-OS eben Android. Aber allein das reicht noch nicht aus. Ein Vanilla-Android bringt keine Treiber für meinen iPod touch mit, denn normalerweise erledigen das die Hersteller der Android-Geräte, aber Apple wird wohl kaum Treiber für Android programmieren ;-). Auch hier gibt es jedoch mit iDroid einen Port von Android, der auf mobiler Apple-Hardware läuft, nämlich auf dem iPod touch der ersten Generation sowie dem iPhone der ersten und zweiten Generation.

Die Installation von OpeniBoot und iDroid ist mittlerweile recht einfach. OpeniBoot muss man über das Terminal per USB installieren, die iDroid-Installation selbst erfolgt über Bootlace unter iOS, welches man über Cydia installieren kann – ihr seht schon, das Gerät muss natürlich jailbroken sein, aber man benötigt einen Jailbreak auf Kernel-Ebene wie etwa redsn0w, andere Jailbreaks können funktionieren, müssen aber nicht (jailbreakme oder Spirit funktionieren etwa nicht). Bootlace überprüft vorher, ob der Jailbreak mit iDroid kompatibel ist. Theoretisch sollte die Installation fehlerfrei ablaufen, trotzdem sollte man ein Backup der gespeicherten Daten machen, denn es kann sein, dass etwas nicht funktioniert, dann bleibt nur noch das Wiederherstellen über iTunes. Ausprobieren also wie immer auf eigenen Gefahr.

OpeniBoot könnt ihr hier herunterladen (openiboot.img3), das nötige Installationstool bekommt ihr hier – achtet darauf, die richtige Architektur (x86 oder x86_64) runterzuladen. Anschließend entpackt das Archiv und schmeißt alles in den selben Ordner, sodass die Dateien openiboot.img3, loadibec und oibc nebeneinander liegen.

Danach müsst ihr euer Gerät in den Recovery-Modus versetzen. Dazu

  • das Gerät ausschalten
  • den Home-Button gedrückt halten
  • während der Home-Button gedrückt ist das Gerät per USB anschließen
  • warten, bis das iTunes-Symbol auf dem Display erscheint

Anschließend eine Rootshell (sudo -s) in dem Verzeichnis öffnen, in dem ihr die OpeniBoot-Dateien abgelegt habt. Nach der Installation von eventuell fehlenden Abhängigkeiten könnt ihr OpeniBoot in den Arbeitsspeicher des Geräts laden.

# apt-get install libusb-1.0-0 libusb-1.0-0-dev libreadline6-dev readline-common libreadline6 libreadline-dev
# ./loadibec openiboot.img3

Jetzt sollte OpeniBoot auf dem Gerät gestartet werden. Nun mit dem Power-Button “Console” auswählen und mit dem Home-Button bestätigen, was dazu führt, das auf dem Gerätebildschirm viel Text zu sehen ist. Nach Abschluss des Ladevorgangs seht ihr ein ASCII-Art:

 / _ \ _ __   ___ _ __ (_) __ )  ___   ___ | |_ 
| | | | '_ \ / _ \ '_ \| |  _ \ / _ \ / _ \| __|
| |_| | |_) |  __/ | | | | |_) | (_) | (_) | |_ 
 \___/| .__/ \___|_| |_|_|____/ \___/ \___/ \__|
      |_|

Die Console ist damit einsatzbereit. Sie wird aber nicht vom iPod touch aus bedient (gibt ja keine Bildschirmtastatur), sondern vom Terminal auf eurem Ubuntu-Rechner, indem ihr folgendes Kommando ausführt:

# ./oibc

Im Terminal wird jetzt dasselbe angezeigt wie auf dem Display des iPods, ähnlich einer SSH-Sitzung. Die eigentliche Installation wird über den Befehl

install

eingeleitet. wenn die Installation fertig ist, wird das Gerät neu gestartet durch den Befehl

reboot

OpeniBoot ist jetzt permanent installiert. Die Option “Android” existiert zwar schon, funktioniert aber noch nicht, schließlich ist Android noch gar nicht installiert. Dazu erst wieder iOS booten, Cydia öffnen und das Programm “Bootlace” installieren. Beim ersten Start von Bootlace wird das Gerät überprüft und ein Kernel Patch angewandt. Danach lässt sich im Tab “iDroid” Android in der Version 2.3.3 installieren (iDroid 11.04), updaten und auch wieder deinstallieren. Auch OpeniBoot kann über Bootlace konfiguriert werden, wie das Default-OS und die Wartezeit bis dieses gebootet wird. Die Installation/Deinstallation von OpeniBoot ist hier auch möglich, funktioniert bei mir aber nicht, weswegen ich den Weg über Terminal genommen habe. Außerdem wird auf diesem Weg automatisch eine Datei “norbackup.dump” erstellt, die beim Herstellen des Original-Bootloaders vielleicht nützlich sein könnte.

Endlich kann Android gebootet werden; der erste Start dauert etwas lang. Zu iOS zurück gelangt man, indem man Power- und Home-Button für etwa 2 Sekunden lang gemeinsam drückt und im darauf erscheinenden Fenster “Ausschalten” ausgewählt, danach kann man in OpeniBoot wieder iOS booten.

Was bringt da ganze? Nun, im gegenwärtigen Zustand ist iDroid eher als ein Proof-of-Concept zu verstehen, denn richtig Android nutzen geht damit nicht. So sind aus rechtlichen Gründen die Google Anwendungen nicht mit dabei, darunter der Market. Es bringt auch nichts, von anderen Geräten oder irgendwelchen Quellen im Internet den Market nachzuinstallieren, denn Google lässt nur autorisierte Geräte von Herstellern wie HTC, Motorola, Samsung etc in den Market. Einzelne *.apk Dateien lassen sich aber installieren. Die Geschwindigkeit ist auch etwas langsam, womöglich wegen der noch unreifen Unterstützung der Hardware. Außerdem fehlt es dem iPod touch an Knöpfen wie dem Menü- oder Zurück-Button, die aber durch On-Screen-Buttons in der Statusleiste ersetzt werden. Auch das Android-Plugin für Eclipse erkennt ein iDroid-Gerät sofern man das USB-Debugging aktiviert, eine simple Hello-World-Anwendung ließ sich aber nicht auf das Gerät übertragen und dort starten.

Positiv ist aber, das die neuste Android-Version 2.3.3 zum Einsatz kommt. Viele native Android-Geräte kommen mit 2.2, 2.1, oder gar noch älteren Versionen wie 1.6 daher, Updates vom Gerätehersteller gibt es nicht, also ein ähnliches Problem wie bei Apple.

Wie kriegt mans wieder runter? iDroid lässt sich wie bereits erwähnt über Bootlace deinstallieren. Für OpeniBoot muss man das Gerät wieder per USB an den Rechner anschließen und in OpeniBoot den Konsolen-Modus starten. Danach sind nur noch drei Befehle im Terminal auf dem Ubuntu-Rechner notwendig:

# ./oibc
uninstall
reboot

Fazit: Noch muss man ein bisschen warten, bis iDroid schneller und der Market nutzbar wird, aber auch jetzt kann man damit seinen Spaß haben. Für einen wirklich produktiven Einsatz muss natürlich früher oder später ein natives Android-Gerät her, zum testen taugt es aber, und bisher gefällt mir Android ganz gut, vor allem wegen der höheren Freiheit des Nutzers.

Aktuelles Eclipse selber paketieren

Seit meine Erinnerung zurückreicht wurde Eclipse von den Debian- und Ubuntu-Maintainern immer recht stiefmütterlich behandelt. Die sowohl in Ubuntu Natty als auch in Debian Sid verfügbare Version ist 3.5, obwohl seit Juni 2010 3.6 verfügbar ist. Externe Paketquellen habe ich bisher nicht gefunden (außer die hier, Eclipse stürzt hier nach dem Start ab und sie ist auch nicht für Natty gedacht), offensichtlich scheinen wenig Leute Interesse daran zu haben, Eclipse zu paketieren.

Ein Grund für die zögerliche Paketierung könnte sein, dass Eclipse ja bereits eine interne Paketverwaltung mitbringt, über die Plugins mittels Paketquellen installiert werden können. Sogar auf dem App-Store-Zug sind die Entwickler aufgesprungen. Hier stellt sich die Frage, ob man Plugins auch mitpaketieren sollte, was von Debian und Ubuntu jedenfalls für beliebte Plugins gemacht wird. Da es nicht oder nur mit großem Aufwand möglich ist, APT und die Eclipse-Paketverwaltung zur Zusammenarbeit zu bewegen, existieren sie nebeneinander und das find ich unschön. Ich benutze nicht gerne zwei Werkzeuge parallel für den selben Zweck, ich möchte nicht einen Teil meiner Plugins über APT verwalten und den anderen Teil über Eclipse selbst.

Deswegen bin ich dazu übergegangen, mir nur ein “nacktes” Eclipse über APT zu installieren und die Plugins über Eclipse selber. In den Paketquellen gibt es ja das Paket eclipse-platform, welches ein solches nacktes Eclipse enthält, aber wie oben erwähnt veraltet ist. Das lässt sich aber dadurch kompensieren, indem man sich Eclipse selbst über die Projektseite herunterlädt und in ein eigenes Paket verbaut.

Auf der Download-Seite werden aber nur vorkonfigurierte Bundles angeboten, die bereits irgendwelche Plugins enthalten. Etwas versteckt lässt sich aber eine pluginlose Version besorgen, indem man auf diese Seite geht und bis zu “Platform Runtime Binary” scrollt. Hier muss die für die Rechnerarchitektur passende Version heruntergeladen werden.

In diesem Beispiel nutze ich amd64/x86_64. Wer eine andere Architektur hat, 
muss die Befehle oder Datei-Inhalte ggf. anpassen, also nicht einfach den Guttenberg machen.

Bevor losgelegt werden kann, müssen aber noch einige Tools installiert…

$ sudo apt-get install fakeroot dpkg-dev debhelper unp

…und ein Arbeitsverzeichnis angelegt werden:

$ mkdir eclipse-platform

Innerhalb dieses Arbeitsverzeichnisses müssen nun die Ordner so angelegt werden, wie sie später auf dem Dateisystem abgebildet werden sollen. Legt man also innerhalb des Ordners eclipse-platform den Ordner bin an und speichert dort Dateien, so werden diese Dateien später nach /bin installiert. Ich lasse den Inhalt des Archivs nach /opt/eclipse installieren:

$ unp eclipse-platform-3.6.2-linux-gtk-x86_64.tar.gz
$ mkdir -p eclipse-platform/opt
$ mv eclipse eclipse-platform/opt/eclipse

Anschließen erstellen wir ein Skript, mit dem wir Eclipse starten können:

$ mkdir -p eclipse-platform/usr/bin
$ nano eclipse-platform/usr/bin/eclipse
$ chmod +x eclipse-platform/usr/bin/eclipse

Das Skript versehen wir mit folgenden Inhalt:

#!/bin/sh
export UBUNTU_MENUPROXY=0
exec /opt/eclipse/eclipse "$@"

Das setzen der Variable UBUNTU_MENUPROXY sorgt dafür, dass Eclipse sein Menü im Fenster und nicht im Unity-Panel anzeigt, weil letzteres noch nicht gut genug mit SWT-Anwendungen funktioniert (Update: Ab Eclipse 3.7 ist die Zeile unnötig, Eclipse zeigt per Default sein Menü im Fenster an). Nicht-Unity-Benutzer können das ignorieren. “$@” bewirkt, dass dem Skript mitgegebene Parameter an Eclipse weitergereicht werden. Nun müssen wir nur noch einen Menüeintrag erstellen, damit wir Eclipse auch grafisch starten können…

$ mkdir -p eclipse-platform/usr/share/applications
$ nano eclipse-platform/usr/share/applications/eclipse.desktop

…und zwar mit diesem Inhalt:

[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=Eclipse
Exec=eclipse
Terminal=false
Icon=/opt/eclipse/icon.xpm
Comment=Eclipse Integrated Development Environment
Categories=Development;IDE;

Nun haben wir also ein Startskript, einen Anwendungsstarter sowie einen Programmordner. Fehlen nur noch Informationen, die das Paket näher beschreiben, damit auch APT was damit anfangen kann.

mkdir eclipse-platform/DEBIAN
nano eclipse-platform/DEBIAN/control

In die control-Datei schmeißen wir das da rein:

Package: eclipse-platform
Version: 3.6.2-1
Architecture: amd64
Maintainer: DeinName
Depends: openjdk-6-jre | sun-java6-jre
Section: devel
Priority: optional
Description: Eclipse IDE, static-linked, minimal plugins.

Die Abhängigkeiten sehen natürlich etwas mager aus, nur Java ist drin, was Eclipse zum Laufen benötigt, aber nicht selbst mitbringt. Alles andere ist bei Eclipse eigentlich dabei und nach den Debian-Richtlinien müsste man eigentlich alles sauber in unabhängige Paketteile aufsplitten, um Redundanzen zu vermeiden, aber das würde das hier zu kompliziert machen. Auf diese Weise sind wir aber jetzt schon fertig und können mit dem verpacken beginnen und die Installation einleiten:

$ fakeroot dpkg -b eclipse-platform eclipse-platform_3.6.2-1_amd64.deb
$ sudo dpkg -i eclipse-platform_3.6.2-1_amd64.deb

Das fakeroot bitte nicht vergessen, sonst werden die Rechte nicht richtig gesetzt!

Eclipse sollte jetzt problemlos und ohne irgendwelche Plugins starten. Damit man jetzt anfangen kann, Eclipse zu benutzen, muss man natürlich erst über Help->Install New Software.. die benötigten Plugins installieren. Zuvor muss jedoch noch die Update-Site von Eclipse hinzugefügt werden, dazu Eclipse starten und zu Window->Preferences->Install/Update->Available Software Sites navigieren und diese URL hinzufügen:

http://download.eclipse.org/releases/helios

Frohes Entwickeln!

Warum Unity gut für den freien Desktop ist

Am heutigen Tage ist die neue Ubuntu-Version 11.04 “Natty Narwhal” erschienen. Dies ist ein wichtiges Release für Ubuntu, weil es nicht mehr wie seit dem ersten Release 4.10 auf GNOME mit dem klassischen Panel als Standard-Desktop setzt, sondern auf eine Eigenentwicklung namens Unity. Über Unity wurde seit der Bekanntmachung und während der Beta-Phase viel diskutiert und geredet, einige haben konstruktive Kritik angebracht, andere haben sich beschwert, dass Unity nicht genauso ist wie ihr alter Desktop und dass sie jetzt (mal wieder) zu Debian oder dessen Derivaten wechseln.

Jedoch ist Unity auch nicht ausgelegt auf Leute, die in Erwägung ziehen, Debian zu benutzen. Zwar ist Debian eine super Distribution ohne die Ubuntu nicht existieren würde und die auf Servern eine sehr gute Figur macht, und auch auf Desktops, deren Anwender Zeit haben, ihr System ihren Wünschen entsprechend zu konfigurieren, und es mag sicherlich eine Schnittmenge der Ubuntu- und Debian-Zielgruppen geben, aber Ubuntu will auf die Desktop der Massen. Der normale Desktop-Anwender konfiguriert nicht tausende von Stellschrauben, er macht sich nicht einmal die Mühe, die Einträge im Windows-Startmenü vernünftig zu ordnen, stattdessen fliegt alles irgendwo rum.

Eine Revolution des Desktop ist nötig

Mal ehrlich: Das Bedienkonzept, das klassische Desktopoberflächen mitbringen, hat versagt. Wer schon einmal Leute beim Arbeiten beobachtet hat, die von Computern wenig verstehen, dem wird auffallen, dass sie ihre Arbeit viel effizienter und schneller erledigen könnten, sie aber die entsprechenden Funktionen gar nicht kennen und viele Dinge total umständlich bewältigen. Der Anwender versucht, die Unzulänglichkeiten der GUI zu kompensieren, obwohl die GUI eigentlich den Anwender unterstützen sollte!

Man könnte meinen, dass Windows dies noch besser hinkriegt als Linux und es deswegen auch weiter verbreitet ist. Der Grund, warum noch so viele Leute Windows benutzen, ist jedoch nicht, dass die Oberfläche so toll ist. Die große Stärke von Windows ist und bleibt die Kompatibilität, durch seine hohe Verbreitung gibt es fast nichts, was damit nicht funktioniert, und Microsoft kommt auch nicht auf die Idee, alle paar Releases komplette Subsysteme durch neue zu ersetzen, wodurch Entwickler eine höhere Sicherheit haben. Linux kann und wird Windows niemals im Bereich Kompatibilität überholen, weil es dafür einen höheren Marktanteil haben müsste, für den es aber mehr Kompatibilität braucht. Also muss Linux auf anderen Gebieten punkten, und zwar auf dem Gebiet der Usability.

Genau dieser Mission hat sich offenbar Canonical mit Ubuntu verschrieben. Keine Distribution, keine Desktop-Umgebung, ob GNOME oder KDE, hat es bisher geschafft, Linux auf die Desktops der Massen zu bringen. KDE nicht, was wohl der leistungsfähigste Desktop sein wird, von dem der Laie durch seine vielen Konfigurationsoptionen und durch die ganzen Features und die verschiedenen Möglichkeiten, eine Sache zu machen, jedoch total überfordert ist. Das altbackene GNOME 2 lockt heute auch niemanden hinterm Ofen vor. Einzig Compiz hat dafür gesorgt, dass es noch zeitgemäß blieb.

Also müssen neue Konzepte erarbeitet werden, der klassische Desktop muss umgekrempelt werden hin zu neuen Paradigmen, die von normalen Menschen besser verstanden werden können. Apple setzt die Messlatte hier hoch an, mit dem iPad hat das Unternehmen einen neuen Formfaktor salonfähig gemacht, und mit Mac OS X 10.7 alias “Lion” wird es ebenfalls mit “Launchpad” und “Mission Control” einige Umwälzungen geben. KDE ist mit Plasma und KWin schon etwas in diese Richtung gegangen, wesentlich weiter geht hier überraschenderweise GNOME (verkehrte Welt, irgendwie) mit der GNOME Shell, welche ein völlig neues Bedienkonzept einführt. Es gibt keine Applets und kein Anwendungsmenü mehr, stattdessen läuft das Starten und das Wechseln zwischen Anwendungen und der ganze Rest über den Aktivitäten-Bildschirm ab. Das kürzlich erschienene GNOME 3.0 macht alles anders wie sein Vorgänger, alte Konzepte werden komplett über Bord geworfen und durch neue ersetzt. Die ganzen Neuerungen kann man sehr schön im Standard nachlesen.

Jetzt wird man sich natürlich fragen, warum Ubuntu nicht einfach GNOME 3 mit ausliefert, schließlich decken sich doch die Ziele der beiden: nämlich einen Desktop zu entwickeln, welcher von jedem gut bedient werden kann und diesen Desktop dann auch an den Mann zu bringen.

Probleme von GNOME 3

Das Problem ist, dass GNOME dieses Ziel zwar anpeilt, es aber übertreibt und deswegen verfehlt. Während KDE alle Macht dem Nutzer geben will, damit dieser sich seinen Desktop selber gestallten kann, glaubt GNOME, alles besser zu wissen und nimmt dem Nutzer so gut wie alle Konfigurationsmöglichkeiten. Ein Desktop, welcher es dem Nutzer nicht einmal erlaubt, den Computer auszuschalten, kann nicht dazu beitragen, die Verbreitung des Linux-Desktop zu fördern. Und der Hinweis, man könnte die Option über Konfigurationseditoren oder das Terminal wieder aktivieren, führt genau zu dem Ruf, den Linux heute hat, nämlich dass man selbst für alltägliche Aufgaben das Terminal braucht oder man in der Dokumentation nachlesen muss (da steht nämlich, dass durch Drücken der ALT-Taste der Eintrag “Ausschalten” wieder angezeigt wird).

Weiterhin benötigt GNOME 3.0 zwingend 3D, weil der Fenstermanager Mutter mit Clutter arbeitet, was nunmal OpenGL erfordert. User ohne funktionierende 3D-Unterstützung landen in einem Fallback-Modus, welche GNOME 2 nachgeahmt ist, aber nur einen Brucheil der Funktionen bietet und daher eher eine Notlösung ist. Dies betrifft alle User, die eine aktuelle AMD- oder Nvidia-Grafikkarte im Rechner haben und ein Linux-System über die Live-CD ausprobieren. Aus lizenzrechtlichen Gründen kann man die nötigen proprietären Treiber nicht mitliefern.

Ein weiterer Nachteil der GNOME Shell ist, dass sie auf Netbooks keine gute Figur macht. War Linux doch das Standard-System auf dem ersten Netbook, dem eee PC 701, so sollte genau dort der Fokus liegen. Die GNOME Shell erfordert allerdings viel Mausbedienung, was ja gerade mit einem Touchpad eher hinderlich ist. Unter GNOME 2 konnte man mit Compiz über entsprechende Tastenkombinationen viel effizienter navigieren. GNOME 3 benötigt hier auch massig Platz, die Fenster sind klobig und das Panel zu dick, hinzu kommt noch das Menü und die Titelleiste – gerade auf kleinen Displays auf denen jeder Pixel zählt ein Ärgernis.

Vorteile von Unity

Hier kommt Unity ins Spiel, denn es setzt auf das bewährte, stabile und leistungsfähige Compiz. Dies ist ein Riesenvorteil. Compiz war eine der Anwendungen, die mich letztendlich zum Wechsel auf Linux und damit Ubuntu bewegt haben. Die schönen Effekte waren zwar ganz nett, aber mit Compiz und den entsprechenden Plugins ist das Arbeiten viel effizienter. Unter der GNOME Shell müsste ich auf all das verzichten. Warum war es nötig, Compiz über Bord zu werfen und einen neuen Fenstermanager namens Mutter zu entwickeln, der im Endeffekt das gleiche machen soll?

Weiterhin funktioniert Unity auch ohne 3D-Beschleunigung. Zwar ist Unity eigentlich ein Plugin für den 3D-Fenstermanager Compiz, doch die Ubuntu-Entwickler haben einfach Unity2D aus der Taufe gehoben, welche letzendlich genauso funktionieren soll wie das normale Unity, welches aber mit dem traditionellen 2D-Fenstermanager Metacity zusammenarbeitet.

Unity setzt auch viel mehr auf Tastenbedienung. Programme startet man am besten, indem man die Super-Taste drückt und anfängt, den Programmnamen zu tippen. Sobald das gewünschte Programm in den Suchergebnissen erscheint, drückt man Enter. Also genauso, wie es bereits Launcher wie GNOME Do gemacht haben. Hier kommt mir Unity sehr entgegen, weil ich das bereits so gewohnt bin.

Auch Docks habe ich bisher immer genutzt. Das Dock von Unity ist auch sehr schön umgesetzt, es arbeitet wie alle Docks programmorientiert, nicht fensterorientiert. Hat ein Programm mehrere Fenster, wird beim Klicken auf das Icon das Scale-Plugin von Compiz aktiviert, wodurch die Fenster des Programms in einer Übersicht dargestellt werden. Hält man die Super-Taste gedrückt, werden einem die Shortcuts angezeigt, mit denen man die Programme leichter starten kann. Die von Windows 7 abgeschauten Qucklists sind auch ziemlich praktisch, auch wenn man hier bei mehr Programmen Unterstützung einbauen sollte, was man aber auch selber machen kann, siehe das Beispiel links.

Das Arbeiten mit Workspaces funktioniert nun endlich benutzerfreundlich. Gerade Anfänger kamen mit der bisherigen Funktion in GNOME 2 nicht zurecht und haben sich gewundert, wo ihre Fenster jetzt sind und und haben gar nicht verstanden, was Workspaces eigentlich sind. Die grafische Unity-Umsetzung macht das einiges besser, auch wenn ich mir die Möglichkeit wünschen würde, zusätzliche Workspaces hinzufügen oder entfernen zu können, wie es etwa die GNOME Shell bietet.

Das Panel von Unity ist ebenfalls ein willkommene Verbesserung. Durch das globale Menü, genannt AppMenu, wird die Menüleiste in das Panel verlegt, d.h die Fenster haben nun kein eigenes Menü mehr, stattdessen wird das Menü des aktiven Fensters im Panel angezeigt (vgl. das Globalmenu-Project, welches ähnliches unter GNOME 2 realisiert). Wird das Fenster aktiviert, werden auch die Fensterknöpfe und der Fenstertitel ins Panel verlagert (jetzt weiß man auch, warum Mark die Fensterknöpfe unbedingt links haben wollte). Das Menü ist dann ein Overlay, welches beim darauffahren erscheint. Dies ist ein echter Platzgewinn auf kleinen Displays. Unity hält sich immer dezent zurück und schiebt sich nicht ständig in den Vordergrund, um Platz zu verschwenden oder den Nutzer zu nerven, es ist recht minimalistisch und damit für Netbooks erst recht geeignet.

Auch merzt das Panel einige Bugs aus, die mich beim alten GNOME Panel genervt haben. Oftmals bekam ich die Meldung, dass irgendein Applet nicht geladen werden konnte. Ein beherztes killall gnome-panel half dann meistens. Manchmal wurde auch die Reihenfolge der Applets vertauscht, die man dann mühevoll wieder richtig sortieren musste. Der Benachrichtigungsbereich war auch ziemlich durcheinander, die Icons hatten unterschiedliche Größen und Abstände, das Klickverhalten machte auch jeder anders, Die neuen Indikatoren in Unity sehen aus wie aus einem Guss, sie haben alle den gleichen monochromen Stil und den gleichen Abstand, öffnen tunt sie sich per Linksklick. Leider lassen sich die Indikatoren nicht konfigurieren. Ich würde mir noch wünschen, dass man die z.B per gedrückter mittlerer Maustaste umsortieren kann.

Beide kochen nur mit Wasser

Generell lässt die Konfigurierbarkeit von Unity sehr zu wünschen übrig. Defaultmäßig gibt es folgendes Konfigurationsmenü:

Zwar lässt sich durch die Installation des CompizConfig Setting Managers wesentlich mehr konfiguerieren, auch über den dconf-editor lässt sich einiges einstellen. Jedoch bringt uns das wieder zu GNOME 3, wo auch immer argumentiert wird, dass man ja über entsprechende Tools alles konfigurieren könnte. Dies ist jedoch nicht benutzerfreundlich, Der Desktop muss sinnvolle Voreinstellungen bieten sowie ein Werkzeug, in dem man einige Einstellungen tätigen kann, die jeder User versteht, und dann zusätzlich noch die Möglichkeit mehr zu konfigurieren für erfahrene Anwender – wegen mir auch über die Kommandozeile oder den dconf-edior.

Ein weiterer negativer Punkt an Unity ist die Zahl der Bugs und Implementierungsfehler. Da wären diese neuen Overlay-Scrollbars, wie man sie etwa vom iPhone kennt. Diese funktionieren in einigen vorinstallierten Anwendungen wie Firefox oder LibreOffice, aber auch in nativen GTK+-Anwendungen wie Geany nicht. Offensichtlich müssen die Anwendungen gepatcht werden, und bei Nicht-GTK+-Anwendungen funktionieren die Scrollbars sowieso nicht. Die Fensterschatten sind nicht mehr änderbar (was aber gewollt ist, siehe Bug #708963), am meisten Probleme bereitet jedoch das AppMenu: So funktioniert das Accel-Changing bei GTK+-Anwendungen nicht, bei SWT-Anwendungen wird erst gar kein Menü angezeigt, es gibt Fehler in Menüs, die eigene Icons verwenden und wenn man die automatische Fensterselektion aktiviert hat ist es nahezu unmöglich, das Menü zu erreichen.

Ein Problem, welches zwar nicht direkt die Anwender, wohl aber die Entwickler betrifft ist, dass die 3D-Version und die 2D-Version von Unity völlig unterschiedliche Codebasen besitzen. Unity2D ist in C++ geschrieben, was für etwas so wichtiges wie eine Desktop-Shell ja sinnvoll ist, und es verwendet das Framework Qt, welches bereits in KDE und vielen anderen freien wie unfreien Projekten zum Einsatz kommt. Unity3D jedoch ist in der relativ unbekannten Sprache Vala geschrieben und in dem noch unbekannteren Toolkit Nux, dass sonst keiner benutzt. Mir wäre es lieber gewesen, die Entwickler hätten eine Unity-Version erstellt, welche dann mit einem optionalen Compiz-Plugin etwa via D-Bus kommuniziert und so die Effekte zeichnet, wenn es Hardware und Treiber erlauben (allerdings ist D-Bus in Compiz gerade kaputt). KWin bekommt es ja auch hin, unabhängig von vorhandener 3D-Unterstützung zu funktionieren und bietet sogar noch mit XRender, OpenGL und OpenGL ES verschiedene Backends an.

Dies alles sind aber Dinge, die Unity und GNOME Shell gleichermaßen betreffen und bei jungen Projekten immer zu erwarten sind. Die Bugs werden früher oder später gefixt werden, und vielleicht haben die GNOMEler doch ein Einsehen, überdenken ihr Konzept und lassen dem User etwas mehr Freiheiten. Unity hingegen sollte sich etwas mehr Konzept überlegen, eine Shell im Laufe der Entwicklung ständig auf verschiedene Toolkits zu portieren (GTK+, Clutter, Qt, Nux) erzeugt nur Aufwand und frisst Zeit, die nötig ist, das Programm weiterzuentwickeln.

Abwarten und Tee trinken

Zwar halte ich Unity für das bessere Konzept, weil es nicht ganz so radikal ist wie GNOME 3 und einige alte Konzepte beibehält, etwa einen ständig sichtbaren Programmwechsler, das Beibehalten von Desktop-Icons und das Setzen auf das bewährte Compiz. Jedoch bricht die Konkurrenz zwischen Unity und GNOME Shell den Monolithismus, der unter den Desktop-Umgebungen früher vorherrschte. Man musste sich zwischen GNOME und KDE entscheiden, und damit auch zwischen GNOME- und KDE-Anwendungen. Es ist besser, sie auf die eigentliche Shell zu konzentrieren, die Anwendungen vom Desktop unabhängiger zu machen und auf gemeinsame Standards (hörst du, Canonical?) zu setzen. KDE hat sich auch deswegen in KDE SC (Software Compilation) umbenannt, um darauf hinzuweisen, dass der KDE-Desktop eben nur eine mögliche Zusammenstellung aus Komponenten ist, und man auch einzelne Komponenten anders verwenden kann. Nun hat der Nutzer die Wahl zwischen Unity, GNOME Shell und Plasma sowie zahlreichen weiteren Shells, die Basis-Komponenten sollten jedoch die gleichen sein. Es ist eine totale Usability-Bremse, wenn der Nutzer eine Anwendung installiert und diese plötzlich ein anderes Schlüsselbund-System verwendet.

Letztendlich wird die Zeit zeigen, welches Konzept den Nutzern besser gefällt. Wird Unity ein Flop, kann man immer noch zu einer anderen Distribution wechseln und man hat nichts verloren. Und wenn niemand GNOME Shell verwenden will, kommt das nur Ubuntu zu gute (darauf spekuliert Canonical wohl). Und wenn alle Stricke reißen bleibt noch XFCE und KDE übrig. Hier sieht man einen großen Vorteil des Linux-Desktop: Das man sich bei Design-Revolutionen, die einem nicht gefallen, nicht nur die Möglichkeit hat, auf der alten Version zu bleiben, sondern man aus zahlreichen Alternativen wählen kann. Darum ist Unity gut für den freien Desktop: Alle Projekte strengen sich an, dem Nutzer das beste Erlebnis zu bieten, und am Ende überlebt das beste Konzept.