Getaggt mit ubuntuusers

Aktuellen Autobuild von Xonotic über die Paketverwaltung installieren

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

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

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

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

Das Paket installiert folgende Dateien:

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

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

$ sudo update-xonotic

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

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

Viel Spaß damit.

[Download]

Getaggt mit , , , ,

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

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

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

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

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

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

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

Auch der Paketmanager muss gleichzeitig Pakete mehrerer Architekturen verwalten können. Im Augenblick kann in der Datei /etc/dpkg/dpkg-cfg.d/multiarch eingestellt werden, welche Architekturen neben der Nativen berücksichtet werden sollen. Synaptic zeigt dann die fremden Pakete nach dem Schema <paketname>:<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 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.

Getaggt mit , ,

Android 2.3.3 auf dem iPod touch 1G installieren mit Ubuntu

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# ./oibc
uninstall
reboot

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

Getaggt mit , , , ,

Aktuelles Eclipse selber paketieren

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

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

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

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

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

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

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

…und ein Arbeitsverzeichnis angelegt werden:

$ mkdir eclipse-platform

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

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

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

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

Das Skript versehen wir mit folgenden Inhalt:

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

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

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

…und zwar mit diesem Inhalt:

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

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

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

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

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

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

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

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

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

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

Frohes Entwickeln!

Getaggt mit , ,

Warum Unity gut für den freien Desktop ist

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

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

Eine Revolution des Desktop ist nötig

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

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

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

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

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

Probleme von GNOME 3

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

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

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

Vorteile von Unity

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

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

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

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

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

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

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

Beide kochen nur mit Wasser

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

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

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

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

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

Abwarten und Tee trinken

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

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

Getaggt mit ,

Wenn das WLAN mal nicht läuft – das richtige Kernelmodul finden

Kürzlich erschien die zweite Betaversion von Ubuntu 11.04 “Natty Narwal”. Also USB-Stick gepackt, Image draufgespielt und ausprobiert. Es kam nur der Standard-Desktop, also kein Unity, weil kein 3D. Das war zu erwarten, denn der vorinstallierte freie Nvidia-Treiber kann für meine Karte kein 3D. Was mich aber verwunderte war, dass mein D-Link DWA 140 WLAN Stick (Ralink-Chipsatz) nicht ging, der Network Manager zeigte nur ein “firmware missing” an. Ich installierte den Natty-Kernel 2.6.38 vom Mainline-PPA unter Maverick und stellte fest, dass das Problem dort auch auftrat. Ein Kernel-Problem also. Ich googelte und stellte fest, dass ich nicht allein war. Da fiel mir ein Artikel aus dem Ubuntu-User-Magazin ein, indem verschiedene WLAN-Sticks auf Linux-Tauglichkeit geprüft wurden. Bei einem stand der Autor vor demselben Problem; es wurden falsche Kernelmodule geladen.

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.

Getaggt mit , , ,

Xonotic 0.1 Preview Release

Anfang dieses Jahres entschied der Gründer des Nexuiz-Projekts, Lee Vermeulen, den Namen Nexuiz an die Firma IllFonic zu lizensieren, die ein proprietäres PS3-Spiel mit dem Namen Nexuiz herausbringen will. Dies veranlasste die Community rund um Nexuiz, den freien First-Person-Shooter zu forken und unter dem Namen Xonotic weiter zu entwickeln. Jetzt steht zu Weihnachten eine erste Preview-Version, welche auf Linux, Windows und Mac OS X läuft. Vorher musste man sich den Quelltext aus dem Versionsverwaltungssystem herunterladen und selber kompilieren; dieser Schritt entfällt somit.

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.

Getaggt mit , ,

Tipp: Spiele in einem separaten X-Server starten

Spielen unter Linux ist ja bekanntlich kein Problem, sofern eine Linux-Version des Spieles vorliegt (oder die Windows-Version unter Wine läuft) und ein Treiber installiert ist, welcher die 3D-Fähigkeiten der Grafikkarte unterstützt.

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.

Getaggt mit , ,

Flattr und Open Source: Passt das zusammen?

In letzter Zeit erfolgte eine kontroverse Diskussion über den ubuntuusers-Planeten im Bezug auf die Frage, ob in jedem Beitrag Links zum Spendendienst flattr enthalten sein dürfen.

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.

Getaggt mit ,

Ubuntu Stack Exchange – Private Beta

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.

Getaggt mit
Follow

Bekomme jeden neuen Artikel in deinen Posteingang.