Upgrade auf Hardy

Meinen Blick durch ein paar wenige Distributionen musste ich noch erweitern: Leider haben sich die „paar Macken“, die ich unter Intrepid feststellen musste, als mit der Zeit außerordentlich nervend herausgestellt. Daher habe ich ein Downgrade auf Hardy Heron gewagt, was mit meiner ausgelagerten Home-Partition kein Problem war.

Die Bootzeit ist nun wieder auf Normal-Niveau. Wie in den Bootcharts zu sehen brauchte Intrepid bei mir unglaubliche 62 Sekunden zum Booten. Unter Hardy sind es dagegen ohne Optimierungen gute 30 Sekunden.

Hardy Boot

Intrepid Boot

Der Grund für dieses Verhalten ist ein Bug der mit Intrepid eingeschleppt wurde. Umgehen kann man diese Verzögerung nur, indem man entweder eine Taste gedrückt hält oder den Netzstecker herauszieht und wieder einsteckt. Damit könnte ich leben, da ich meine Mühle desöfteren in den Standby-Zustand schicke und sehr selten boote.

Aber genau da liegt ein weiteres Problem. Intrepid lässt meinen Laptop zwar einschlafen, nur aufwachen will es dann nicht mehr. Der Bildschirm bleibt einfach schwarz, auf Tastatureingaben reagiert es nicht. Abhilfe schafft dann nur noch ein Hard Reset. Bug habe ich vor 4 Wochen gemeldet und vorher in einem ähnlichen Report darüber berichtet, viel Resonanz gab es allerdings nicht.

Erfreulicherweise wird meine Hardware nun auch unter Hardy vollends unterstützt, LTS-Bit und Ubuntu-Devs sei dank. Die Installation verlief reibungslos, nur die nvidia-Treiber machen derzeit wohl Probleme und enden im Low-Graphics-Mode. Abhilfe schaffte bei mir die Installation der ia32-libs.

Somit verbleibe ich in der Gewissheit, Jaunty wird wieder rocken, erstmal bei Hardy und nehme die etwas ältere Versionsausstattung in Kauf, bei Bedarf kann man ja selbst Hand anlegen.

Hello Planet!

Heute wurde mir die Ehre zuteil,  meine Blogeinträge auf dem Planeten von ubuntuusers.de erscheinen zu lassen. Vielen Dank dafür an das ubuntuusers-Team!

Zu meiner Person: Ich bin 21 Jahre alt, wohnhaft im westlichen Eck von Unterfranken und studiere den Kooperativen Studiengang Informatik an der Hochschule Darmstadt. Nebenbei belästige ich mehrmals die Woche 10m entfernte Papierscheiben mit 4,5mm breiten Bleiprojektilen.

In meinem Blog werde ich hauptsächlich über meine Erfahrungen im Bereich Linux, im speziellen meist Ubuntu, berichten. Ab und an werden evtl. auch etwas allgemeinere IT-bezogene Themen dran kommen.

Is Ubuntu for you? – 64Bit-Addon

Auf Basis des Is „Ubuntu for you?“-Helferlein gibts von mir ein kleines 64Bit-Addon. Die 64-Bit User dürfen ein wenig lachen.

Is Ubuntu64 for you?

Hintergrundfarben stammen aus dem Originalbild. Das Ubuntu 64-Logo stammt aus dem Ubuntuusers.de-Wiki.

Kurz verglichen: imagemagick und pdftk

Beim Sortieren diverser Daten, ist mir ein Flyer in PDF-Form in die Hände gefallen, natürlich jede Seite in einer eigenen PDF-Datei.

Zum Zusammenführen der einzelnen PDFs fielen mir 2 Möglichkeiten ein:

1. Der erste Gedanke: imagemagick

Von früher war mir bekannt, dass imagemagick auch mit PDFs umgehen kann, also über apt installiert und die PDFs zusammengeführt: convert *.pdf Flyer.pdf

Eine einfachere Syntax findet man selten. Das Ergebnis war zwar brauchbar aber nicht zufriedenstellend. Wahrscheinlich hätte man die Qualität auch noch weiter tunen können, nur imagemagick konvertierte die PDFs in Bilder und machte daraus wieder PDFs, was mich daran gehindert hätte, die Texte per copy & paste wieder zu verwenden.

Das nehme ich imagemagick auch nicht übel, schließlich ist es ein Bild- und kein PDF-Bearbeitungsprogramm.

1. Der zweite Gedanke: pdftk

Ich überlegte also nach anderen Möglichkeiten. Im Hinterkopf hatte ich dann noch sehr schwach das Tool pdftk in Erinnerung, dass in seiner manpage genau diese Anwendung als Beispiel aufzeigt.

Also pdftk installiert und die Manpage durchforstet: pdftk *.pdf cat output Flyer.pdf

Die Syntax ist etwas gewöhnungsbedürftig, dafür das Ergebnis umso besser: Texte waren Texte und Bilder waren Bilder.

Insgesamt sind beide Tools in ihren Kernbereichen natürlich unschlagbar und ich gehe davon aus, dass ich das ohne Linux wohl erst nach Stunden der Suche geschafft hätte. Um es in den Worten einer bekannten Comic-Figur zu sagen: Windows 0, Linux 1.

Mein Shell-Befehl des Tages

Keinesfalls sollte man in einer bestehenden ssh-Verbindung folgenden Befehl ausführen:

sudo rmmod 3c59x

Zum Glück stand der betreffende Rechner nur 2m neben mir

GNUArm Toolchain unter Ubuntu 8.10

Update 25. März 09: Das Sommersemester 2009 hat begonnen. Da sicherlich einige Teilnehmer der Lesung Raffius hierüber stolpern werden, möchte ich darauf hinweisen, dass ich im Ubuntuusers Wiki eine aktuellere Anleitung als die unten stehende hinterlegt habe.

Es ist jedes Mal ein Grauß, sich ein Cross-Compiling Toolchain zu bauen, vor allem unter einem 64-Bit System, da es hier kaum vorkompilierte Pakete gibt. Die wenigen, die angeboten werden, stammen noch aus Opas Zeiten. Bleibt also nichts anderes übrig, als selbst Hand anzulegen.

1. Die Suche:

Jedesmal wenn ich mir das Toolchain bauen muss, schüre ich Google an, um nach evtl neuen Paketen in Ubuntu zu suchen. Pakete für Ubuntu gibt es keine, was mich allerdings verwundert, gibt es doch mittlerweile eine Mobile Edition von Ubuntu, die extra auf Mobile Geräte zugeschnitten ist. ARM Chips sind dafür bekannt, eine extreme Verbreitung im Bereich der Embedded Devices zu haben. Ein fertiges Cross-Compiling Toolchain wäre hier eigentlich zu erwarten. Google bringt mich dann immer zu ungelösten Beiträgen in englischen und deutschen Foren. Auch eine bekannte Seite eines KoSI-Kollegen wird hier angezeigt: alphapogo.de. Leider stimmen hier die Abhängigkeiten nicht mehr, die Pakete sind ebenfalls recht alt.

Um auf den Punkt zu kommen. Dieses Mal wurde mir ein Thread im Forum von mcuprogramming.com präsentiert, der ein Script enthielt, welches die enstprechenden Quellen automatisch downloaden, kompilieren und konfigurieren können sollte.

2. Vorbereitung:

Die Version 0.1 des Scriptes steht unter der GPLv3. Zum Download muss man sich im Forum registrieren.

Die neuesten Quellen, die zum Erfolg führen, kann man unter folgenden Links beziehen:

• http://gnuarm.org/binutils-2.19.tar.bz2
• http://gnuarm.org/gcc-4.3.2.tar.bz2
• http://gnuarm.org/newlib-1.16.0.tar.gz
• http://gnuarm.org/insight-6.8.tar.bz2

Nach dem Download speichert man die Quellen im Verzeichnis „gnu-arm-installer/src„, zuvor muss man natürlich das tar.gz Archiv des Scriptes entpacken.

Damit das Kompilieren nicht vorzeitig abbricht, sollte man unter Ubuntu Intrepid Ibex den configure Befehlen in der Datei gnu-arm-installer.sh noch die Option –disable-werror mitgeben, sodass aus zum Beispiel folgendem Code …

$SRCDIR/$BINUTILS_DIR/configure --target=arm-elf --prefix=$PREFIX \
--enable-interwork --enable-multilib --with-float=soft \
&& make all install

folgender wird:

$SRCDIR/$BINUTILS_DIR/configure --target=arm-elf --prefix=$PREFIX \
--enable-interwork --enable-multilib --with-float=soft --disable-werror \
&& make all install


eine Erklärung findet man in diesem Ikhaya-Artikel. UPDATE: Die Anpassung ist in der Version 0.2 des Skriptes nicht mehr nötig. Mein Vorschlag wurde netterweise aufgenommen /UPDATE

Jetzt fehlen noch die Abhängigkeiten:

sudo apt-get install build-essential libgmp3-dev libmpfr-dev texinfo libncurses5-dev

… sollten die wichtigsten sein. Danach bin ich mir nicht mehr ganz sicher aber Danach habe ich mir es einfach gemacht und mit …

sudo apt-get build-dep binutils insight

alles anfallende abgedeckt. Genaues werde ich nochmals in einer frischen Installation nachprüfen.

3. Kompilieren:

Dem Bauen sollte nun eigentlich nichts mehr im Wege stehen:

sh gnu-arm-installer.sh

Das Skript werkelt nun vor sich hin und sollte bei Erfolg ein fertiges Toolchain im Ordner install abspeichern. Die wichtigen ausführbaren Dateien findet man unter install/bin. UPDATE: Während des Kompilierens sollte man die Finger von der globalen PATH Variable lassen. Das Skript verändert diese temporär während der Ausführung. /UPDATE

Viel Spaß beim Assembler Programmieren

UPDATE: Bei Problemen mit dem Simulator bitte diesen Kommentar beachten. /UPDATE

!Ubuntu und wieder zurück

Nachdem ich die neueste Ubuntu-Version 8.10 „Intrepid Ibex“ seit der Beta-Phase getestet und einige Bugs reportet habe, auf die kein Ubuntu-Entwickler ein Auge geworfen zu haben scheint, war ich zunächst sehr entäuscht von der Richtung in die sich Ubuntu entwickelt: Überlange Pausen während dem Boot – unzählige Dienste, die gestartet werden, welche augenscheinlich keiner brauch.

Also habe ich mich mal wieder in der Welt der Distributionen umgesehen – Und bin bei Ubunu 8.10 „Intrepid Ibex“ gelandet. Echt klasse, was die aus der Distribution gemacht haben: Geräte werden automatisch erkannt, ggf. prop. Treiber angeboten – Video Codecs werden bei Bedarf nachinstalliert – Ordnerfreigaben funktioniern ohne großes Konfigurieren meinerseits.

Und hier ein kleine Übersicht der Distributionen, die ich getestet habe:

Arch: Ich hatte ArchLinux vor geraumer Zeit schon mal installiert. Die wenigen Pakete, die schlechte Hardware-Erkennung und erheblicher Konfigurationsaufwand trieben mich damals wieder zu Ubuntu. So tat ich es mir wieder an. Die nicht erreichbare englischsprachige Webpräsenz und die veraltete deutsche Doku, ließen Arch kaum bis zum XServer in VirtualBox kommen. Danach verließ mich das Interesse.

Sabayon: Als ehemaliger Gentooianer erregte Sabayon, ein Gentoo-Abkömmling, zunächst meine Aufmerksamkeit. Leider ist die Dokumentation sehr schlecht. Artikel sind zwar vorhanden, jedoch ohne klare Inhaltsübersicht. Als Paketmanagement wird natürlich Portage empfohlen, was allerdings bei Sabayon ohne zusätzliche Konfiguration unbrauchbar ist. Konflikte entstehen schon beim portage-Update, dass man zunächst machen sollte. Der eigentlich sinnvolle Paketmanager für die Binärpakete, auf die Sabayon ja setzt, namens equo wird nur peripher erwähnt.
Die Installation verläuft rasch, jedoch sollte man die DVD verwenden, wenn man Gnome oder andere Umgebungen verwenden will. Die minimal-ISO beinhaltet nur XFCE und evtl KDE. Wählt man die Gnome-Umgebung und entfernt alle Haken bei den zusätzlichen Paketgruppen, wie Video oder Bürosoftware, erhält man ein ziemlich chaotisches System: Einen KNetworkManager in Gnome braucht nun wirklich keiner. So fiel diese Distribution aus der Liste raus und ich installierte …

Fedora: Die erste Distribution, die ich länger laufen hatte. Leider fehlt auch hier eine gute Dokumentation, unterscheidet es sich doch teilweise sehr von den Debian-basierten Distributionen. Die freie Ausrichtung lässt das Abspielen von Mediendateien teilweise schwierig werden, denn das neue RPMFusion Repository funktionierte leider für amd64 noch nicht. Alte Decoder-Versionen verhalfen dann aber zum Erfolg. Der Knackpunkt war, dass die Ordnerfreigaben weder über die Samba-Konfiguration noch über Nautilus funktionieren wollten.

Ubuntu: Meine Ausflüge in das Distributions-Meer haben mir einiges klarer werden lassen: Ein Betriebssystem sollte mich nicht mit unnötigen Pakete zubomben, aber mir sie dennoch anbieten, wenn es merkt ich könnte sie gebrauchen (Stichwort: Video-Decoder, Netzwerkfreigaben, Treiber), d.h. ich erhalte nach der Installation ein einfaches System, das ich meinen Bedürfnissen anpassen kann, und das die täglichen Aufgaben zuverlässig erfüllt ohne großen Konfigurationsaufwand nach der Installation. Natürlich erwarte und will ich nicht, dass mir jede denkbare Funktion zur Verfügung steht. Sollte ich aber die Desktopeffekte aktivieren, und mir fehlt der entsprechende Treiber, darf mir das System ruhig diesen Treiber anbieten, fehlt mir ein Plugin zum Abspielen eines Videos, soll mir das System einen passenden Codec anbieten…usw.

Ubuntu ist meines Erachtens die einzigste Distribution, die am nähesten an diesem Ziel dran ist – auch wenn es einige Macken hat.

So hat sich Ubuntu wieder Mal als die für mich beste Distribution herausgestellt. Die nächste Distribution die ich nun zu testen habe, wird sich Jaunty Jackalope nennen – go get it!