Beim Zugriff über ssh auf ein etwas älteres Unix wie z.B. Solaris 10 erhält man in vi oder manchen anderen Terminal-Anwendungen eine Fehlermeldung wie
xterm-256color: Unknown terminal type
Die Anwendung ist dann meistens nicht oder nur eingeschränkt benutzbar.
Die triviale Lösung ist einfach die TERM
-Umgebungsvariable auf xterm
zu setzen. Wenn man das nicht immer manuell machen will, kann man das einfach in der .profile Datei (oder .bash_profile, wenn die Login-Shell die bash ist) folgendes hinzufügen:
if [ $TERM = "xterm-256color" ]; then
TERM=xterm
export TERM
fi
Wenn man root-Rechte auf dem Server hat, gibt es auch noch eine andere Lösung. Es gibt eine Terminfo-Datenbank, die für die verschiedenen Terminal-Typen die Fähigkeiten enthält. Den fehlenden Eintrag für das xterm-256color Terminal kann man einfach hinzufügen.
Unter Solaris 10 finden sich die Terminfo-Dateien unter /usr/share/lib/terminfo
. Dort gibt es für jeden möglichen Anfangsbuchstaben ein Verzeichnis, die xterm Einträge sind daher unter /usr/share/lib/terminfo/x
. Dort muss eine Datei xterm-256color
rein. Die ganz einfache Lösung wäre einfach die xterm
-Datei zu kopieren. Ich hab hingegen die xterm-256color
-Datei von einem Solaris 11 dort eingefügt. Beides funktioniert und sobald diese Datei da ist, erkennen Anwendungen auch das xterm-256color-Terminal.
Hardware-RAID hat gegenüber ZFS so einige Nachteile. Keine Checksums, resilvern dauert lange, Inkompatiblitäten zu anderen RAID-Controllern, da ist man echt froh, wenn man das nicht hat. Ein Argument gegen ZFS ist allerdings der Ressourcen-Verbrauch, denn statt Hardware-RAID-Controllern muss jetzt Software den selben Job und noch mehr erledigen. Spüren tut man das allerdings nicht, denn die CPUs sind heutzutage so schnell, dass die das locker nebenbei erledigen.
Dieses prähistorische Dinosaurier-RAID ist vielleicht nicht so toll, doch wenn man nur die passenden Dinosaurier-CPUs dazu hat, dann hat das ganze doch ein paar Vorteile. Ich habe kürzlich auf einer Sun Ultra 25 Workstation ein raidz1 mit 3 Platten gebildet. Die Workstation stammt aus dem Jahr 2006, die darin verbaute UltraSPARC IIIi CPU gibt es allerdings seit 2003. Und damit merkt man leider schon, was ZFS so an Rechenleistung verbrennt.
Ein Ausschnitt der Ausgabe von prstat wärend mit dd auf den raidz1 pool geschrieben wurde:
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
107 root 0K 0K run 0 -20 0:00:25 58% zpool-storage/136
967 root 4624K 2152K run 53 0 0:00:08 12% dd/1
Und wenn parallel dazu noch auf den rpool, der nur aus einer Festplatte besteht, geschrieben wurde:
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
107 root 0K 0K sleep 99 -20 0:01:55 41% zpool-storage/136
980 root 4624K 2216K sleep 53 0 0:00:04 11% dd/1
5 root 0K 0K run 0 -20 0:00:23 6,1% zpool-rpool/136
981 olaf 4624K 2320K run 39 0 0:00:01 4,1% dd/1
Es ist also doch kein Mythos, dass ZFS ein paar Ressourcen braucht. Und ein zpool scrub
verursacht sogar über 90% CPU-Auslastung.
Ich finde den Fall einfach zu erbärmlich um ihn nicht zu erwähnen.
User creation dialog design and usability
Linux-Desktops wird oft nachgesagt, dass sie inkonsistente Userinterfaces haben, jede Anwendung nutzt ein anderes Toolkit mit anderem Look and Feel. Das Design stammt oft von irgendwelchen C-Hackern, die keine Ahnung von GUI-Gestaltung haben. Aber alle diese Probleme hat man mitlerweile auch bei Windows. Jede Microsoftanwendung hat ein anderes Look and Feel. Und solche lächerlichen Fehler wie uneinheitliche Positionen für Buttons darf es bei einem so großen Unternehmen nicht geben.
Unter Linux kann man Man-Pages in html umwandeln und im Browser öffnen:
man --html=firefox ls
Dies wandelt die Man-Page für ls
in html um und speichert dies in einer temporären Datei. Anschließend wird dann firefox
mit entsprechendem Parameter aufgerufen.
Damit dies funktioniert muss groff
installiert sein, was beispielsweise unter Ubuntu standardmäßig nicht installiert ist.