Category: Ideen mit Linux

Gedanken, Ideen und Lösungen zu Linux

Posted on

Wenn Zwei zusammenkommen: Arch Linux und Debian

Eine Entscheidung zu treffen war. Tue ich es oder tue ich es nicht? Sollte ich den Inspiron 4000 verschrotten oder Arch Linux parallel zu Debian Sid installieren? Ok, es gab schon dramatischere Situationen, aber bevor ich Arch Linux installiere....Spaß, Spaß.
Der Dell-Laptop ist mittlerweile zehn Jahre in Gebrauch, dreieinhalb davon hat er bei mir verbracht und er hat sich gut gehalten. Nun ja zumindest bis vor kurzem. Nach dem Scharnierbruch ist er nicht mehr der Mobilste. Wäre ich ein geschickter Handwerker, dann würde die Sache schon längst repariert sein und ich käme nicht auf die Idee mich erneut an einem Multi-Boot-System zu versuchen. Nicht dass es besonders schwierig wäre, wie alles hat es seine Vor- und Nachteile.
Da der Laptop ansonsten immer noch einwandfrei funktioniert und nach wie vor der meistgenutzte Rechner ist, macht es Sinn einen kleinen Versuch zu starten. Debian Sid und Arch Linux im direkten Vergleich. Fairerweise muss ich hinzufügen, dass es mir nicht um das "bessere" Linux geht, sondern einfach nur darum herauszufinden, welche Unterschiede es zwischen beiden gibt.

Was man bei der Installation von Arch Linux auf dem Dell Inspiron 4000 beachten sollte

Keine Sorge, ich werde nun niemanden mit der Installation von Arch Linux langweilen. Eine der großen Stärken von Arch Linux ist die ausgezeichnete Dokumentation. In der Regel benutze ich das englische Arch Linux Wiki, weil es umfangreichere Informationen enthält. Für die Installation ist das deutschsprachige Wiki aber nicht schlechter.
Arch Linux verlangt von seinen Benutzern absichtlich mehr Aufmerksamkeit. Entscheidungen von Grund auf zu treffen, ist bei Arch die Regel. Für den Inspiron 4000 musste ich dennoch nur bei den schon bekannten Problemen aufpassen. Die xorg.conf muss separat für dieses Modell erstellt und angepasst werden. Für Arch Linux lautet der Xorg-Treiber xf86-video-ati. Da noch keine Linuxdistribution den X-Server perfekt eingerichtet hat, hatte ich schon etwas Erfahrung. Eine einfache Kopie meiner xorg.conf von Debian nach Arch Linux reichte vollkommen aus.
Zu Testzwecken probierte ich die Linksys-WLAN-Karte mit Broadcom-Chipsatz zum Laufen zu bringen. Wie gehabt wird sie mit dem freien Kernelmodul b43 aktiviert, lediglich die Firmware der Karte ist unfrei und muss separat installiert werden. Im Gegensatz zu Debian muss die Firmware aus AUR installiert werden. Konkret bedeutet das, dass ein Tarball mit einem sogenannten PKGBUILD manuell heruntergeladen und entpackt wird. Diese Datei enthält lediglich Informationen, von wo man die ursprünglichen Quelldateien bezieht und notwendige formale Einträge über die Zielarchitektur, den Uploader usw.
Man sollte sich diese Textdatei auf jeden Fall genauer anschauen, da sie auch für ein System schadhafte Informationen enthalten kann. PKGBUILDS lassen sich aber bewerten, es gibt Feedback dazu auf der offiziellen Webseite, so dass in der Regel diese Methode durch eine Vielzahl von anderen Nutzern getestet worden ist.
Hat man das PKGBUILD entpackt und das Paket fakeroot installiert, genügt lediglich ein makepkg -s, um ein Arch Linux Paket zu bauen. Dieses wird dann lokal mit Hilfe von Pacman installiert. pacman -U Paketname.
Nachdem ich sowohl Xorg als auch Openbox installiert hatte, musste ich lediglich noch meine Konfigurationsdateien von Debian nach Arch Linux kopieren. Hier gab es erwartungsgemäß keine Probleme, da ich viele Ideen aus dem Arch Linux Wiki schon umgesetzt hatte und sowohl Debian als auch Arch hier keine Unterschiede gemacht hatten.
An dieser Stelle könnte ich nun einen Screenshot präsentieren, aber das System sieht exakt so aus wie es die Screenshots z.B. hier oder hier zeigen.
Mein Fazit ist: Arch Linux verlangt von seinen Benutzern mehr Aufmerksamkeit als Debian, das einige triviale Optionen einfach als gegeben voraussetzt. Das macht es einfacher, ein System von Grund auf an die eigenen Bedürfnisse anzupassen. Arch Linux hingegen will ausdrücklich, dass sich der Nutzer mit jeder Systemeinstellung auseinandersetzt und versteht wie das Ganze funktioniert. Zeigt man aber Eigeninitiative und folgt den Anweisungen im Arch Wiki, lässt einem Arch Linux nicht im Stich. Es gibt bei Freien Betriebssystemen kaum eine bessere Dokumentation.
Positiv fiel mir wieder einmal die Geschwindigkeit und das simple Konzept von Pacman, dem Paketmanager von Arch Linux, auf. Mittlerweile hat man auch die Sicherheitsprobleme angepackt. Danke auch an Daniel für den Hinweis!
In Zukunft werde ich versuchen Unterschiede von Debian Sid und Arch Linux zu dokumentieren und einfach etwas mehr über diese Distribution zu schreiben ohne Debian Sid in irgendeiner Weise zu vernachlässigen.

Posted on

Openbox 3.5 und ein paar Änderungen

Seit Anfang Oktober ist Openbox 3.5 in Debian Unstable und heute gab es eine weitere Aktualisierung. Da Openbox sowohl auf dem Inspiron 4000 als auch auf dem maximalen Spielesystem mit Debian Sid läuft, versuche ich bei der weiteren Entwicklung am Ball zu bleiben. Eine Sache, an die man vielleicht nicht zu oft denkt, ist aptitude changelog öfter zu benutzen. Regelmäßig gibt es hier doch einige interessante Kommentare und Informationen.
Wenn man zur Zeit wie ich Debian Unstable und Openbox benutzt, sollte man auf jeden Fall seine Konfigurationsdateien im Blick behalten. Seit Version 3.5 haben sich einige Syntaxregeln in der rc.xml geändert. Neu hinzugekommen ist sogar eine Datei namens environment, in der globale Einstellungen wie die Sprache speziell für Openbox geändert werden können. Im Moment sehe ich aber keinen großen Bedarf dort irgendetwas hineinzuschreiben.
Die veränderten Regeln in der rc.xml scheinen keine Auswirkungen auf die bestehenden Einträge zu haben. Sollte sich hier aber etwas merkwürdig verhalten, liegt es mit Sicherheit an dem neuen Update. Des Weiteren heißt es nun nicht mehr autostart.sh sondern nur noch autostart. Hier scheint aber das neue Openbox 3.5 noch ein Stück tolerant zu sein.
Doch was sehen meine entzückten Augen da: Das Openbox-Menü kann nun auch Icons darstellen. Endlich. 🙂

Posted on

Apt-Cacher-NG: Ein Proxy-Server für Debian und Ubuntu

Es gibt Programme, die einem erst in den Sinn kommen, wenn man viele Linuxdistributionen gleichzeitig auf seinen Heimrechnern benutzt und das Hardwarearsenal von Jahr zu Jahr anwächst. Im Regelfall hat jedes Linux einen Paketmanager, der dafür sorgt, dass Softwarepakete zentral verwaltet werden und die Aktualisierung derselben oft nur ein kurzes Kommando oder Mausklick entfernt ist.
Wenn man wie ich zweimal Debian Squeeze, zweimal Debian Sid und einmal Debian Testing einsetzt, braucht man irgendwann einen zwischenspeichernden Proxy-Server wie Apt-Cacher-NG. Diese Anwendung sorgt dafür, dass ein zentraler Server im Netzwerk die Rolle des Proxys spielt und alle anderen Clients bei einem Update über ihn mit neuer Software versorgt werden. Das Praktische daran:

  1. Es wird deutlich Bandbreite gespart, da nun nicht mehr jeder einzelne Rechner separat die Pakete herunterladen muss, sondern diese ab sofort nur einmal vom Proxy aus dem Internet geladen werden müssen. Der Debian FTP Master wird es einem danken. 😉
  2. Die Verteilung der Updates erfolgt dann innerhalb des lokalen Netzwerks über den zentralen Proxy-Server, womit alle Clients von der maximalen Geschwindigkeit des LANs profitieren.

Für die spezielle Aufgabe nur Debianpakete zwischenzuspeichern, gibt es mehrere Alternativen, von denen mir Apt-Cacher-NG am besten gefallen hat. Die Konfiguration ist einfach und funktioniert wie folgt:

  1. aptitude install apt-cacher-ng
  2. /etc/apt-cacher-ng/acng.conf an die eigenen Vorstellungen anpassen. Im Regelfall können die Einstellugen für Debian oder Ubuntu beibehalten werden.Optional: Das Cache-Verzeichnis z.B. auf /mnt/backup/apt-cacher-ng ändern und eine externe Festplatte oder USB-Stick in diesem Verzeichnis mounten. Das Standardverzeichnis liegt auf /var/cache/apt-cacher-ng. Das neue Verzeichnis muss unbedingt Schreibrechte erhalten und dem Benutzer apt-cacher-ng gehören.

    3. chown -R apt-cacher-ng:apt-cacher-ng /mnt/backup/apt-cacher-ng
    chmod -R a+rX,g+rw,u+rw /mnt/backup/apt-cacher-ng

  3. Apt-Cacher-NG neustarten: /etc/init.d/apt-cacher-ng restart
  4. Clients konfigurieren:
    Möglichkeit 1: Apt in /etc/apt/apt.conf mitteilen, dass wir neue Pakete nur noch über den Proxy Server beziehen wollen.

    Acquire::http { Proxy "http://server:3142"; };

    5. Möglichkeit 2: Die /etc/apt/sources.list anpassen:

    deb http://ftp.de.debian.org/debian/ sid main contrib non-free

    wird zu

    deb http://server:3142/ftp.de.debian.org/debian/ sid main contrib non-free

    Alle weiteren Zeilen müssen bei Methode 2 dementsprechend in der sources.list angepasst werden.

Den Namen server kann man beliebig wählen, sofern man die lokale IP-Adresse in /etc/hosts diesem Namen zugewiesen hat. Anstatt server lässt sich natürlich auch die lokale IP wie z.B. 192.168.0.201 eintragen. Es spart einem aber Tipparbeit es einmal in /etc/hosts festzuhalten. Für andere Anwendung wie SSH ist das auch ziemlich praktisch: ssh server anstelle von ssh 192.168.0.201
Für die anderen Clients verfährt man entsprechend. Anschließend werden dann bei einem Update die Pakete über den Server heruntergeladen, der sie zur weiteren Verwendung zwischenspeichert. Apt-Cacher-NG erkennt dabei automatisch, welche Pakete veraltet sind und welche nicht und kommt auch mit den unterschiedlichen Versionen von Debian oder Ubuntu klar. Ein netter Bonus von apt-cacher-ng ist das Webfrontend, welches sich unter http://server:3142 erreichen lässt.
Der Proxy bleibt aber nicht nur auf debianbasierende Distributionen beschränkt, sondern lässt sich auch mit Arch Linux benutzen. Bei anderen Distributionen sollte man das Handbuch konsultieren. Eine gute Zusammenfassung zu apt-cacher-ng gibt es auch bei ubuntuusers.de.
Alternativen sind oder waren apt-proxy (wird nicht mehr gepflegt), approx und apt-cacher. Mir gefällt apt-cacher-ng am besten, weil es unkompliziert einzurichten ist und selbst auf dem Inspiron 4000 Laptop ohne Probleme läuft.

Posted on

Jamendo, Youtube, Arte: Musik und Unterhaltung mit Totem

Ich dachte bis heute alles über Totem, den Medienabspieler von Gnome, zu wissen. Zwei seiner Plugins aus dem Paket totem-plugins benutze ich häufiger. Sowohl das Youtube- als auch das Jamendo- Plugin eignen sich ausgezeichnet zum Anschauen von Videos oder zum Musik hören.
Manchmal benutze ich auf dem Core Duo auch Minitube, um gezielt Youtube-Videos aufrufen zu können, ohne dass ich dafür extra einen Browser bemühen müsste. Außer es handelt sich natürlich um den Elinks, Mplayer und Youtube-dl Trick. (Ich mag diese Lösung wirklich. 🙂 )
Da das Paket totem-plugins standardmäßig installiert war, fiel mir erst vor kurzem auf, dass es da noch ein weiteres Extrapaket bei Debian namens totem-plugin-arte gibt, mit welchem sich Sendungen des Deutsch-Französischen Senders Arte TV streamen lassen. Normalerweise sehe ich mir Arte mit Mediathekview an.

Ich will mich an dieser Stelle nun nicht über das Für-und-Wider von GEZ-Gebühren und die öffentlich-rechtlichen Sender in Deutschland ereifern. Nur soviel sei gesagt: Ich könnte gut und gerne auf die meisten dort gezeigten Sendungen verzichten. Trotzdem muss ich mich hier als Arte Fan outen. Weniger weil ich ein Kulturfuzzi oder regelmäßiger Zuschauer wäre, sondern einfach nur, weil mir die Programmmischung und das zweisprachige Modell gefallen. Außerdem gab und gibt es dort immer wieder ziemlich coole Themenabende, ich erinnere mich da z.B. an Monty Python, Italowestern oder Anime.
Mit dem Plugin lassen sich spielend leicht auch hochauflösende Streams in Totem anschauen, zumindest solange sie nicht depubliziert werden.

Das Eingangs erwähnte Jamendo-Plugin rockt ebenfalls im wahrsten Sinne des Wortes. Damit lässt sich gezielt nach Künstlern suchen oder Schlagworte eingeben, um dazu passende Musikstile zu finden. Ebenfalls nett ist der Reiter mit den bekanntesten und meistabgerufenen Künstleralben. Etwas schade ist nur der teils zögerliche Verbindungsaufbau zu Jamendo. Die vorgestellten Linuxanwendungen sind zwar nur ein Teilausschnitt aus den Möglichkeiten, die sich mit Freier Software bieten, für den ein oder anderen (Film)Abend aber sicher ein guter Einstieg. 🙂

Posted on

Nvidia, Xorg 1.11.1 und etwas Licht am Horizont

Es gibt mal wieder etwas Positives von der Bugfront zu berichten. Ich hatte vor kurzem erwähnt, dass nach dem Update auf Xorg 1.11.1 plötzlich Iceweasel und andere Anwendungen heftig in meinem Debian-Testing-System laggten und die CPU-Last stark angestiegen ist.
Bei einem so offensichtlichen Problem kann man sich praktisch immer sicher sein, dass noch viel mehr Leute davon betroffen sind. Ich hatte damals keine Lust tiefer in die Problemlösung einzusteigen, da ein Wechsel zum freien Nouveau-Treiber das Problem für mich gelöst hatte und ich volle 3D-Unterstützung auf diesem System sowieso nicht benötige. Lediglich das laute Lüftergeräusch wegen des mangelhaften Powermanagements des Nouveau-Treibers blieb ein Makel.
Brandaktuell erfuhr ich dann vor einer Stunde beim Überfliegen der Debian-Devel-Mailingliste indirekt von der Lösung des Problems. Debian Bug #642757 beschäftigt sich nämlich mit dem gleichen Übel. Bisher sind schon 13 weitere Fehlerberichte damit zusammengeführt worden.
In Kürze, Xorg ist nicht schuld, sondern der proprietäre Nvidia-Treiber. Moment mal, werden sicher einige sagen. Nvidia funktionierte doch einwandfrei bis zum Update auf X 1.11.1. Das stimmt auch, aber solange der freie Nouveau-Treiber mit dem veränderten Xorg funktioniert, hat der Nvidia-Treiber vorerst die Torte im Gesicht.
Im Nvidia-Forum gibt es hierzu auch einen Thread mit einem offiziellen Beitrag eines Nvidia-Mitarbeiters, der das Problem technisch so erklärt:

I tracked this down to this commit to the X server:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=788ccb9a8bcf6a4fb4054c507111eec3338fb969
It removed our ability to accelerate part of the trapezoid rendering process and forces the whole thing (even the part we can accelerate) to fall back to software on GPUs that do not support full trapezoid acceleration. I've started a discussion on the xorg-devel@lists.x.org mailing list to see how the X community wants to solve this problem:
http://lists.x.org/archives/xorg-devel/2011-October/026050.html

Trapezoid Rendering Process wird mich nun sicherlich noch nächtelang im Schlaf verfolgen...
Im gleichen Thread gibt es auf Seite 2 einen inoffiziellen Patch, der scheinbar für einige dort funktioniert hat. Ich bin bei so etwas immer etwas vorsichtig und ehrlich gesagt kann ich auch noch eine Weile auf den offiziellen Fix warten. Doch für alle, die wirklich dringend eine Lösung suchen, weil sie morgen in der ESL wieder ihren Unterhalt verdienen müssen oder der nächste Raid vor der Tür steht, ist der Fix vielleicht ein Hoffnungsschimmer.
Für mich interessant ist aber die Diskussion, die das Ganze (vermutlich) anstoßen wird. Um solche gravierenden Bugs nämlich vor dem Update zu erkennen, gibt es ein Debian-Programm namens apt-listbugs, welches vor der Installation ausdrücklich warnt, falls ein Paket ein ernstes Problem verursachen würde.
In diesem Fall befanden sich die Fehlerberichte jedoch alle im Nvidia-Paket und nicht in den Xorg-Paketen, weshalb apt-listbug keinen Alarm auslöste. Wie es damit weitergeht? Keine Ahnung. Debian entwickelt sich immer weiter und was scheinbar im ersten Moment einfach nur ärgerlich war, führt plötzlich zu einer Verbesserung des Projekts an einer ganz anderen Stelle.
Übrigens, auf dem gleichen Rechner habe ich das Problem mit Debian Unstable nicht, obwohl ich dort die gleichen Xorg- und Nvidia-Pakete verwende und das verwirrt mich im Moment wirklich am meisten. 😉
Update 07.11.2011: Seit wenigen Tagen gibt es in Debian Sid ein Update der Nvidia-Pakete, welches das Problem beseitigt.

Posted on

Schnell und leicht: Dillo 3 ist zurück

Es war einmal ein Browser, der war schnell und sehr leicht. Er basierte auf GTK1, startete augenblicklich und war in vielen Distributionen zu finden, die sich auf ältere Hardware spezialisiert hatten.
Der Nachfolger mit der Versionsnummer 2 stieg danach auf die FLTK2 Bibliothek um, welche aber einige Lizenzprobleme hatte, so dass der Browser in vielen bekannteren Linuxdistributionen nicht aufgenommen werden konnte.
Wir schreiben das Jahr 2011 und Dillo 3 hat das Licht der Welt erblickt. Mittlerweile sind die Entwickler wieder auf FLTK1.3 umgeschwenkt, obwohl die Lizenzprobleme für die FLTK2-Bibliothek gelöst sind. Wie auch immer, Debian hat sich entschieden Dillo 3 aufzunehmen, weswegen ich mir den Browser kurzerhand mit Apt installiert habe.
Bei den Systemanforderungen ist Dillo 3 nach wie vor äußerst anspruchslos. Er belegt ca. 2 MB auf der Festplatte und laut ps_mem.py Skript ca. 11 MB RAM auf meinem Inspiron 4000. Die Startzeit um diese Seite zu laden liegt bei ca. 2 Sekunden.
Dillo hat sich offensichtlich seit meinen Versuchen Dillo 2 vergangenes Jahr zu kompilieren weiterentwickelt und bietet nun bessere CSS-Unterstützung. Mein WordPress-Blog ist lesbar und alle wichtigen Navigationslinks sind auch dort wo sie sein sollen.

Natürlich hat Dillo 3 auch ein paar Schwächen. HTTPS-Seiten würde ich weiterhin mit ihm nicht besuchen, da er außer rudimentärsten Kommandos SSL/TLS-Verschlüsselung nicht unterstützt.
Die CSS-Fähigkeiten sind sichtbar besser geworden, aber an die Qualität eines modernen Webkit-, Gecko- oder Presto- Browsers kommt er nicht heran.
Für alle, die immer auf der Suche nach dem besten Kompromiss zwischen Leichtigkeit und Funktionalität sind, kommt Dillo als Webbrowser als eine Möglichkeit in Frage. Mittlerweile bieten aber Webkit-Browser wie Surf deutlich bessere Rendereigenschaften bei vergleichsweise geringen Hardwareanforderungen.
Für reine HTML-Seiten ist Dillo ideal, obwohl links2 mit der -g Option ähnliche Ergebnisse bietet. Für Textseiten ohne Javascript und alles andere gibt es ja auch noch elinks. Interessant für Webentwickler ist auch Dillos Buganzeige am unteren rechten Bildschirmrand.
Am Ende muss man einfach abwägen, was man tatsächlich zum Browsen braucht. Standardmäßig ist Dillo sehr sicherheitsbewusst eingestellt. Cookies werden immer abgelehnt. Normalerweise lässt sich dieses Verhalten in ~./dillo/cookiesrc wieder ändern.

DEFAULT DENY
fltk.org ACCEPT
.host.com ACCEPT_SESSION

Hiermit werden alle Cookies abgelehnt, bis auf fltk.org, welches immer akzeptiert wird und host.com, wofür Dillo aber nur für die Dauer der Sitzung Cookies entgegennimmt. Leider gelang es mir trotzdem bis jetzt nicht, mich in das WordPress-Backend oder Google-Mail einzuloggen. Bei letzterem könnte auch die Beschränkung auf "Standardbrowser" eine Rolle spielen.
Häufig gestellte Fragen beantwortet die Dillo FAQ.
Wie immer gilt, Dillo am besten selbst einmal ausprobieren.

Posted on

Gnome 3 ist nun in Debian Unstable

Gnome 3.0 ist da! Der 13. Oktober brachte nicht nur Ubuntu 11.10, sondern auch den Übergang der letzten und entscheidenden Pakete von Gnome 3 aus Debian Experimental nach Unstable. Was lange währt, wird endlich gut. Damit lag ich im letzten Beitrag zu diesem Thema mit der Vermutung nicht ganz falsch, dass Gnome 3.0 in Debian dann erscheinen wird, wenn offiziell 3.2 von den Gnome Entwicklern freigegeben wurde.
Hier sind vielleicht noch ein paar interessante Fakten zu Gnome 3 in Debian:

  • Tatsächlich fand der Übergang von Gnome 2 nach Gnome 3 bisher auf eine sanfte und unbemerkte Weise für alle Testing- oder Unstable-Nutzer statt. Von Zeit zu Zeit flossen Pakete von Gnome 3 schon ein und wurden parallel zu Gnome 2 installiert, ohne dass dies irgendeine gravierende Auswirkung gehabt hätte. Am ehesten fiel es noch bei Anwendungen wie "Eye of Gnome" auf, die plötzlich Versionsnummer 3 trugen und nicht mehr im alten GTK2-Gewand erschienen sind, da sie nun auf GTK3 basieren.
  • Seit dem 13. Oktober befinden sich nun die wirklich entscheidenden Pakete in Debian Unstable, Gnome Shell, Nautilus 3 und Gnome Panel und mit ihnen alles, was das neue Bedienungskonzept von Gnome 3 sichtbar werden lässt.
  • Der Status von Gnome 3.0 in Debian lässt sich weiterhin auf http://www.0d.be/debian/debian-gnome-3.0-status.html verfolgen. Fast alles grün mittlerweile. 🙂
  • Gnome 3.2 hat eine ähnliche Übersichtsseite bekommen. http://www.0d.be/debian/debian-gnome-3.2-status.html
  • Kompetente und aktuelle Informationen in Englisch zu Gnome 3 in Debian gibt es im IRC in #debian-gnome auf OFTC.
  • Gnome 3 Release Critical Bugs: http://deb.li/gnomercbugs
  • Gnome 3 Buildd Status. Wurde Gnome 3 Paket X erfolgreich für meine Architektur gebaut?: http://deb.li/pkggnome
  • Auf linuxundich.de wurde berichtet, dass die Erweiterung nautilus-open-terminal zu Abstürzen der Ubuntu Version von Nautilus führt. Im Debian-Bugtracker existiert seit August Fehlerbericht #637309 hierzu, der scheinbar in Zusammenhang mit dem Fehlerbericht #869131 auf Launchpad.net steht. Scheinbar lassen sich eine Reihe von Bugs auf den notwendigen Übergang von GTK2 auf GTK3 zurückführen. Zu den mehr als 100 Gnome 3 relevanten Paketen gesellen sich auch noch eine große Anzahl von Erweiterungen hinzu, die alle ebenso portiert werden müssen. Eine Übersicht über alle schwerwiegenden Bugs in Bezug auf den Übergang von Nautilus befindet sich hier.
    Mittlerweile stuft Debian diese Bugs alle als "Serious" und damit als veröffentlichungskritisch ein. Erste Warnungen an die Paketbetreuer gab es bereits im August. Diese müssen nun mit Hilfe von Upstream ihre Pakete wieder in einen stabilen Zustand bringen. Da Ubuntu direkt aus Debian Unstable Pakete entnimmt, ist die aktuelle Ubuntu Version Oneiric Ocelot direkt davon betroffen. Dieses kleine Beispiel zeigt nur, dass Gnome 3 ein sehr großes Projekt ist, welches von einer großen Anzahl von Einzelpersonen abhängt um perfekt zu funktionieren.
  • Ich habe in meinem Beitrag "Wie steht es um Gnome 3 in Debian?" geschrieben, dass Debian einen größeren Aufwand hat Gnome 3 für alle auf Debian unterstützten Architekturen zur Verfügung zu stellen und es damit oft etwas länger dauert. Das trifft im Allgemeinen sicher zu, doch hat Josselin Mouette am 02. Oktober 2011, einer der Gnome Paketverwalter, auf der debian-devel Mailingliste klargestellt, dass dies nicht das Kernproblem ist.
    Vielmehr finden große Veränderungen in Debian in Übergängen (Transitions) statt, aber erst wenn sichergestellt ist, dass dadurch nicht eine Reihe von bestehenden Paketen unbenutzbar wird. Er führt die lange Verzögerung in Debian vor allem auf das letzte Einfrieren der Pakete für die Veröffentlichung von Squeeze zurück. Dadurch entsteht sozusagen ein "Paketstau", der nur langsam abgebaut werden kann.

So viel zum aktuellen Stand von Gnome 3 in Debian. Mit etwas Glück könnte schon am 23. Oktober Gnome 3 in Testing ankommen. Selbst wenn es länger dauert, ich werde warten. 😉

Posted on

Thinkpad 600 und Lubuntu 11.10: Ein Nachtrag

Es war nicht ganz einfach Lubuntu 11.10 auf dem Thinkpad 600 zum Laufen zu bekommen. Wie zuvor schon erwähnt, musste ich mir einige Male die Haare raufen. Ich benutzte die alternative i386 Lubuntu-CD und hatte eigentlich keine großen Komplikationen erwartet. Leider stellte sich später heraus, dass eine normale alternative Installation zu keinem Erfolg führte. Entweder brach die Installation beim Installieren des Basissystems ab oder das System fror schon vorher mit einer Kernel Panic einfach ein.
Daraufhin überprüfte ich die CD mit Lubuntus eingebauter Testfunktion. Doch die CD war in Ordnung. Auch das Deaktivieren von ACPI oder APIC im F6-Menü brachte keinen Erfolg...bis ich die Experten-Installation wählte. Hiermit hat man eine noch viel feinkörnigere Kontrolle über den Installationsvorgang, der in diesem Modus scheinbar auch weniger RAM benötigt. Zur absoluten Sicherheit blieb ich auch bei Englisch als Systemsprache und sparte mir dadurch ebenfalls noch etwas Arbeitsspeicher.
Es dauerte danach mehr als zwei Stunden bis ich mit der Installation durch war und schließlich in Lubuntu 11.10 bootete. Wie zu erwarten war, sind 128 MB RAM und ein PII Prozessor die Untergrenze für diese Linuxdistribution. Das System funktioniert zwar, aber um wirklich flüssig damit arbeiten zu können, müsste man diverse Anpassungen vornehmen oder eine Schippe RAM drauflegen. Schon nach dem Login war der Arbeitsspeicher ausgereizt und Daten wurden auf die SWAP Partition ausgelagert.

Ich bleibe dabei, dass die anderen bisher auf dem Thinkpad 600 installierten Distributionen Debian, ConnochaetOS und Slitaz die bessere Alternative auf dem Modell sind.

Posted on

WineHQ kompromittiert – Eine Erinnerung

Mich hat heute die schlechte Nachricht per E-Mail erreicht, dass die AppDB- und Bugzilla-Datenbank von winehq.org gehackt worden ist. Da ich Wine in der Vergangenheit für World of Warcraft, Starcraft II oder Runes of Magic benutzt und Kommentare hinterlassen habe, besitze ich dort einen Account.
Die Meldung zum Einbruch in die WineHQ-Datenbank reiht sich dieses Jahr nahtlos in eine Serie von Angriffen auf bekannte Websites ein, namentlich Sony, Kernel.org oder DigiNotar. Es besteht aber kein Zusammenhang zwischen den Vorfällen. Alle Angriffe waren verschieden und nutzten unterschiedliche Sicherheitslücken aus.
Ich finde es gut, dass der Vorfall so schnell von den Verantwortlichen von WineHQ mitgeteilt worden ist, schlaflose Nächte bereitet er mir zum Glück nicht. Da ich keine Kontrolle über jeden Server und Internetdienst habe, probiere ich es mit diesen Vorsätzen.

  • Kein Passwort doppelt benutzen.
  • Passwörter benutzen, die schwer zu erraten sind.

Es macht mir deswegen nichts aus, dass mein gehashtes Passwort in die Hände von Fremden gefallen ist, da ich es nur auf WineHQ verwende. Ehrlich gesagt ist es so kompliziert, dass ich es mir selbst nicht merken kann. Da ich mich nur selten auf der Seite einloggen muss, genügt es mir das Passwort lokal auf meinem Rechner abzuspeichern und bei Bedarf wieder hervorzuholen.
Der beste Tipp für ein sicheres und einfach zu merkendes Passwort ist immer noch sich einen Satz auszudenken, den man sich leicht merken kann und daraus das Passwort abzuleiten.
"Im glühend heißen Sommer 2003 war ich am 8. 8 in München auf dem Viktualienmarkt um Peter zu besuchen und viel $ auszugeben."
Die Anfangsbuchstaben des Satzes sind genau wie Datumsangaben und Sonderzeichen, wie z.B. $ für Geld, Teil des Passworts.
IghS2003wia88iMadVuPzbuv$a
Das Beispiel ist natürlich ausgedacht. Aber auf genau diese Art und Weise erstelle ich meine Passwörter, die für mich Sinn ergeben, für andere aber extrem schwer zu erraten sind.
Hier ist noch einmal die Original-Mail von WineHQ.

We are sorry to report that recently our login database for the
WineHQ Application Database was compromised. We know that the entire
contents of the login database was stolen by hackers. The password
was encrypted, but with enough effort and depending on the quality
of your old password, it could be cracked.
We have closed the hole in our system that allowed read access to
our database tables.
To prevent further damage we have reset your password to what is shown
below. We strongly suggest that if you shared your AppDB password on
any other sites that you change that password as soon as possible.
For more detailed information about this hacking, please read about
it at this link:
http://www.winehq.org/pipermail/wine-users/2011-October/097753.html
Again, we apologize for any inconvenience this has caused.
-WineHQ Staff
http://appdb.winehq.org/

Posted on

Automatischer Paketbau mit dem Build Service von OpenSUSE

Wer keine Lust hat eine vollständige Entwicklungsumgebung aufzusetzen, aber dennoch gerne eigene Softwarepakete erstellen möchte, kann auf einen Dienst der Linuxdistribution OpenSUSE zurückgreifen. Mit diesem ist es möglich Pakete für verschiedene RPM-basierte Distributionen und auch für Debian oder Ubuntu zu erstellen.
Es genügt, wenn man sich auf https://build.opensuse.org mit Nick und E-Mail registriert. Anschließend hat man Zugriff auf ein eigenes Konto, mit welchem sich eigene Projekte realisieren lassen. Das webgestützte Interface hat mir auf Anhieb gut gefallen. Nachdem man sich für sein neues Paket einen Namen und eine Beschreibung ausgedacht hat, kommt man auch schon sofort zum wesentlichen Teil.
Auf der "Sources"-Seite müssen alle notwendigen Dateien zum Bauen eines eigenen Debianpakets hochgeladen werden. Im Grunde genommen sind das die wichtigen Steuerungs- und Kontrolldateien aus dem mit dh-make erstellten Debian-Ordner innerhalb des Quellpakets. Diese müssen, um vom Buildservice verarbeitet werden zu können, zuerst wie folgt umbenannt werden.

debian.changelog
debian.compat
debian.control
debian.rules
debian.install

Ebenfalls möglich ist es, Dateien direkt aus dem Internet herunterladen zu lassen oder ein Tar-Paket in ein anderes Format zu komprimieren. Sind diese Vorbereitungen getroffen, fehlt nur noch die DSC-Datei und das eigentliche Quellpaket im gepackten Tar-Format. Als Alternative lässt sich auch das komplette Paket-Version-debian.tar.gz mit Quellverzeichnis und der DSC-Datei laut der offiziellen Anleitung hochladen. Letztere Methode hat den Vorteil, dass man auf ein debianisiertes Quellpaket zurückgreifen kann und somit nur noch diese Dateien zum Buildservice hinzufügen muss, was ziemlich praktisch ist.

Wie der Screenshot zeigt, habe ich mich an dem kleinen Texteditor Nano wieder einmal probiert. Eine gute Wahl, wenn man sich in die Materie vortasten will. Nachdem die drei Dateien hochgeladen waren, begann die Virtuelle Maschine, eine XEN Lösung übrigens, automatisch mit der Erstellung der Build-Umgebung, Auflösen der Abhängigkeiten und dem anschließenden Kompilieren. Ich musste danach nur noch die fertigen Deb-Pakete herunterladen.
Praktisch an dem Build Service ist, dass man parallel für unterschiedliche Distributionen und Architekturen Pakete bauen kann. Außer Webzugang und einem Konto gibt es keine weiteren Voraussetzungen. Das gesamte Angebot eignet sich besonders für Entwickler, die ihre Software auf mehreren Plattformen testen wollen, ohne dabei privat mehrere verschiedene Entwicklungsumgebungen installieren zu wollen. Für mich als Nicht-Entwickler ist es dagegen einfach eine bequeme Möglichkeit zum Experimentieren und Dazulernen. Abgesehen davon, dass das zugrundeliegende Rahmenwerk für den Build Service Freie Software ist, zeigt es auch, dass sich verschiedene Linuxdistributionen mit ihrer Infrastruktur gegenseitig ergänzen können.
Von wegen immer: Mein Linux ist besser als deins. 😛