Archiv des Autors: AS

Asus Eee PC mit Ubuntu 10.10 (Maverick Meerkat)

Auch wenn mein Apple MacBook Pro (13.3 Zoll) ja schon recht handlich ist, so wäre als Reisebegleiter weniger Gewicht und weniger Größe durchaus nett – ich teste daher gerade einen Asus Eee PC (danke an die Kollegen von make.tv für die Leihgabe!).

An Windows mag ich mich aber nicht gewöhnen müssen. Als erstes wurde daher ein Image der bestehenden Platte gemacht und das installierte Windows XP durch ein Ubuntu 10.10 (Maverick Meerkat) ersetzt.

In Ermangelung eines internen CD-/DVD-Laufwerks wollte ich vom USB Stick booten, dies schlug aber fehl. Trotz verschiedener USB Sticks, trotz der Erstellung des bootfähigen Images unter Linux und Mac OS hat der Eee PC partout nicht vom USB Device booten wollen. Mit einem externen USB CD-Laufwerk hingegen klappte die Installation ohne Probleme – bis auf eine Kleinigkeit, die aber schnell zu beheben war:

Displayhelligkeit

Das Display gibt erst einmal ein enttäuschendes Bild ab: Es ist nach der Installation dunkler als beim vorher installierten Windows und läßt sich über die Einstelldialoge von Ubuntu ebenso wenig gut einstellen wie über die Funktionstasten: Die Helligkeit “springt” zwischen den Stufen stark hin und her – und bei Einstellungen über 79% Bildschirmhelligkeit wird es wieder dunkler (!).

Die Lösung hierfür ist schnell und einfach, gefunden im Blog von Tom Schimana:

Datei “/etc/default/grub” editieren:

vi /etc/default/grub

Dort zur Zeile GRUB_CMDLINE_LINUX_DEFAULT navigieren und hier folgende Änderung vornehmen bzw. die Zeile durch diesen Text ersetzen:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=Linux"

Mit sudo update-grub2 die Änderungen speichern bzw. die Grub Konfiguration erzeugen, reboot und schon ist das Problem gelöst…

Zwischenfazit

Nachdem nun der Monitor hell strahlt, bin ich mit dem ersten Eindruck sehr zufrieden. Natürlich ist so ein Asus Eee PC kein Ersatz für mein Apple MacBook Pro, aber mit ca. 250.- Ladenpreis kostet das Netbook schließlich auch nur ca. ein Drittel…

Ich nutze den Rechner jetzt ein paar Tage zu Hause und entscheide, ob ich damit in unserer Ferienwohnung im Urlaub für ein paar Stunden arbeiten kann. In dem Falle bleibt der Apple zu Hause – das Asus Gerät ist leichter, kleiner und im Falle eines Diebstahls eher zu verschmerzen ;-)


rsync zwischen MacOS (HFS+) und Linux (ext3) – und defekte Dateinamen

Bei umfangreicheren rsync-Läufen hier im lokalen Netz (ging um ca. 4 TB die von einem Ubuntu Server mit ext3 auf einen Mac mit HFS+ gehen sollten) stellten sich 2 Probleme heraus, die beim Sync zwischen Linux Maschinen nicht auftraten:

  • Ein großer Teil der Daten (und zwar alle mit Leerzeichen oder Umlauten im Dateinamen) wurde bei jedem rsync Aufruf neu übertragen, obwohl die Dateien sich nicht geändert hatten.
  • Umlaute waren z.T. defekt.

Eine längere Herleitung spare ich mir hier mal – statt dessen nur das Ergebnis der Recherchen, da das ggf. noch für jemanden nützlich sein könnte:

Das Problem entstand durch unterschiedliche Charsets auf beiden Maschinen:

Something else that can trip up rsync is a filesystem changeing the filename behind the scenes. This can happen when a filesystem changes an all-uppercase name into lowercase, or when it decomposes UTF-8 behind your back.

An example of the latter can occur with HFS+ on Mac OS X: if you copy a directory with a file that has a UTF-8 character sequence in it, say a 2-byte umlaut-u (\0303\0274), the file will get that character stored by the filesystem using 3 bytes (\0165\0314\0210), and rsync will not know that these differing filenames are the same file (it will, in fact, remove a prior copy of the file if –delete is enabled, and then recreate it).

You can avoid a charset problem by passing an appropriate –iconv option to rsync that tells it what character-set the source files are, and what character-set the destination files get stored in. For instance, the above Mac OS X problem would be dealt with by using –iconv=UTF-8,UTF8-MAC (UTF8-MAC is a pseudo-charset recognized by Mac OS X iconv in which all characters are decomposed).

(Die Erklärung stammt aus der rsync FAQ.)

Dem geneigten Mac-User fällt aber leider schnell auf, dass das mitgelieferte rsync den Parameter --iconv leider nicht versteht. Hier empfiehlt sich das Updaten z.B. über Macports – dazu hatte ich hier gerade schon ein paar Zeilen geschrieben.

Lange Rede, kurzer Sinn – nach dem rsync Update und der Angabe der Parameter schaut das bisher sehr gut aus. Folgender Kommandozeilenaufruf wird dabei verwendet:

rsync -a --modify-window=1 --stats --progress --exclude "*.frk"' --delete --iconv=UTF8-MAC,UTF8 root@SERVERNAME:/pfad/zum/Quell-Verzeichnis/ /pfad/zum/Ziel-Verzeichnis/

Kurznotiz: Darwinports, Fink und Macports

Nachdem Stefan in seinem Blog kurz und eindringlich von Darwinports abriet und Fink mich vor einiger Zeit schon nicht begeistert hatte, habe ich heute mal Macports eine Chance gegeben.

Kurzfazit:

  • Installation über einen Mac Installer (!), entsprechend problemlos und schnell
  • Installation von Paketen sehr einfach, automatische Auflösung von Abhängigkeiten klappt gut
  • binnen 15 min. gewechselt vom unerträglich schlechten RSYNC auf dem Mac zu einer aktuellen Version (rsync  version 3.0.7  protocol version 30)

Tipp der Redaktion, sozusagen ;-)

Google Street View und der LDI NRW (Landesbeauftragter für Datenschutz und Informationsfreiheit)

Ich bin erstaunt – wenngleich die Datenschützer (m.E. zu Recht) Google Street View das Leben bisweilen schwer gemacht haben, hat der Landesbeauftragte für Datenschutz und Informationsfreiheit NRW anscheinend darauf verzichtet, das Bürogebäude verpixeln zu lassen:

Autoresponder im eCommerce…

…oder wie man es nicht machen sollte – gerade diese nicht allzu kundenverständliche Mail eines Amazon Merchants erhalten:

------------- Anfang der Nachricht -------------

!R! CALL ARKT; EXIT;

Da fragt man doch gerne mal zurück: WTF? ;-)