Java auf linux-ppc

Auch auf dem neuesten Kubuntu Edgy Eft für Linux ppc-arch. funktioniert der GJC (GNU Java) überhaupt nicht. Also wieder Standardmethode.
Ausgehend von dem rpm Paket IBMJava2-JRE-ppc-1.4.2-1.0.ppc.rpm, welches ich mir mal vor längerer Zeit von einer IBM Seite (mit Registrierung) gezogen habe, wird zuerst mal nach deb umgewandelt (Kubuntu/Ubuntu Linux basiert auf Debian).
Nach der Installation muss noch eine magische Umgebungsvariable in ein profile script aufgenommen werden:
export JITC_PROCESSOR_TYPE=6

Falls jemand das Paket oder den Linux benötigt bitte kurz einen Kommentar hinterlassen

Solaris 64bit System (sparc)

Interessant scheint mir, dass auf einem UltraSparc IIe Rechner
SunOS Release 5.10 Version Generic 64-bit

die meisten Dateien des Betriebssystem „nur“ 32bit Binaries sind.
# file /usr/bin/ls
/usr/bin/ls: ELF 32-Bit MSB ausführbar SPARC Version 1,..

Interessant vor allem, weil die Solaris10 Variante auf x64 eher 64bit binaries enthält. Auf dieser Plattform gibt es laut SUN eher Performancevorteile durch bessere Register. Der Grund für die 32bit Programme auf UltraSparc ist wohl der Speicher Overhead einer 64bit Applikation der sich leicht negativ auswirkt.
http://developers.sun.com/sunstudio/articles/options.html

Sun Solaris 10 als (open)LDAP client

Wenn im Netzwerk eine Single-Sign-On Authentifizierung via openLDAP existiert und eine neue Solaris Maschine angebunden werden soll benötigt man dort das ldapclient Kommando.

Zuerst sollte man aber einen genaueren Blick in die Datei

/etc/nsswitch.ldap

werfen. Denn diese Datei wird nach mit dem Aufruf des ldapclient Kommandos nach /etc/nsswitch.conf kopiert. Wenn man bspw. nur Accounts mit openLDAP verwaltet, Hostnamen aber via DNS, dann muss man den Eintrag

hosts: ldap [NOTFOUND=return] files

in

hosts: files dns

ändern. Denn sonst funktioniert bestenfalls keine Hostnamensauflösung mehr, schlechtestenfalls bootet der Rechner gar nicht mehr, falls in /etc/hosts der eigene Rechnername nicht gelistet ist.

Nach dem ändern dieser Datei wird nun das Kommando aufgerufen, dass eine persistente – also einen Neustart überlebende – LDAP Anbindung schafft. Das erste Argument kann init oder manual lauten. „init“ setzt eine automatische Konfiguration voraus, welche im LDAP Repository schon vorhanden ist. Falls nicht kann man diese aber auch mit diesem Befehl erzeugen und im LDAP Server dann einspielen – näheres sagt die manpage über diesen Befehl.

Der andere Weg ist die manuelle Anbindung. Beispielhaft sieht sowas folgendermaßen aus:

ldapclient manual -a „defaultSearchBase=o=myOrganization,c=de“ -a „defaultServerList=ldaphost.mydomain.de“ -a serviceAuthentificationMethod=pam_ldap:tls:simple“

Dieser Befehl schreibt diese Konfiguration dann nach /var/ldap und startet via SMF den ldap/client. Der Befehl

svcs -l ldap/client

sollte dann den Status online ausgeben.

Falls „getent passwd“ oder „getent group“ nicht die gewünschte Anbindung anzeigt, muss ev. mit dem Attribut „serviceSearchDescriptor“ nachgeholfen werden. Nachträgliche Änderungen erfolgen mit ldapclient mod

ZFS

ja das fehlt noch – ein stabiles und modernes Filesystem das alle UNIX Varianten beherschen.

Und ich hoffe es wird ZFS sein (Zettabyte File System) – wieder aus dem Hause Sun, die schon den Vorläufer UFS (UNIX File System) herausbrachten, welcher theoretisch (aber nicht praktisch, da durch viele Varianten verwässert) auf allen UNIXen laufen sollte.

Bedeutung hat ein einheitliches FileSystem v.a. für Wechseldatenträger.

Unter Linux wird es nur noch eine Frage der Zeit sein – Fortschritte gab es durch Google’s Summer of Code 2006. Im Frühjahr 2006 gab es auch Gerüchte dass Mac OS X, zukünftig auf ZFS setzt. Bisher hat man nichts mehr gehört – aber es sollen ja noch einige Features der nächsten Release Leopard geheim sein…

Hier wird einem der Mund wässrig gemacht:

http://unixconsult.org/zfs_vs_lvm.html

Dateinamen in UTF-8

Auf UNIX Filesystemen werden die Dateinamen schon seit längerer Zeit mit der Zeichenkodierung UTF-8 gespeichert. Da auch NFS seit langem UTF-8 unterstützt könnte man meinen, man sei im UNIX-Paradies des heterogenen Dateiaustausches.

Leider nicht, denn einer macht’s immer anders. Mac OS X hat sich für eine spezielle Variante entschieden, bekannt unter Form D

Form D kennt kein „precomposing“ – ein zusammengesetzes Zeichen, bpsw. deutsche Umlaute, wird getrennt als Buchstabe und die darüberliegenden Pünktchen kodiert. Dieses Vorgehen hat Vorteile bei der Suche.

Der Nachteil ist dass alle anderen, Linux – Windows – kommerzielle UNIX’es – W3C das „precomposing“, bekannt als Form C verwenden. Dort wird ein Umlaut als ein Zeichen (mit 2 Bytes) kodiert.

Lediglich die Zeichen des ASCII Codecs sind immer gleich. Falls man Dateinamen mit Zeichen ausserhalb des ASCII Bereiches verwendet, wird man Probleme bekommen. Tatsache ist:

Form C Dateinamen aus der Linux/UNIX Welt kann der Finder in Mac OS X darstellen, aber einige Programme aus dem Hause Apple nicht öffnen (bspw. iPhoto)

Form D Dateinamen aus der Mac OS X Welt können zumindest unter Linux problemlos verarbeitet werden. Zudem stellen konsole/xterm die Dateinamen einwandfrei dar – konqueror sieht man das decomposing an – María wird mit einem i-Punkt und einem Akzent dargestellt – das ist verkraftbar…

Hier ist Linux flexibler und muss als Klügerer nachgeben – mit folgendem Befehl werden alle Dateinamen in den home Verzeichnisse von Form C auf Form D konvertiert.

convmv -r -f utf8 -t utf8 –nfd –notest /home

ONLINE

Es ist vollbracht!

Mein Blog – vornehmlich über UNIX Themen – ist online. Bezweifle dass viele den Weg hierher finden wollen oder können. Aber er reicht ja schon wenn einer etwas verwertbares hier findet. Ausserdem kann man hier schnell etwas festhalten was vielleicht nochmal gebraucht wird – früher standen diese Dinge normalerweise auf einem Zettel der wenn er denn gebraucht wurde meist schon durch die Müllverbrennungsanlage entmaterialisiert wurde.
Ich wünsch den Lesern und mir jedenfalls viel Spaß…