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.

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?

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.

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.

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.

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]

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.

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.

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!

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.

Normalerweise lädt Ubuntu beim Booten oder beim Anschluss des Geräts das dafür passende Kernelmodul. Danach kann man mit dem Gerät schon loslegen. In diesem Fall aber (und offenbar in vielen anderen Fällen auch) lud Ubuntu zusätzlich zum richtigen Modul noch einige falsche Module für ähnliche Chipsätze. Dies sorgt allerdings dafür, dass das System nun nicht weiß, welches Modul die Kontrolle über den WLAN-Stick haben soll und deswegen kam keine Verbindung zustande.

Um das Problem zu lösen, sollte man sich ersteinmal alle geladenen WLAN-Module anzeigen lassen. Da mein Stick einen Ralink-Chipsatz benutzt, lautet der Befehl

$ lsmod | grep rt

Der Hersteller des Sticks bzw. der WLAN-Karte ist unwichtig, wichtig ist nur der Chipsatz (z.B Atheros, Broadcom oder eben Ralink). Wer einen anderen Chipsatz als ich hat, muss in Erfahrung bringen, welches Präfix die entsprechenden Module haben (das ubuntuusers-Wiki ist eine gute Anlaufstelle). Die Ausgabe schaut bei mir folgendermaßen aus:

parport_pc 36959 0
parport 46458 3 parport_pc,ppdev,lp
rt2870sta 450556 0
rt2800usb 18235 0
rt2800lib 45181 1 rt2800usb
crc_ccitt 12667 2 rt2870sta,rt2800lib
rt2x00usb 20330 1 rt2800usb
rt2x00lib 49235 3 rt2800usb,rt2800lib,rt2x00usb
mac80211 294370 3 rt2800lib,rt2x00usb,rt2x00lib
cfg80211 178528 2 rt2x00lib,mac80211

Hier sind nur die Module interessant, die mit “rt” anfangen. Diese werden jetzt allesamt entladen:

$ sudo modprobe -rf rt2870sta rt2800usb rt2800lib rt2x00usb rt2x00lib

Jetzt kommt das Ausprobieren. Man muss jetzt probieren, welches Modul das richtige ist. Also mit

$ sudo modprobe <modulname>

das Modul laden, ausprobieren, ob das WLAN läuft und wenn nicht, das Modul mit

$ sudo modprobe -rf <modulname>

wieder entladen. Glücklicherweise wusste ich schon von meiner Maverick-Installation, dass das Modul rt2870sta das richtige ist. Nach dem Laden dieses Moduls funktionierte auch das WLAN wieder.

Eine Kleinigkeit wäre da noch: Damit man das Prozedere nicht bei jedem Neustart wiederholen muss, sollte man die falschen Module blacklisten. In meinen Fall reicht es, folgende Zeilen zur Datei /etc/modprobe.d/blacklist.conf hinzuzufügen:

blacklist rt2800usb
blacklist rt2800lib
blacklist rt2x00usb
blacklist rt2x00lib

Es freut mich zwar, dass das Problem so einfach zu lösen war, aber Anfänger werden dadurch abgeschreckt. Wegen der neuen Unity-Oberfläche wird Natty sowieso ein heikles Release werden. Hoffen wir, dass es nicht das Vista der Ubuntu-Versionen wird

Update 2.Juni 2011:

Wie aus den von mir gemeldeten Launchpad-Bug hervorgeht, hatte ich mit meiner Einschätzung nicht ganz recht. Alle Module, die beim Hochfahren/Einstecken des DWA 140 geladen werden, sind richtige Treiber, die für den Stick geeignet sind. rt2870sta ist ein alter Staging-Treiber, der nicht offiziell zum Kernel gehört, nicht wirklich gepflegt wird und der irgendwann mal verschwinden wird. Der neue Treiber der ihn ersetzen soll ist dieser rt2800usb, welcher auch von den Wifi-Schnittstellen des Kernels besser Gebrauch macht. Die in Natty enthaltene Version dieses Treibers funktioniert aber mit meinem Stick noch nicht, weil linux-firmware zu alt ist. rt2800usb wird also geladen, kann aber nicht arbeiten, daraufhin wird rt2870sta geladen, welcher aber auch nicht arbeiten kann, weil rt2800usb nicht entladen wurde.

Eine bessere Alternative zu dem oben vorgestellten Lösungsvorschlag ist die Benutzung von rt2800usb mit aktueller Firmware, weil dieser Treiber besser gepflegt wird. Zuerst muss rt2870sta geblacklistet werden:

 
$ echo 'blacklist rt2870sta' | sudo tee -a /etc/modprobe.d/blacklist.conf

Das Blacklisting der anderen rt-Module muss natürlich rückgängig gemacht werden. Anschließend lädt man sich die neueste Version von linux-firmware herunter und entpackt das Archiv. Einzig die Datei rt2870.bin ist interessant. Nun wird die alte Firmware umbenannt und die neue installiert:

$ cd <entpackter Ordner>
$ sudo mv /lib/firmware/rt2870.bin /lib/firmware/rt2870.bin.old
$ sudo cp rt2870.bin /lib/firmware/rt2870.bin

Nach einem Neustart sollte das drahtlose Netzwerk wieder funktionieren. Am besten, man testet beide Treiber und nutzt dann den, welcher besser läuft.

Was ist neu in Xonotic 0.1 im Vergleich zu Nexuiz 2.5.2? Zum einem wäre da das neue HUD, also die ganzen Anzeigen, die während des Spiels angezeigt werden. Durch den neuen HUD-Editor lassen sie sich jetzt völlig frei anordnen, wie es dem Spieler gefällt. Man erreicht ihn mit Multiplayer->Player setup-> Enter HUD editor.

Zum anderen gibt es jetzt neue Bewegungsabläufe, wie etwa das Bunnyhopping, bei dem man wie ein Känguru vorwärts springt und somit immer mehr an Bewegung gewinnt (ähnlich dem Bunnyjumping in Warsow). Das und noch viel mehr wird in einem schönen Video erklärt, welches die Macher veröffentlicht haben:

Weiterhin gibt es neue Maps, neue Spielermodelle, neue Fadenkreuze, eine neue Waffe (der “Minenleger”) sowie die Möglichkeit, sich bei einem Multiplayer-Spiel am Server zu authentifizieren, um etwa Namenklau zu vermeiden oder um Ranglisten zu speichern.

Die Preview kommt in einem einzigen ZIP-File daher, welches über BitTorrent oder HTTP bezogen werden kann und in dem Binaries für Linux32, Linux64, Windows32, Windows64 und Mac OS X (Universal Binary) enthalten sind. Für Linux-Nutzer empfehle ich, Xonotic unter einem eigenen X-Server zu starten, um bessere Performance zu erzielen. Das Skript startet dabei die zur Architektur passende Binary:

$ startx ./xonotic-linux-sdl.sh -- :1

Xonotic und ein eventuell installiertes Nexuiz kommen sich nicht in die Quere. Wer Platz sparen will, kann die Windows- und Mac-Binaries sowie den mitgelieferten Quelltext löschen.

Abschließend kann man sagen, dass die Preview Lust auf mehr macht und zeigt, dass die Community um Nexuiz/Xonotic nicht tot ist. Forks wie dieser scheinen ja mittlerweile richtig in Mode gekommen zu sein, wenn man an OpenOffice/LibreOffice, Solaris/Illuminos oder MySQL/MariaDB denkt. Allerdings wurde Nexuiz/Xonotic schon immer durch die Community entwickelt, wodurch bei einem Fork nicht so viel Entwicklerressourcen flöten gehen. Hoffen wir, dass sich das Spiel gut entwickelt und weitere Releases bald folgen.

Trotzdem läuft nicht immer alles rund. Manchmal bekommt man mitten im Spiel eine Benachrichtigung von einem Chat-Programm, dem BitTorrent-Client usw, welche sich dann lästig ins Bild schiebt und den Spielfluss stört. Vielleicht erfordert die Benachrichtigung auch eine Interaktion und man möchte kurz auf die Arbeitsfläche wechseln, was aber schwierig sein kann, wenn das Spiel im 3D-Modus läuft. Zwar geht dies manchmal über Tastenkombis, aber diese können bereits vom Spiel belegt sein und nicht funktionieren, schlimmstenfalls stürzt das Spiel sogar ab.

Die Wurzel des Problems liegt darin, dass das Spiel über der eigentlichen Arbeitsfläche gestartet und daher ein Wechsel erschwert wird. Die Lösung ist daher, Spiel und Arbeitsfläche parallel und unabhängig von einander zu starten – unter Linux ist das ganze auch problemlos möglich.

Auf einem Linux-System wird die Grafikanzeige bekanntermaßen nicht direkt vom Kernel erledigt, sondern von einem eigenen Programm, dem X-Server (der aber auch mit dem Kernel kommuniziert). Ubuntu startet standardmäßig nur eine Instanz von X, welche dann über die Tastenkombi Strg+Alt+F7 erreichbar ist. Über Strg+Alt+F1 bis Strg+Alt+F6 sind virtuelle Terminals erreichbar. Mit einem dieser Terminals kann man eine zweite X-Instanz starten, zu welcher dann über Strg+Alt+F8 gewechselt werden kann.

Dazu wechselt man zuerst in so ein virtuelles Terminal, nehmen wir mal tty1 (Strg+Alt+F1). Dort müssen wir uns erneut mit unserem Nutzernamen und Passwort anmelden. Anschließend können wird mit dem Befehl xinit ein beliebiges Programm unter unserem zweiten X-Server starten, hier exemplarisch für Nexuiz:

$ xinit nexuiz -- :1

:1 steht hier für das zweite X-Display, :0 wäre des erste. Nexuiz sollte jetzt starten, mit Strg+Alt+F7 kann man nun wieder zur graphischen Oberfläche zurückkehren und mit Strg+Alt+F8 wieder zu Nexuiz. Der zweite X-Server wird automatisch beendet, wenn Nexuiz nicht mehr läuft. Sollte sich Nexuiz aufhängen, kann man einfach wieder auf das Terminal zurückwechseln, auf welchen man den zweiten X gestartet hat, und das Programm mit Strg+C beenden. Die graphische Oberfläche bleibt in jedem Fall unbeschadet.

Dasselbe funktioniert natürlich auch mit jedem anderen graphischen Programm, z.B dem Texteditor gedit:

$ xinit gedit -- :1

Hier kann man schön den Aufbau von X sehen: Das gedit-Fenster hat keine Titelleiste, diese wird also nicht von X selbst, sondern vom Fenstermanager gezeichnet, welcher auf :0 läuft. Auch Theme-Engine, Hintergrundbild oder gar Desktopeffekte werden von eigenen Programmen dargestellt. Dies ist von den Entwicklern so gewollt, um eine bessere Vielfalt zu gewährleisten, wie das unter Linux immer so ist.

Wenn ich mich früher mit X beschäftigt habe, dann nur, weil die Auflösung nicht richtig gesetzt wurde, oder weil die Anzeige zu langsam war, was zum herum-editieren in der xorg,conf führte. Mittlerweile funktioniert sowas aber automatisch und man kann endlich vom lange gepriesenen Potenzial von X profitieren. Versucht das mal unter Windows

Getestet habe ich das ganze unter Ubuntu 10.10 64-Bit mit X-Server 1.9 und dem proprietärem NVIDIA-Treiber in der Version 260.19.06.

Edit:
Man kann das ganze natürlich noch weiter treiben und einen dritten X-Server starten, auf dem dann z.B Sauerbraten läuft:

$ xinit sauerbraten -- :2

Der dritte X-Server ist dann über Strg+Alt+F9 erreichbar. Solange der Rechner leistungsfähig genug ist, geht das ohne Probleme und beide Spiele laufen flüssig. Grundsätzlich scheint es mir so, dass Spiele auf einem separatem X einen Tick flüssiger laufen.

flattr will das Spenden stark vereinfachen. Wer sich bei flattr anmeldet, zahlt eine monatliche Gebühr. Anschließend kann diese Gebühr bei Blogs und anderen Websites gespendet werden, indem man auf den flattr-Button unter dem Blogpost klickt. Am Ende des Monats wird die Summe in soviele Stücke aufgeteilt, wie man den flattr-Button geklickt hat und auf die Blogger verteilt. am Besten erklärt es folgendes Video:

Man mag von flattr halten was man will, und es gibt im Netz viele Diskussionen darüber, ob flattr sinnvoll ist oder nicht, aber das soll gar nicht Thema dieses Beitrags sein. Fakt ist, dass es im Planeten einige Blogger gibt, die flattr benutzten und den flattr-Button auch im RSS-Feed eingebunden haben, sodass er dann auch im Planeten zu sehen ist. Dies kollidiert aber nach Meinung des ubuntuusers-Teams mit den Regeln (siehe Ikhaya-Eintrag):

„Werbung für Unternehmen, kommerzielle Produkte und Waren, Dienstleistungen, politische Parteien und extremistische Gruppierungen sowie Jobgesuche und -angebote sind nicht gestattet.“

Chris, der hinter dem Blog Linux und Ich steht (und dort hervorragende Artikel schreibt), gab daraufhin bekannt, dass seine Artikel zukünftig nicht mehr im Planeten erscheinen werden. In den Kommentaren entstand eine heftige Diskussion und auch Martin (der auch hervorragende Artikel schreibt) äußerte sich in seinem Blog darüber.

Einige Leute vergleichen Blogger, die flattr einsetzen, mit kostenpflichtigen Supportern, die sich auf Kosten der Community die Taschen vollstopfen und den Grundgedanken von Open Source untergraben würden, während andere es völlig in Ordnung finden, dass sich Menschen, die freiwillig Zeit investieren, um Content für die Community zu generieren, auch dafür entlohnt werden.

Im Grunde ist es eine ähnliche Diskussion wie damals vorm Release von Ubuntu 10.04. Dort hat Canonical das Design seiner Distribution radikal überarbeitet, dieser Umstand zusammen mit der Tatsache, dass mit Ubuntu auch weitere kostenpflichtige Dienste wie Ubuntu One angeboten werden, führten zu einer ähnlichen Diskussion mit ähnlichen Argumenten. Die Kernfrage lautet eigentlich: Kann man Freiheit und Kommerz vereinen?

Damals hatte ich auch schon einen Artikel darüber geschrieben und ich bleibe bei meiner Aussage: Ja, kann man! Viel zu oft wird von Befürwortern von Open Source betont, dass freie Software nicht mit Freibier gleichzusetzen sei, sondern mit Freiheit und man damit auch Geld verdienen könne (Red Hat sei hier als Beispiel genannt).

Wegen der GPL und anderen Lizenzen kann man freie Software nicht genauso wie proprietäre Software verkaufen, weswegen meist Geld mit Zusatzleistungen verdient wird, z.B Support, oder, im Falle von Canonical, mit zusätzlichen Diensten, bei dem man gegen Geld zusätzlichen Online-Speicher oder Musik erhält.

Bei den Blogbeiträgen ist es ähnlich: Jeder darf sie lesen, und oftmals stehen sie auch unter ein freien Lizenz wie Creative Commons, dass dem Nutzer das weiterverbreiten oder verändern der Inhalte erlaubt. Mit flattr, Paypal und anderen Spendendiensten besteht zusätzlich die Möglichkeit, dem Blogger für seine Arbeit zu danken und Geld zu verteilen. Die Einnahmen durch Spenden fallen nicht immer groß aus, wenn man Glück hat, reicht es, um die Serverkosten zu decken, aber von Geld verdienen im Stile eines kommerziellen Unternehmens kann keine Rede sein.

Anders wäre es, wenn Blogger ihre Beiträge hinter einer Paywall verstecken würden, d.h dass man sie nur gegen Geld lesen kann. Dies würde denn Open Source Gedanken widersprechen, weil die Arbeit nicht an die Community, sondern nur an einen Kreis von zahlenden Kunden weitergegeben wird. In diesem Falle muss man zahlen, im Falle von flattr kann man zahlen, wenn man will. Die Artikel an sich ist immer noch frei.

Ein anderer Punkt ist die Werbung. Hier könnte man wirklich eine Kollision mit der oben zitierten Regel sehen, denn flattr ist ein kommerzieller Dienst (behält schließlich 10% der Einnahmen), und ein flattr-Link ist indirekte Werbung für flattr – die Regeln verbieten jegliche Werbung. Wenn man diese Argumentationkette zuende denkt, müsste man viel mehr verbieten als nur flattr-Links. Wenn ein Blogger z.B seine Meinung über Ubuntu One schreibt, dann lesen viele Leute den Namen Ubuntu One, den Namen eines kommerziellen Dienstes, und der Name prägt sich unbewusst im Gedächtnis ein. Und wenn man irgendwann einen Cloud-Speicherdienst sucht wird man sich vielleicht an Ubuntu One erinnern und deswegen diesen Dienst nutzen – indirekt war das also Werbung. Blogger sind nunmal Multiplikatoren, weswegen viele Firmen auch Blogger auf ihre Angebote aufmerksam machen, weil sie genau wissen, dass ein Blog eine größere Reichweite haben kann als irgendeine Werbekampagne.

Man muss sich also überlegen, wo man die Grenze zieht. Würde man den Planet-Bloggern verbieten, den Namen von kommerziellen Projekten zu nennen, dann könnte man nur noch sehr eingeschränkt bloggen. Niemand könnte mehr bloggen, wie man seine Onboard-Grafik von Intel unter Ubuntu zum laufen kriegt, ohne (Negativ-)Werbung für Intel zu machen. Und über Aktionen wie das Humble Indie Bundle darf auch niemand mehr schreiben.

Die Regel zum Verbot von Werbung ist richtig und wichtig, niemand möchte, das Forum oder Planet mit Werbung vollgespamt werden, denn das wäre eine ziemliche Zweckentfremdung. Der Zweck von ubuntuusers.de ist es, anderen Menschen zu helfen – und darum ist die Intention eines Forenpostes oder eines Blogartikels wichtig. Wenn ein Artikel dazu dient, andere Ubuntu-Nutzer bei ihren Problemen zu helfen und nütztliche Informationen weiterzuverbreiten, dann ist der Artikel gut, auch wenn darin der Markenname irgendeines Produkt vorkommt. Dient der Artikel aber dazu, Werbung für ein bestimmtes Produkt zu machen und damit Geld zu verdienen, wie etwa ein Trigami-Review, dann hat der Artikel nichts im Planeten verloren.

Viele von Freiwilligen erzeugte Inhalte im Wiki, im Forum und im Planeten haben mir und vielen weiteren Usern schon weitergeholfen. Ich halte es nicht für verkehrt, wenn die Schreiber eine einfache Möglichkeit bereitstellen, ihnen für diese Inhalte zu danken. Niemand möchte sich an der Community bereichern, sondern es soll sichergestellt werden, dass die großartige Arbeit von Freiwilligen auch in der Zukunft bestehen kann. Wenn im Gegenzug dafür am Ende des Beitrags ein Link steht, der den Namen eines kommerziellen Dienstes trägt, dann ist das akzeptabel.

Gerade habe ich eine Mail bekommen, in der ich zur Private Beta von Ubuntu Stackexchange eingeladen wurde, weil ich mich vor ein paar Wochen dort mal registriert habe. Aber vielleicht sollte ich erst erklären, was Ubuntu Stack Exchange eigentlich ist.

Vielleicht haben einige von euch bereits von StackOverflow.com gehört. StackOverflow.com ist eine Frage/Antwort-Plattform für Programmierer. Der Unterschied zu einem Forum besteht darin, dass die Fragen und die Antworten möglichst allgemein gehalten werden sollen, sodass sie leicht von anderen weiterverwendet werden. Ein Beispiel wäre (einfach mal so herausgegriffen): Is LinkedList thread-safe when I’m accessing it with offer and poll exclusively? (Java). Statt das in Foren ständig die gleichen Fragen gestellt werden, kann so eine Frage einmal beantwortet werden und derjenige, der die Antwort sucht, braucht nur noch nachzuschlagen.

Ähnlich ist es bei Ubuntu Stack Exchange. Stack Exchange ist eine Plattform, auf der jeder eine Seite ähnlich Stack Overflow erstellen kann, und nun hat das eben jemand für Ubuntu gemacht. Auch bei Ubuntu und Linux im Allgemeinen tauchen in Foren immer wieder dieselben Fragen auf, ob man denn auch auf Windows-Partitionen zugreifen kann, ob Spiele funktionieren, ob Linux wirklich kostenlos ist (ja, ich weiß, Freiheit, nicht Freibier), ob man unter GNOME auch KDE-Programme verwenden kann und so weiter. Oftmals wird auf eine FAQ verwiesen, woraus man sich die Antwort erschließen könne. Ubuntu Stack Exchange ist im Prinzip genau das: Eine ständig sich selbst erweiternde FAQ. Beispiele für Fragen wären etwa How can I install a package without root access? oder How do I move the window buttons back to the right for all users?

Fragen können verschlagwortet, bewertet und natürlich beantwortet werden. Aktive User bekommen auch sogenannte Badges, die man in seinem Nutzerprofil sammeln kann, je nach der Aktivität auf der Seite. Es gibt auch noch eine Meta-Seite, auf der über Ubuntu Stack Exchange selbst Fragen gestellt werden können.

Um bei Ubuntu Stack Exchange mitzumachen, braucht man nur eine OpenID. Wer ein WordPress.com-Blog betreibt, der kann einfach seine Blog-URL nehmen. Auch Launchpad-Accounts besitzen eine OpenID. Ansonsten kann man sich bei einem beliebigen OpenID-Provider eine erstellen. Momentan befindet sich Ubuntu Stack Exchange noch in einer geschlossenen Beta, die offene Beta wird am 4. August beginnen.

Insgesamt gibt es schon rund 100 Fragen zu Ubuntu. Die Zahl wird sich sicherlich erhöhen, wenn die Public Beta startet, denn zur Zeit sind neben mir nur 593 weitere User registriert.

Alles in allem halte ich Ubuntu Stack Exchange für eine sinnvolle Ergänzung zu den bisherigen Hilfe-Ressourcen, wenn man auch langsam den Überblick verlieren kann. Vielleicht machen wir einfach eine Q&A-Seite, auf der erklärt wird, wofür die einzelnen Hilfeservices gut sind . Jedenfalls sollten wir mal abwarten, wie sich das ganze entwickelt.

Dies ist der zweite Teil der Serie Linux leicht gemacht. Der erste Teil ist bei JUICEDBlog verfügbar.

Die Paketverwaltung
Nachdem man Ubuntu installiert hat, will man bestimmt weitere Software installieren. Dies funktioniert unter Linux ein wenig anders. Unter Windows ist es üblich, ein Programm von einer Webseite herunterzuladen. Man erhält dann meist eine .exe-Datei, die ein Installationsprogramm enthält, welches das eigentliche Programm dann an die richtigen Stellen im System verteilt.

Unter Linux geht so etwas auch, allerdings wird das selten gemacht. Für gewöhnlich startet man einfach ein Programm, das Paketverwaltung heißt, gibt den Programmnamen ein und klickt auf Installieren. Das Entfernen geht genauso, nur, dass man eben auf Entfernen klickt.

Dabei bezieht die Paketverwaltung die Software aus einer Paketquelle. Eine Paketquelle ist eine Softwaresammlung auf einem Server oder einer CD. Die Paketquelle stellt eine Liste von Programmen bereit, außerdem bietet sie diese Programme zum Download an. Die Paketverwaltung schaut also nach, ob ein Programm mit diesem Namen existiert, und lädt es von der Paketquelle automatisch herunter.

Unter Ubuntu ist normalerweise nur eine Standard-Paketquelle aktiviert, die von Canonical und der Ubuntu-Community betrieben wird. Dort findet sich alle mögliche Software, wie Firefox, Thunderbird, OpenOffice oder GIMP. Der Vorteil ist, dass man nicht erst nach einem Programm suchen muss, sondern es durch Eingabe des Namens direkt von einer vertrauenswürdigen, sicheren Quelle herunterladen kann. Kennt man den Namen nicht, so kann man in den Kategorien stöbern. Updates werden so auch erleichtert: Die Paketverwaltung informiert einen darüber, ob eine neue Version einer Software verfügbar ist und bietet ein Update an (System->Systemverwaltung->Aktualisierungsverwaltung). Das klappt für Betriebssystem und Programme. Das Konzept ist mit dem des App Stores des iPhones vergleichbar.

Möchte man Software installieren, die nicht in den offiziellen Quellen vorhanden ist, so kann man eine weitere Quelle einbinden. Allerdings sollte man das nur machen, wenn es absolut notwendig ist. Die Fremdquelle kann die Sicherheit und die Stabilität des Systems beeinträchtigen. Einige Quellen werden von normalen Nutzern betrieben, meist ohne böse Absicht. Es ist jedoch kein Problem, auch Schadsoftware darüber zu verteilen. Ist ersichtlich, dass die Paketquelle von vertrauenswürdigen Leuten betrieben wird, z.B von einer Firma wie Oracle im Beispiel unten, so ist das OK. Die Stabilität ist in Gefahr, wenn die Quelle Updates für Systemkomponenten enthält wie den Kernel oder den X-Server (die Software, die unter Linux für die Grafik zuständig ist. Ist sie kaputt -> kein Bild). Dann kann es sein, dass das System nicht mehr startet, weswegen man auf solche Basteleien lieber verzichten sollte. Ein nette Geschichte zu dem Thema ist in diesem Ikhaya-Artikel zu finden.

Möchte man nun so eine Quelle hinzufügen, so benötigt man die APT-Zeile, die es auf der Webseite der Quelle gibt. Beispiel für die Virtualisierungslösung VirtualBox:

deb http://download.virtualbox.org/virtualbox/debian lucid non-free

Das “lucid” am Ende gibt an, dass die Quelle für die aktuelle Ubuntu-Version, 10.4 Lucid Lynx gedacht ist. “non-free” gibt den Bereich an, in diesem Fall ist es der unfreie Bereich, da diese Quelle die unfreie Version von VirtualBox anbietet.

Zusätzlich sollte man auch den GnuPG-Schlüssel der Quelle hinzufügen. Dieser stellt die Identität der Quelle und dessen Software sicher. Wie man das macht, steht meist auf der Webseite der Paketquelle. Bei Paketquellen von der Entwickler-Plattform Launchpad wird der Schlüssel automatisch importiert.

Proprietäre Software: Multimedia-Codecs und Treiber

Viele Linux-Software ist freie Software, aber es gibt natürlich auch proprietäre Programme. Nicht jeder Entwickler ist gezwungen, sein Programm unter eine Open Source Lizenz zu stellen, nur weil er für Linux entwickelt. Manche Software ist unter Umständen von Patenten betroffen, so dass ihr Einsatz in einigen Ländern möglicherweise nicht ganz legal ist. Dies ist beispielsweise der MP3-Codec. Natürlich können auch MP3s unter Linux angehört werden. Da man für Linux normalerweise kein Geld zahlt, zahlt man logischerweise auch nicht irgendwelche Patentgebühren mit, wie das bei kostenpflichtiger Software der Fall sein kann.

Unter Ubuntu gibt es zwei Paketquellen, die proprietäre oder von Patenten belastete Software enthält. Das wäre einmal die Multiverse und einmal die Partner-Quelle. Unter System->Systemverwaltung->Software-Paketquellen muss man unter dem Tab Software von Ubuntu die Option Urheberrechtlich eingeschränkte Software (multiverse) aktivieren. Die Partner-Quelle befindet sich unter Andere Software. Nach einem Neueinlesen der Quellen kann mit der Installation begonnen werden.

Die Faulen können sich jetzt einfach das Meta-Paket

• ubuntu-restricted-extras

installieren. Dann werden die ganzen Codecs, Flash usw. auf einmal installiert. Wer jedoch genau festlegen will, was er braucht, der kann sich die Pakete auch einzelnen installieren:

• adobe-flashplugin oder flashplugin-installer: Der Flash-Player, wie man ihn von Windows her kennt.
• sun-java6-jre: Die offizielle Java-Runtime von Sun/Oracle.
• openjdk-jre: Auch eine Java-Runtime, allerdings Open Source. Funktioniert genauso wie obige, manche Applets und Programme machen aber Probleme.
• acroread: Der Adobe Reader. Ubuntu bringt mit Evince bereits einen PDF-Reader mit, für komplexe PDFs kann man den Adobe-Reader verwenden.
• gstreamer0.10-fluendo-plugins-mp3-partner: Codec, um sich MP3s anhören zu können. Legal, weil von Canonical lizenziert.
• skype: Die bekannte VoIP-Software.
• unrar: RAR-Dateien entpacken.

Falls man irgendeinen Codec vergessen hat, ist dies auch nicht weiter schlimm: Falls der Video-Player Totem eine Datei abspielen soll, für die er keinen Codec hat, so bietet er die Installation automatisch an.

Nun zu den Treibern. Die meisten Treiber sind Open Source. Diese sind oft Bestandteil des Kernels und werden bei Ubuntu mitgeliefert. Die Hardware läuft „out-of-the-box“, also gleich nach der Installation. Für manche Hardware, besonders Grafikkarten, müssen proprietäre Treiber installiert werden.

Benutzer von ATI-Karten haben drei Treiber zur Verfügung: radeon (frei), radeonhd (frei) und fglrx (unfrei). Für Nvidia-Benutzer gibt es ebenfalls drei Treiber: nv (frei), nouveau (frei) und nvidia (unfrei). Normalerweise wird ein freier Treiber vorinstalliert. Leider sind diese Treiber oft langsamer als die unfreien, hersteller-eigenen Treiber, oder man kann Funktionen wie 3D ohne den unfreien Treiber gar nicht nutzen.

Um auf einen unfreien Treiber umzustellen, gibt es unter Ubuntu ein extra Programm. Dies öffnet man mit System->Systemverwaltung>Hardware-Treiber. Dort wird dann angezeigt, welche proprietären Treiber für den Computer verfügbar sind, außerdem kann man sich die gleich installieren. Dabei wird die Paketverwaltung genutzt.

Was bedeutet /media oder /usr? – die Verzeichnisstruktur

Unter Windows ist man die Laufwerksbuchstaben gewohnt. Die Systempartition befindet sich unter C:\, das Diskettenlaufwerk unter A:\ und das CD-ROM-Laufwerk unter D:\. Auch externe Festplatten und USB-Sticks kriegen einen Buchstaben zugewiesen.

Unter Linux funktioniert das anders. Dort gibt es nur einen einzigen Verzeichnisbaum mit der Wurzel “/”. “/” ist die Systempartition. Weitere Partitionen können als Ordner in den Verzeichnisbaum eingehängt werden. Legt man eine CD ein, findet sich der Inhalt unter /media/cdrom0 wieder (manchmal wird cdrom0 auch durch den Namen der CD ersetzt). Es ist auch möglich, Datenträger von entfernten Rechnern (FTP z.B) als Ordner einzuhängen. All das mag einen Windows-User erst verwirren, so waren früher Ordner doch immer Bestandteil eines Laufwerks, und es fing auch nie irgendwo ein neues Laufwerk an.

Vorteil ist, dass man sich seine Partitionierung komplett selbst gestalten kann. Viele Leute legen ihre eigenen Daten auf einer extra Partition ab, damit sie nach einer Neuinstallation noch vorhanden sind. Unter Windows gibt es die “Eigenen Dateien”. Diese liegen für gewöhnlich irgendwo unter C:\. Erstellt man nun eine neue Partition, z.B unter E:\ für seine Dateien, dann speichern Programme die Dateien immer noch in den “Eigenen Dateien”.

Linux-User haben das Problem nicht. Der persönliche Ordner liegt unter /home/Benutzername. Möchte man sein Home-Verzeichnis nun auf einer anderen Partition haben, so erstellt man bei der Installation eine zusätzliche Partition und gibt als “Einhängepunkt” /home an. Dadurch landet alles, was in den Ordnen unter /home gespeichert wird, automatisch auf der neuen Partition. Es ist sogar möglich, dies nach der Installation zu machen. Das geht deshalb, weil sich aus Sicht der Programme nichts ändert. Sie greifen einfach auf /home zu und bekommen ihre Daten. Auf welcher Partition diese liegen, darum müssen sie sich nicht kümmern.

Ich habe mit /media und /home schon zwei Standard-Verzeichnisse aufgeführt. Es gibt aber noch weitere, diese sind mit dem File Hierarchy Standard für alle Distributionen definiert:

• /boot: enthält zum booten benötigte Dateien
• /bin und /sbin: enthalten Programme, die wichtige Aufgaben übernehmen, wie cp für das Kopieren einer Datei oder shutdown für das Herunterfahren
• /dev: enthält Gerätedateien, über die Geräte angesprochen werden können
• /etc: enthält Einstellungen und Konfigurationsdateien
• /lib: enthält essentielle Bibliotheken
• /lost+found: ist bei jeder Linux-Partition vorhanden, enthält Dateifragmente, die bei einer Überprüfung/Reparatur des Dateisystems gefunden wurden
• /mnt: temporär eingehängte Geräte
• /tmp: Temporäre Dateien
• /opt: optionale Software, die nicht mit der Paketverwaltung installiert wurde
• /proc und /sys enthalten Dateien, die laufende Prozesse repräsentieren und Schnittstellen zu Kernelfunktionen
• /root: Home-Verzeichnis für den Benutzer root, dem Superuser unter Linux
• /usr: enthält durch die Paketverwaltung installierte Programme und Bibliotheken
• /var: enthält Protokolle und Daten von Diensten

Der letzte Teil der Serie ist wieder bei JUICEDBlog zu lesen.

Die neue Version 2.4 bringt viele Verbesserungen mit sich und schließt einige Bugs (mal sehen, ob Stetic endlich mit Gettext zusammenarbeitet). Deshalb wollte ich auf die neue Version updaten, leider gibt es keine Pakete für Ubuntu, sondern nur für SLED/SLES, OpenSuse sowie Windows und OS X. Das wäre ja kein Problem gewesen, schließlich könnte man sich auch das Programm aus den Quellen bauen und installieren. MonoDevelop 2.4 benötigt aber Mono 2.6, in Ubuntu ist aber nur Mono 2.4 enthalten. Man müsste sich also alle Mono-Bibliotheken einzeln aus den Sources bauen, worauf ich nicht wirklich Lust hatte.

Glücklicherweise bin ich auf das Projekt badgerports gestoßen. Dieses Projekt hat sich zum Ziel gemacht, aktuelle Mono-Pakete für die jeweilige LTS-Version von Ubuntu zugänglich zu machen. badgerports wird vom Debian- und Ubuntu-Maintainer Jo Shields betrieben, hier findet man seine Launchpad-Seite.

Der Eintrag für die sources.list lautet:

deb http://badgerports.org lucid main #Badgerports

Nun muss noch der Schlüssel für die Quelle eingespielt werden:

$ wget http://badgerports.org/directhex.ppa.asc
$ sudo apt-key add directhex.ppa.asc
$ rm directhex.ppa.asc

Anschließend müssen die Paketquellen neu eingelesen werden:

$ sudo apt-get update

Danach muss man die Aktualisierungsverwaltung starten, welche uns gleich mit folgender Warnung begrüßt:

Das ist deshalb so, weil Mono eine grundlegende Bibliothek von Ubuntu ist und viele Ubuntu-Programme darauf aufbauen. Soweit ich weiß wird kein normales apt-get upgrade ausgeführt. sondern ein apt-get dist-upgrade, es werden also auch komplett neue Pakete installiert, sowie auch vorhandene entfernt. Darum sollte man sich genau überlegen, ob man wirklich Mono 2.6 installieren will. Beim Erscheinen und Update auf Ubuntu 10.10 sollte man auch im Hintergrund behalten, das man unoffizielle Pakete benutzt, und ggf. wieder auf die offiziellen Pakete downgraden.

Entschließt man sich zur Installation, werden die Pakete heruntergeladen und installiert.

Danach hat man MonoDevelop 2.4 und Mono 2.6 auf dem Rechner.

Ubuntu hingegen hat bisher einen Mittelweg praktiziert: Alle sechs Monate kommt eine neue Version raus, die zugehörigen Paketquellen werden eingefroren und wie bei Debian nur noch mit Bugfixes und Sicherheitsupdates versorgt, neuere Major-Releases der Programme gibt es erst in der nächsten Version. Bisher hat dies meiner Meinung nach recht gut funktioniert, wer tortzdem aktuellere Pakete wollte, der konnte Fremquellen benutzen.

Aber mittlerweile läuft da einiges schief. Beim aktuellen Release (das auch noch eine LTS ist) wurde etwa das Videoschnittprogramm PiTiVi integriert, dass sich immernoch in Entwicklung befindet und einige notwendige Features nicht beherrscht, teilweise noch viele Bugs hat. Hier gäbe es mit OpenShot eine ausgereiftere und stabilere Alternative. Dann wird KMS sowie Nouveau verwendet, ersteres führt bei mir zu einer langsamen Performace bei 3D, nach der Deaktivierung funzt die Performance wieder, dafür funktioniert GDM nicht mehr richtig (Blackscreen). Korrekterweise kommt Kernel 2.6.32 zum Einsatz, dafür werden Treiber und Features aus 2.6.33 zurückportiert. GIMP, ein erprobtes und zuverlässiges Programm, wird einfach entfernt (aus der Standardinstallation). Seit Lucid befindet sich auch Chromium in den Quellen, ein durchaus guter und vernünftiger Browser, leider im Beta-Status, die Version in den Paketquellen wird auch nicht geupdatet.

Jetzt lese ich hier bei OMG! Ubuntu!, dass F-Spot in 10.10 entfernt und stattdessen Shotwell eingesetzt werden soll. Über Shotwell habe ich schon einmal geschrieben, mir persönlich hat die Software gefallen. Allerdings ist die Software in einem noch frühen Stadium, so werden z.B keine PNGs unterstützt und es nicht möglich, Tags in die Metadaten zu schreiben, wodurch ein Wechsel zu einem anderen Programm mehr als schwierig wird. Gegen F-Spot spricht eigentlich nur die langsame Performance, was aber in Lucid bei mir besser geworden ist – könnte eine Nebenwirkung des Grafikkarten-Problems sein.

Ich bin der Meinung, dass man diese Strategie überdenken sollte: Ein Rolling-Release-Zyklus wäre wohl nicht so ideal, da Ubuntu ja halbwegs stabil und für den Endanwender geeignet sein will, und eine Debian-ähnliche Strategie würde die Distribution nicht interessant genug machen. Grundsätzlich finde ich die 6-Monate-Strategie gut, aber dann sollte man auch wirklich stabile Versionen in die Paketquellen legen und innerhalb der Support-Zeitraums aktualisieren, Aber Beta-Versionen in eine LTS zu integrieren und dann 3 Jahre lang diese Beta zu benutzen, ist quatsch. Die Entwickler des Programms werden wohl kaum diese Beta mit Sicherheitsupdates versorgen, wenn es schon eine neue Beta, RC oder vielleicht schon eine Final gibt.

Warum nicht die Backports besser ausnutzen? In die normalen Quellen kommt die jeweils aktuelle finale Version, während in den Backports die neuesten Versionen von beliebten Programmen bereitgehalten werden (so wollen viele Nutzer eine neue Firefox-Version benutzen, aber nicht aufs nächste Release warten). So könnte der Nutzer das Stabilitäts-Aktualitäts-Mischungsverhältnis ein wenig selbst justieren.

…oder einfach über die Kommandozeile installieren:

$ sudo apt-get install transmageddon

Anschließend kann das Programm über Anwendungen->Unterhaltungsmedien->Transmageddon Video-Umwandler gestartet werden.

Transmageddon verügt bereits über Voreinstellungen, man muss nur das Zielgerät auswählen, die Einstellungen werden automatisch gesetzt. Manuell gehts natürlich auch, hier hilft Transmageddon indem es nur Formate auswählbar macht, die auch zum gewählten Container passen. Wer will, kann das Video noch drehen oder spiegeln, ansonsten landen nach einem Klick auf Umwandeln die fertige Datei im selben Verzeichnis wie die Quelldatei.

Wer wie ich mit Problemen zu kämpfen hat, der sollte KMS vielleicht auch mal probeweise abschalten. Wenn ihr den radeon-Treiber benutzt, dann müsst ihr einfach die Datei /etc/modprobe.d/radeon-kms.conf bearbeiten.

$ gksudo gedit /etc/modprobe.d/radeon-kms.conf

Dort die Zeile

options radeon modeset=1

durch

options radeon modeset=0

ersetzen. Dann muss noch das Initial Ram Filesystem neu erstellt werden:

$ sudo update-initramfs -u

Jetzt einfach mal rebooten und dann am besten gleich ein 3D-Spiel, z.B einen Shooter, starten, um die Performance zu testen. Bei mir läuft nun alles auf Karmic-Niveau. Leider gibt es einen Haken bei der Sache: GDM startet mit einem Blackscreen, man muss den Bildschirm ein- und wieder ausschalten, um ein Bild zu kriegen. Weiterhin läuft nun Plymouth in niedriger Auflösung, was natürlich weniger schön aussieht. So hat man die Wahl zwischem schicken Bootscreen und schneller 3D-Grafik…

Edit: Der Trick mit dem Bildschirm funktioniert nur sporadisch, daher hab ich KMS wieder aktiviert. Dann halt kein 3D, lieber stabiles einloggen.