Tuxhausen-Blog

Heute gibt es (nach langer Zeit) mal wieder einen Neuzugang in meiner Blogroll: Der Blog von Tuxhausen

Der Blog hat zwar nicht allzuviele Artikel, aber der Betreiber Markus Ungermann nutzt ihn auch eher als digitales Gedächtnis. Warum er es überhaupt auf meine Blogroll geschafft hat, liegt darin, daß er die Themen „Linux“, „Windows“ und „Mac“ vollkommen gleichrangig nebeneinander behandelt. Das ist einfach mal richtig wohltuend neben dem ganzen Fanboy-Gehabe, welches man sehr oft auf anderen Webseiten antrifft. Außerdem kann man dort einen wirklich gut geschriebenen Linux-Kurs herunterladen.

An seinem Schreibstil gefällt mir besonders, daß er nicht einfach irgendwelche Fakten aneinanderreiht, sondern daß die Texte wirklich logisch aufgebaut sind, und man damit tatsächlich etwas anfangen kann.

Gute Seite, ab in die Blogroll, fertig.

Bildkonvertierung für digitale Bilderrahmen

Hier mal ein kleines Shell-Script, um Digitalphotos optimal für die Wiedergabe auf Fernsehern oder digitalen Bilderrahmen umzuwandeln.

Das Skript ist entstanden, weil moderne Multimediaboxen zwar auch hochaufgelöste Bilder wiedergeben können, aber bei großen Bilddateien doch merklich langsamer reagieren. Außerdem haben mich die Balken gestört, welche bei der Wiedergabe auf einem 16:9 Fernseher auftreten.

Außerdem werden bei mir die Fotos etwas zu dunkel wiedergegeben, und das läßt sich an meinem Fernseher nicht richtig kompensieren.

Das Skript sortiert zudem Bilder im Hochformat aus, weil die auf dem Fernseher einfach doof aussehen. Bei diesen neumodischen digitalen Bilderrahmen sieht das anders aus, deswegen erfahren diese Hochkant-Bilder im Script eine gesonderte Behandlung.

Die Originalbilder bleiben unverändert, es werden unterhalb des Arbeitsverzeichnisses die Verzeichnisse „hoch“ und „quer“ angelegt, wo die umgewandelten Bilder abgelegt werden. Die Exif-Daten bleiben erhalten.

Die gewünschte Auflösung wird in der Variablen „resolution“ definiert, ein paar gängige Auflösungen habe ich bereits eingetragen.

Die Bilder werden auf die gewünschte Auflösung verkleinert. Dabei werden überflüssige Seitenränder beschnitten, damit eine unverzerrtes Ergebnis erzielt werden kann. Die verkleinerten Bilder werden leicht nachgeschärft, was beim Verkleinern notwendig ist.

Die (standardmäßig auskommentierte) Variable „gamma“ regelt das Aufhellen/Abdunkeln der Bilder. Der vorgegebene Wert von „1.2“ ist bei mir optimal. Normalerweise bringen hier Werte zwischen 0.8 und 1.2 optimale Ergebnisse, aber das müßt ihr für euer Setup selbst herausfinden.

Die Zeile 29 kann ggfs. auskommentiert werden, wenn ihr einen Bilderrahmen mit integrierten Lagesensor habt. Sollten die Hochformat-Bilder auf dem Kopf stehen, müßt ihr dort den Wert von 90 zu 270 ändern.

#!/bin/bash

## Benötigt werden die Pakete imagemagick, libjpeg-progs und jhead
## ( sudo apt-get install imagemagick libjpeg-progs jhead )
## Stand 14.12.2009
## Entwickelt unter Ubuntu 9.10, Karmic Koala

#resolution="800x600" #Bilderrahmen
#resolution="1680x1050" #PC-Widescreen
#resolution="1280x720"
#resolution="1366x768" #HD-Ready
resolution="1920x1080" #Full-HD

#gamma="-level 0%,100%,1.2" #Helligkeitsanpassung, falls Bilder zu dunkel oder zu hell wiedergegeben werden.

mkdir "hoch" "quer"

PICS=$(ls -A . | grep -i jpg)

for i in ${PICS}
do
  convert "$i" -resize $resolution^ -gravity center -extent $resolution -unsharp 0x1 $gamma -auto-orient "/tmp/$i"
#  convert "$i" -resize $resolution^ -gravity center -extent $resolution -unsharp 0x1 $gamma -gravity northwest -pointsize 40 -fill white -undercolor '#00000080' -annotate +50+50 "Belichtung: %[exif:ExposureTime]\nBlende: %[exif:FNumber]\nISO: %[exif:ISOSpeedRatings]" "/tmp/$i"
  height=`identify -format "%h" "/tmp/$i"`
  width=`identify -format "%w" "/tmp/$i"`
  if [ $height -lt $width ] ; then
    mv "/tmp/$i" "quer/$i"
  else
    jhead -cmd "jpegtran -rot 90 &i > &o" "/tmp/$i" #Anpassung für Bilderrahmen ohne Lagesensor
    mv "/tmp/$i" "hoch/$i"
  fi
done

#Bilder umbenennen, damit die Sortierung bei der Mischung versch. Kameras stimmt
jhead -ft -n%Y%m%d-%H%M%S quer/*
jhead -ft -n%Y%m%d-%H%M%S hoch/*

Optimale Partitionierung von Ubuntu

Nachdem mir die aktuelle Suchstatistik für das Blog anzeigt, daß dieses Themengebiet hier öfters nachgefragt wird, möchte ich ein paar Anmerkungen dazu machen.

Eine übliche Ubuntu-Installation sieht i.d.R von den Partitionen her so aus:

Erläuterung:

/dev/sda1 Windows-Partition
/dev/sda2 Ubuntu-Installation
/dev/sda4 erweiterte Partition
/dev/sda5 Swap-Partition in der erweiterten Partition

Je nachdem, mit welcher Ubuntu-Version man die Ersteinrichtung durchgeführt hat, kann die Partitionseinteilung aber auch anders aussehen:

/dev/sda1 Windows-Partition
/dev/sda4 erweiterte Partition
/dev/sda5 Ubuntu-Installation in der erweiterten Partition
/dev/sda6 Swap-Partition in der erweiterten Partition

Der wesentliche Unterschied besteht darin, daß Ubuntu dabei vollständig in der erweiterten Partition installiert ist. Auswirkungen auf die Funktionalität hat dies nicht, aber es hat Vorteile, falls man noch weitere verschiedene Betriebssysteme auf dem gleichen Rechner installieren möchte.

[picapp align=“center“ wrap=“false“ link=“term=hard+disk&iid=5120359″ src=“4/9/3/1/computer_elements_17d2.jpg?adImageId=7949499&imageId=5120359″ width=“500″ height=“333″ /]

Ubuntu in einer oder mit mehreren Partitionen installieren?

In früheren Zeiten wurden klassische Linux und Unix-Installationen immer mit mehreren Partitionen realisiert. In diesem etwas älteren Artikel kann man ein solches Partitionsmodell nachlesen und auch die damaligen Begründungen dafür erfahren.

Der genannte Artikel bezieht sich auf den Einsatz von Linux-Servern, und da gelten erstmal sowieso ganz andere Kriterien für die technische Umsetzung als bei Desktop-Installationen, wie sie jetzt üblicherweise bei Ubuntu-Systemen vorzufinden sind.

So sollte man ein Desktop-Linux nicht installieren.

Normalerweise sollte man einfach die Standardpartitionierung von Ubuntu übernehmen.

Es gibt nur zwei Situationen, wo es technisch zwingend ist, eine eigene /boot Partition zu verwenden:

1. Wenn man ein uraltes BIOS hat, und die Boot-Files innerhalb der ersten 1024 Zylinder der Festplatte liegen müssen (so ein System besitze ich sogar)

2. Beim Einsatz einer kompletten Systemverschlüsselung. Dabei kann /boot nämlich derzeit nicht verschlüsselt werden.

Ab Ubuntu 9.04 Karmic Koala ist es übrigens für den Betrieb von Software-Raid nicht mehr nötig ein eigenes /boot anzulegen (habe ich aber noch nicht getestet)

Sollte man /home auf eine eigene Partition legen?

Nein.

Ich weiß, daß das zwar sogar im berühmten „Kofler“ so empfohlen wird, aber ich halte das für keine gute Vorgehensweise.

Gerade viele Ubuntu-Anwender tendieren dazu, diese Einteilung vorzunehmen, da alle halbe Jahre ein neuer Ubuntu-Release herauskommt, man dann das reine System einfach wegwirft, und dann eine frische Installation unter Beibehaltung von /home machen kann.

Auf den ersten Blick gar nicht mal so schlecht, aber der Teufel steckt halt im Detail. Was ist denn, wenn man bei einem neuen Release festellt, daß es doch nicht so perfekt funktioniert? Wenn z.B. die WLAN-Verbindung dauernd ausfällt, oder andere Dinge nicht funktionieren, die man nicht gleich bemerkt?

Oder, viel schlimmer, wenn die Konfigurationsparameter sich mit den alten Einstellungen beißen. Ich kenne einige Beispiele dafür, wo sich der Gnome-Desktop durch alte Einstellungen auf einmal ziemlich seltsam verhalten hat. Will man dann auf den verhergehenden Releasestand zurückwechseln, hat man schnell einen Mischmasch zwischen „alten“ und „neuen“ Einstellungen. Das ist nicht gerade optimal.

Um all diesen Fallstricken aus dem Weg zu gehen, empfehle ich bei Ubuntu-Updates eine andere Vorgehensweise: Ich entferne alle Ubuntu-Partitionen (sogar Swap und die erweiterte Partition), und lasse dann Ubuntu in den nun freien Bereich installieren.

Die Daten hole ich mir dann gezielt aus dem Backup zurück, dabei fasse ich bei den Konfigurationsverzeichnissen (die versteckten Verzeichnisse mit dem Punkt am Anfang) wirklich nur die Nötigsten an, z.B. die Einstellungen für den Messenger und den Browser. Auf diese Weise ist zudem sichergestellt, daß man keinen alten Schrott mitschleppt.

Natürlich setzt das voraus, daß man über eine richtige Backup-Strategie verfügt, aber dieses Thema wird hier ja öfters behandelt.

Artikelstatus: Vorabveröffentlichung, wird noch ergänzt/erweitert/überarbeitet.

Knacksende Geräusche unter Ubuntu Karmic Koala

Dieses unangenehme Phänomen kann man durch Auskommentieren der letzten Zeile in der /etc/modprobe.d/alsa-base.conf beseitigen:

# options snd-hda-intel power_save=10 power_save_controller=N

First Look: Ubuntu 9.10 Karmic Koala (Beta)

[picapp src=“0268/a90a8a91-4da4-4ced-9a1b-748b6feacbb8.jpg?adImageId=5068297&imageId=272250″ width=“500″ height=“332″ /]

Eigentlich habe ich mich ja dafür entschieden, bei Ubuntu nur noch auf die LTS-Versionen zu setzen, weil es mir einfach zu stressig ist, mich alle halbe Jahre mit einem neuen Betriebssystem herumzuschlagen. Diese Strategie hat sich auch ganz gut bewährt, aber bei neuen Ubuntu-Releases schaut man ab und zu doch mal drauf, um zu sehen, in welche Richtung es in Zukunft gehen wird.

Jetzt ist die Beta von“ Karmic Koala“ herausgekommen, und bei der gibt es gleich zwei ziemlich knackige Änderungen: Zum Einen wird standardmäßig das Dateisystem Ext4 verwendet, und zum Anderen wird als Bootloader Grub2 eingesetzt.

Beides ist für mich besonders relevant, weil es direkt mit meinem Backup/Restore-Konzept zu tun hat.

Die ersten Tests verliefen recht angenehm. Mein neuer WLAN-Stick (nicht von AVM) wurde sauber erkannt, und ich mußte nur den WPA2-Schlüssel eingeben, damit das Netzwerk funktioniert (das muß ich mitttlerweile aber relativieren, denn nach einigen Updates funktioniert das WLAN jetzt nur noch sehr unzuverlässig :(). Auch der proprietäre NVIDIA-Grafikkartentreiber ist ohne Probleme nutzbar. Zum ersten Mal kann ich „Suspend-to-Ram“ und „Suspend-to-Disk“ wirklich „Out-of-the-Box“ benutzen, da wurde großartige Arbeit geleistet.

Eine faustdicke Überraschung ist allerdings dieses Grub2. Hier ist irgendwie alles anders als bei Grub, und ich glaube, es wäre fast besser gewesen, diesem Bootloader gleich einen gänzlich anderen Namen zu geben.

Das Problem ist, daß Grub2 nicht abwärtskompatibel ist. War man bislang gewohnt sein System mit Hilfe der /boot/grub/menu.lst anzupassen, so muß man hier kräftig umdenken, denn dieser Mechanismus wurde radikal umgekrempelt.

Bei Grub2 werden alternative Kernel und Betriebssysteme nämlich nicht mehr statisch eingetragen, sondern bei einem „sudo update-grub“ dynamisch aus der vorliegenden Systemkonfiguration ermittelt. Bei Installationen mit mehreren Betriebssystemen hat das durchaus gewisse Vorteile, aber wenn man z.B die SystemRescueCD zusätzlich auf der Festplatte installieren möchte, ist erstmal einiges an Gehirnschmalz zu investieren, damit das reibungslos klappt.

Für mich bedeutet das, daß ich hier einige Artikel ergänzen muß (kotz), damit diesem Sachverhalt genüge getan wird.

Aber die Sache hat auch etwas Positives: Mit Grub2 soll man direkt von einem Raid-Verbund booten können. Das war bislang nur bei einem Raid-1 möglich, und wenn das jetzt auch mit den anderen Raid-Leveln möglich ist, wäre das ein gigantischer Fortschritt.

Es stellt sich nun die Frage, ob man das Update auf Karmic Koala gefahrlos mitmachen kann, denn mit einem neuen Dateisystem und einem völlig neuen Bootloader werden ganz essentielle Bestandteile des Betriebssystems geändert. Die Entwicklung von Grub2 ist z.B. noch gar nicht abgeschlossen, und Ext4 ist auch noch ziemlich neu. Das Problem dabei ist, daß Dokumentation und Erfahrungsberichte dazu noch recht dünn gesät sind.

Ich persönlich werde „Karmic Koala“ erstmal auf einer extra Festplatte installieren und ordentlich Erfahrungen sammeln.

Meine „Produktivsysteme“ werde ich dann ab dem 26.04.09 umstellen, wenn die nächste LTS-Version „Lucid Lynx“ herauskommt.