Category: Solaris

Die letzte iX veröffentlichte eine Umfrage, welche auf die Benutzung von Linux auf dem Desktop abzielte. Das ernüchternde Ergebnis war, dass sich seit der gleichen Umfrage von 2006 fast nichts veränderte, es wurde sogar ein minimaler Rückgang verzeichnet. Auch andere „Messergebnisse“ oder Prognosen bescheinigen Linux eine Stagnation auf dem Desktop – je nach Land und Methode so zwischen 1 – 3% Marktanteil.

Mac OS X hingegen baut auf dem Desktop seine Stellung weiter aus und kratzt momentan deutschland- und weltweit an der 10% Marke. Kommerzielle Workstation UNIX Varianten, wie Sun Solaris – spielen in diesem Segment keine Rolle mehr. Eher noch dringen Embedded Geräte – mit einem meistens auf Linux basierenden OS – weiter vor.

Die Zukunft von Sun Solaris ist sehr ungewiss. Natürlich spielt es im Enterprise Bereich bei den Hochleistungsservern noch eine grosse Rolle aber Linux rückt auch dort dichter auf die Pelle. Oracle – der neue Besitzer von Sun Microsystems – könnte mit einer eigenen Linuxdistribution die Entwicklungskosten, die Solaris derzeit benötigt, wahrscheinlich deutlich reduzieren. Allerdings würden Sie dann auch die Alleinstellungsmerkmale von Solaris aufgeben – vielleicht bauen Sie deshalb nur die Kompatibilitätsschichten zu Linux weiter aus.

Bei Linux zeichnen sich unterschiedliche Tendenzen ab. Aufgrund der hohen Innovationsgeschwindigkeit und der kurzen Releasezyklen des Kernels wird Linux seine Stellung im SOHO-/Midrange-Server und HPC Bereich weiter ausbauen und zum dominaten Mitspieler in dieser Kategorie aufsteigen.

Im klassischen Desktop Bereich scheint sich aber der Abstand zu Mac OS X und Windows zu vergrössern. Während man sich bei der Linux Foundation noch darum bemüht die Grundlagen des Desktops (Dialoge, etc.) aufgrund mehrerer vorhandener Windowmanager zu vereinheitlichen, ist Mac OS X – aber auch Windows – schon mit sehr mächtigen Frameworks (CoreAudio,CoreGraphics,Windows Presentation Foundation,Windows Communication Foundation) ausgestattet. Diese API’s erlauben Anwendungsprogrammierer sich nur primär auf die Logik Ihrer Applikation zu konzentrieren während man sich unter Linux noch um den ganzen Rest kümmern muss. Natürlich gibt es auch auf dem Linux Desktop diese Ansätze (bspw. GStreamer als Kooperation zwischen Gnome und KDE), diese sind aber noch in der Anfangsphase – nicht immer ausgereift und es gibt v.a. keinen Hinweis darauf wie diese Technologielücke in der nächsten Zeit geschlossen werden sollte.

Damit wird sich Linux als Desktop bei Privatnutzern trotz der Stabilitäts- und Sicherheitsvorteile in der nächsten Zeit nicht durchsetzen können. Anders sieht es in gewissen Enterprise Bereichen aus. Dort wo das Betriebssystem quasi nur als Programmstarter benutzt wird und die überschaubaren Applikationen mit maximaler Stabilität und Performance laufen müssen, ist Linux im Vorteil – sofern die Applikationen die Plattform unterstützen.

Noch besser sieht es im bei Spezialanwendungen oder im Embedded Bereich aus. Dank der flexiblen Konfigurationsmöglichkeiten die Windows und Mac OS X einfach nicht bieten, ist dort Linux mit Abstand die beste Wahl. Da es sich dort auch schon seit einiger Zeit im harten Einsatz bewährt hat, wird sich die Verbreitung von Linux auf solchen Systemen in nächster Zeit beschleunigen.

Der Mac OS X Zug fährt mit konstanter Geschwindigkeit weiter. Nach der 10% Hürde wird es Apple in den nächsten Jahren schaffen 20% des Desktop Marktes für sich zu beanspruchen. Auch wenn einige Entscheidungen aus dem Hause Apple schwer nachzuvollziehen sind (Vernachlässigung der Pro Sparte im Hardware Bereich) bleibt Mac OS X das beste Desktop System unserer Zeit. Die Verschmelzung der klassischen Mac OS GUI’s mit der UNIX Technik von NEXT brachte ein System hervor, welches aus mehreren Welten das Beste vereinte und auf dem Desktop technisch wie ergonomisch das Feld mit grossem Abstand anführt.

Wenn man übergreifend den ganzen IT Kuchen betrachtet, werden die Stücke die auf UNIX Technologie basieren – und damit sind nicht die imkompatibel in Windows hereingewanderten Komponenten gemeint 🙂 – kontinuierlich grösser.

Lange ist es her als Apple ankündigte, dass ZFS in Mac OS X Einzug halten sollten.  Leider ist die Einbindung immer noch recht rudimentär. Nicht besser, eher schlechter, sieht es unter Linux aus. Da die von Sun für ZFS gewählte CDDL Lizenz, nicht kompatibel zur GPL ist, gibt es keine Kernelunterstützung für ZFS in Linux (im Gegensatz zu BSD). Dafür ist das Filesystem im Userland mittels FUSE jetzt angesiedelt.

Auch wenn die Unterstützung noch zu wünschen übrig lässt, sind dennoch die bestehenden Implementierungen stabil genug um einen ernsthaften Test zu wagen, der auch – ums vorweg zu nehmen – erfolgreich war.

Hintergrund ist, dass man unterhalb der verschiedenen UNIX Systeme immer noch kein gemeinsames Filesystem hat mit dem man portable Datenträger versehen könnte. FAT32 ist denkbar ungeignet, da es

• das POSIX Rechtesystem nicht kennt
• weder softlinks beherscht, noch case-sensitiv ist
• äussert unperformant ist

Somit kann bspw. rsync Operationen auf solchen Datenträgern vergessen.

ZFS bringt sehr viele neue Ansätze mit, bestechend ist aber dass sich verschiedene ZFS Filesysteme –  sog. data sets – auf pools arbeiten die online jederzeit neue Datenträger aufnehmen können. Alle Grenzen sind online beliebig verschiebbar, die klassische Trennung Filesystem-Volume-Datenträger wird also aufgehoben.

Nach diesen warmen einleitenden Worten nun die Vorgehensweise beim erzeugen eines ZFS sets auf einem externen Datenträger – dazu müssen auf Linux die Pakete fuse und  zfs-fuse installiert sein.

1. Nach dem Anschließen der Festplatte, meldet sich diese als /dev/sde

2. mit fdisk eine Partitionstabelle  auf /dev/sde erstellen

3. zpool create -o version=8 testpool /dev/sde

Hintergrund:  Die Spezifikation der ZFS pools wird laufend weiterentwickelt. Dabei wird die Versionsnummer der ZFS pool Beschreibung hochgezählt. Unter Linux werden mit zfs-fuse 0.5 Pools bis zur Version 13 unterstützt. Die letzte ZFS Implementierung unter Mac OS X kann aber nur Version 8. Auf einem solchem System könnte auf kein ZFS pool > Version 8 zugegriffen werden, daher wird unter Linux der Pool explizit mit Version 8 erstellt.

Die unterstützten Versionen können jederzeit mit

zpool upgrade -v

angezeigt werden.

4. Nach der Erstellung des Pools „testpool“ ist dieser sofort als data-set benutzbar, was ok ist – man braucht bei einer externen FP nicht unbedingt ein zweites Dataset (welches mit

zfs create /testpool/subdirectory

angelegt werden könnte).

Der Mountpoint wird ebenfalls sofort ungefragt auf /testpool gelegt, man kann ihn ändern mit

zfs set mountpoint=/mnt/externalZFSdisk testpool

5. Nach solch einer Operation muss man ihn einmal wieder mounten

zfs mount testpool

6. Ein ZFS data set auf einer externen Festplatte wird normalerweise nicht ge- und unmounted sondern im- und exportiert.

zpool export testpool

damit wird implizit auf ungemounted.

7.  Auf einem anderem Rechner wird nun die FP angeschlossen:

zpool import

zeigt einem die verfügbaren Pools sofort an (in dem Fall testpool, inkl. den Informationen welcher Datenträger sich dahinter verbirgt)

zpool import testpool

macht ihn dem System zugänglich, indem er das dazugehörige dataset mounted (Unter Mac OS X wird es standardmässig dann unter

/Volumes/testpool

eingehängt.

Danach kann man problemlos darauf zugreifen. Normalerweise sollte nach der Session ein

zpool export testpool

ausreichen – unter Mac OS X – muss man aber trotzdem dass Volume mit den bekannten Methoden vorher auswerfen.

Der Datenaustausch mit allen oben erwähnten Annehmlichkeiten unter den UNIX Systemen steht nichts mehr im Wege.

Noch ein paar Hinweise..

zpool list

listet alle verfügbaren Pools auf, während

zpool status testpool

deren Status (v.a. im Fehlerfall hilfreich) anzeigt.

zpool iostat -v testpool

zeigt die I/O Transaktionen an

zpool add testpool /dev/sdf

würde dem Pool noch einen weiteren Datenträger zuweisen, was in diesem Bsp. keinen Sinn machen würde.

Unter Mac OS X wird mit dem ls Befehl schon angedeutet, dass die POSIX Rechte durch ACL’s erweitert sind. Tatsächlich unterstützt ZFS die neuen NFSv4 ACL’s die unter UNIX defacto ACL Standard darstellen und ziemlich an die Windows NT ACL’s angelehnt sind. Unter Linux werden diese leider noch nicht angezeigt. Sun’s eigene Solaris Umgebung verhält sich hier natürlich vorbildlich.

netstat ist ein ausgezeichnetes Kommando um sich schnell einen Überblick über alle vorhandene Socket Verbindungen zu bekommen. Hier ist die Zusammenfassung der gebräuchlichsten Parameter des GNU Kommandos welches auf jedem UNIX System zuhause ist:

Parameter	Langfassung	Bedeutung
-a	–all	alle aktiven und lauschenden(LISTEN) sockets
-l	–listening	Zeigt nur lauschende (LISTEN) sockets
-d	–directory	Zeigt den Directory Eintrag statt dessen Inhalt an
-p	–programm	Zeigt PID und Namen des verantwortlichen Prozesses (nur eigene)
-i	–interface=IFACE	zeigt Interface Infos an oder schränkt auf angegebens IFACE ein
-r	–route	Gibt alle Netzwerkrouten aus
-s	–statistics	Gibt Statistiken von /proc/net/snmp aus
-u	–sort=access	Sortiert nach Zugriffszeit (nur im Zusammenhang mit -t)
-n	–numeric	Verhindert Namensauflösung bei Hostangaben
-t / -u / -w / -x	…	Zeigt Infos über TCP / UDP / RAW / UNIX sockets an

Glücklicherweise gibt es auch eine Kommandotool um den I/O Durchsatz zu verfolgen, welches auf allen Plattformen verfügbar ist (unter SuSE Linux das Paket sysstat installieren).

iostat verfügt über einen statischen Output, sowie über ein Trackingmodus. Unter Linux wird dazu einfach als erster Parameter das Sekundenintervall angegeben, unter Sun Solaris dagegen nach dem Parameter -x, unter Mac OS X nach -w

Das Ergebniss wird tabellarisch angezeigt. Wichtig sind dabei die Felder tps (transfers per second) sowie die Durchsatzraten (entweder in kiloByte oder MegaByte angebbar).

Zudem wird immer auch die CPU Belastung (user,system,idle) protokolliert.

Probleme mit falschen Umlauten oder Sonderzeichen sind auf der Tagesordnung. Prinzipiell müsste das nicht sein, aber fehlerhafte Programmierung und fehlende Erkennungsmerkmale führen zu hohen Fehlerquoten.

Hintergrund ist dass auf allen gängigen UNIX Systemen UTF-8 als Standardkodierung sowohl für den Inhalt von Klartextdateien als auch für die Kodierung von Dateinamen (siehe auch Form C/D Unterschied) verwendet wird.

Bei Windows wird in unseren Breitengraden standardmässig Latin-1 verwendet (exakt: Windows CP-1252). Dies führt zu Problemen beim Dateiautausch, wenn kein Transformationsmechnismus (bspw. bei Mac OS X wenn Windows Shares via SMB kontaktiert werden) eine Anpassung vornimmt.

Angesichts zigfacher Austauschmöglichkeit (email,USB-Stick,WebDAV,scp..) wird es meines Erachtens noch bis zu 10 Jahre dauern bis dieses Problem nicht mehr auftritt.

Die zweite Sache die m.E. noch bis zu 5 Jahre problematisch sein kann sind 64bit Plattformen. Unter Linux Standard, da der Distributionsinstaller auf allen x64 Plattformen vorschlägt die 64bit Variante zu installieren. Das hat aber zur Folge, dass 3rd party Desktop Programme die nur als 32bit Version oftmals nicht installierbar sind, da die 32bit Bibliotheken fehlen. Auch beim selber kompilieren mit automake&friends gibt es hin und wieder Probleme, wenn man an zig Stellen redundant einen 32bit Flag setzen muss.

Unter Mac OS X wird das Problem mit Fat-binaries erschlagen die einfach immer alles mitbringen. Application+Libraries in 32/64bit ev. noch als Universal Binary.

Einfach für den User aber mittlerweile extrem Resourcenintensiv. Auf einem Apple Laptop mit ca. 100GB HD kann man davon ausgehen, dass Ruck-Zuck 50GB nur für die installieren Programme und das Betriebssystem draufgeht.

Der einfachste Ansatz zukünftig wäre alles nur noch 64bit – dass dauert aber noch und bringt derzeit auch noch Nachteile mit sich (64bit Pointer Overhead).

Manchmal erscheint es notwendig, einen alten Zeichensatz für eine bestimmte Aufgabe zu setzen. Die momentane Lokalisierung kann man einfach mit locale feststellen. Mit locale -a/-m kann man alle Namen der verfügbaren Lokalen/charmaps ausgeben.