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>:<archetekturname>, also zum Beispie adobe-flash: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 kurzum 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:

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

# ./oibc

install

reboot

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 /usr/lib/eclipse installieren:

$ unp eclipse-platform-3.6.2-linux-gtk-x86_64.tar.gz
$ mkdir -p eclipse-platform/usr/lib
$ mv eclipse eclipse-platform/usr/lib/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 /usr/lib/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=/usr/lib/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

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

$ xinit gedit -- :1

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

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

options radeon modeset=1

options radeon modeset=0

$ 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.

Schaltet man die Funktion über GConf ein, so werden die Schatten unter Fenster und unter dem Panel angezeigt. Rebootet man nun (oder meldet sich neu an), so haben die Fenster weiterhin Schatten, das Panel jedoch nicht. Jemanden wie mich, der immer einen schönen Desktop braucht, stört sowas natürlich. Die einzige Möglichkeit, das zu fixen, wäre, das Compositing nach jedem Neustart aus- und wieder anzuschalten. Daher ein kleines Skript, quick&dirty:

#!/bin/sh
sleep 10
gconftool-2 -s --type bool /apps/metacity/general/compositing_manager false
gconftool-2 -s --type bool /apps/metacity/general/compositing_manager true

Nun muss man das Skript nur noch ausführbar machen, irgendwo hinschmeisen, wo es nicht stört, und mithilfe von System->Einstellungen->Startprogramme festlegen, dass es bei jedem Login starten soll.

Jetzt frage ich mich: Gibt es eine saubere Methode, als das Skript einfach 10 Sekunden schlafen zu lassen? Oder gibt es sogar einen „echten“ Fix für Metacity, der das Problem behebt?

Um den sbmanager zu nutzen müssen erstmal – falls nicht schon geschehen – die grundlegenden Bibliotheken wie etwa libimobiledevice installiert werden. Dafür gibts ein PPA:

$ sudo add-apt-repository ppa:pmcenery/ppa
$ sudo apt-get update
$ sudo apt-get dist-upgrade
$ sudo apt-get install gvfs gvfs-backends gvfs-bin gvfs-fuse libgvfscommon0 libgvfscommon-dev ifuse libimobiledevice0 libimobiledevice-utils libimobiledevice-dev
$ sudo adduser $USER fuse

Es folgt die Installation von sbmanager. Hierfür benötigen wir ein zweites Mal das Terminal:

$ sudo apt-get install build-essential git-core checkinstall
$ git clone git://git.sukimashita.com/sbmanager.git
$ cd sbmanager
$ sh autogen.sh
$ make
$ sudo checkinstall

$ sbmanager

Wenn man mit der Anordnung zufrieden ist, darf man nicht vergessen, mit dem grünen Haken die Änderungen zu speichern. Leider lassen sich nicht mehere Apps gleichzeitig markieren oder ganze Seiten verschieben. Modifikationen wie das Five Icon Dock machen keine Probleme.

Sicherlich sind einige wegen der größeren Freiheit zu Ubuntu gewechselt, die sie in ihrem vorherigen Betriebssystemen offenbar nicht fanden. Ich würde es mir heute auch zweimal überlegen, einen iPod touch zu kaufen. Schließlich schreibt mir Apple hier vor, welche Software ich zu installieren habe und kann selbige mit einer Kill-Switch-Funktion sogar remote löschen. Ich muss das Gerät unbedingt mit iTunes synchronsieren, das Upgraden der Firmware kostet Geld und das Downgraden ist jetzt auch nicht mehr so einfach. Und falls ich ein Programm für iPhone OS geschrieben hätte (wofür der Kauf eines Macs erforderlich gewesen wäre), so müsste ich Apple erst um Erlaubnis für die Veröffentlichung im App Store ersuchen.

Aber wenn man jetzt Apple und Canonical vergleicht, so fallen einem gewaltige Unterschiedene auf. Bei Canonical hat man – anders als bei Apple – die Wahl. Ubuntu ist Open Source. Ich kann es, so wie es ist, annehmen, inklusive der kommerziellen Bestandteile. Oder ich kann es verändern wie ich will, ich kann Ubuntu One, Ubuntu Software Center, Ubuntu One Music Store usw entfernen oder sogar Alternativprodukte entwickeln und anbieten, ohne dass ich irgendwas cracken muss oder dass ich verklagt werden kann. Und natürlich kann ich Ubuntu auf jeder Hardware benutzen. Ich kann mir sogar die Desktop-Oberfläche aussuchen und mehrere Programme gleichzeitig starten. Wow, ich habe sogar root-Rechte auf meinem eigenen System!

Dennoch kann man die Parallelen zu Apple nicht leugnen. Ansprechendes Design, schicke Hardware auf der Homepage, Cloud Computing, einen App Store, eine Musikverwaltung samt Musikstore. Einen Guru namens Mark Shuttleworth. Und man bekommt immer mehr das Gefühl, das Ubuntu als Komplettpaket gedacht ist, dass das Beste aus der Computer-Welt vereint und in perfekte Harmonie bringt. Ein Versprechen, welches auch Apple gibt. Wie wäre es also, wenn Ubuntu dieses Versprechen halten würde? Dann hätten wir, sagen wir mal, Apple in gut. Ich hätte mein Komplettpaket, wie bei Apple, nur das ich noch meine Freiheit dazu hätte. Wenn mir eine Komponente nicht gefällt dann kann ich sie austauschen.

Allerdings muss Canonical auch eine eigene Identität aufbauen. Wer in die Fußstapfen von anderen tritt, hinterlässt keine Spuren. Es gibt dutzende andere Linux-Distributionen und einen Haufen von Firmen, die versucht haben Apple zu kopieren. Und Firmen, die sowohl freie als auch proprietäre Software anboten gab es auch schon oft. Hier liegt es an Canonical, etwas innovatives, einzigartiges zu entwickeln. Das das nicht von heut auf morgen geht, ist klar. Und das Design muss auch noch entwickelt werden. Geben wir Canonical etwas Zeit und lassen die erst mal machen. Solange die Freiheit des User nicht durch irgendwelche Beschränkungen beschnitten wird und die kommerziellen Dienste optional sind, sehe ich sie auch nicht als Bedrohung an, sondern eher als willkommenes Angebot.

Wie ihr sehen könnt, kann man derzeit hier nur seine Account-Details bearbeiten. Der automatische Login in andere Dienste wie Launchpad funktioniert derzeit noch nicht. Später soll Ubuntu Single Sign On auch als OpenID-Provider dienen, sodass man sich auf Seiten, die als OpenID Consumer agieren, einloggen kann. Mit Launchpad geht das derzeit schon.

Meiner Meinung nach könnte man GIMP schon verbannen – allerdings sollte man kein Vakuum zurücklassen. Bildbearbeitung braucht nun jeder einmal und da wäre es praktisch zumindest ein rudimentäres Bildbearbeitungsprogramm zu haben, wovon es aber unter Linux wenig Auswahl gibt. F-Spot ist eher eine Fotoverwaltung statt eine -bearbeitung und Kolorpaint ist ein KDE-Programm. Am besten wäre sowas wie Paint.NET – leicht zu bedienen und trotzdem leistungsstark.

Wie der Name schon sagt ist Paint.NET in .NET implementiert und sollte deshalb eigentlich unter Mono laufen, nur tut es das mehr schlecht als recht. Besonders die Oberfläche ist kaum zu benutzen, die Schriften teilweise unleserlich. Genau diesem Problem haben sich die Entwickler des Open-Source-Projektes „Pinta“ nun angenommen, sie wollen die Winforms-Oberfläche nach GTK# portieren. Damit sieht das Programm wie eine echte GNOME-Applikation aus.

Momentan gibt es die Standard-Werkzeuge wie Pinsel, Stift, Radiergummi und Pipette, sowie verschiedene Auswahlwerkzeuge. Effekte gibt es nur wenige, nämlich S/W, Sepia, Autolevel und Farbumkehrung. Die Entwicklung ist noch in einem frühen Stadium, die Versionsnummer ist noch bei 0.1.

Pinta steht unter der MIT-Lizenz und läuft unter Ubuntu, openSUSE und weiteren Linux-Distributionen, als auch unter Mac OS X und unter Windows. Benötigt wird Mono, GTK# und Cairo. Ein fertiges .deb-Paket kann auf der Homepage des Projekts heruntergeladen werden. Allerdings ist dieses kein „richtiges“ Debian-Paket, sondern eigentlich ein RPM-Paket, das lediglich mit alien transformiert wurde – Vorsicht ist also angesagt.

Was meint ihr? Wäre Pinta ein würdiger Nachfolger für GIMP, wenn es denn noch ein wenig weiterentwickelt wird? Sollte lieber ein anderes Programm den Job machen? Oder sollte man lieber gleich GIMP behalten?

[via golem.de]