Category: Linux

LINUX ⊆ UNIX

nvidia-settings und die Memory Anzeige

Auf einem MacBook Pro mit einer NVidia 8600M GT Karte die über 128MB VRAM verfügt zeigt das Linux Tool seltsamerweise immer 512MB an.

Auf der  NVIDIA 8600 Tech-Specs Seite kann man auch den Grund erfahren. Es handelt sich hierbei um NVIDIA® TurboCache™ Technology

Hierbei wird dem dezidiertem Videospeicher zusätzlich dynamisch Systemspeicher zugefügt. Man kann davon ausgehen, dass diese Technik nicht in den von Apple angepassten NVIDIA Treibern des MAC OS X Betriebssystem vorhanden ist.  Das würde dann auch die wesentlich bessere Performance der Graphikkarte unter Linux auf einem MacBook Pro erklären.

NVidia-Settings Snapshot

praxis tipps: netstat

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

Spiele Benchmark: Linux vs. Mac OS X

Wer ein MacBook Pro hat und darauf 3D Spiele spielt sollte den folgenden Beitrag definitv lesen!

Ich hatte schon seit längerem das Gefühl, dass 3D Anwendungen auf Linux mit den NVidia Treibern wesentlich besser laufen als auf Mac OS X. Das Gefühl musste jetzt mal gemessen werden und zwar mit dem Benchmark von X-Plane 8. Zuerst die Rahmenbedingungen:

  • MacBook Pro (Santa Rosa) Intel CoreDuo 2 2.2GHz, 2GB (PC5300), NVidia 8600M GT 128MB
  • Mac OS X 10.5.2 mit letzen Patches, TFT 1440×900 (24bit)
  • Linux 2.6.24, KDE 3.5.9, NVidia Treiber 169.12, TFT 1440×900 (24bit)
  • X-Plane 8.64, volle Auflösung, texture resoluton high, anti-alias level 2, alle Einstellungen synchron auf Mac OS X und Linux

gemessen wurde mit den Runstring –fps_test=123 (3 digit number bestimmt gewisse Grafikeinstellungen).
Unter Linux mit:

./X-Plane-i586 --fps_test=123

Unter Mac OS X:

/Applications/X-Plane\ 8.64/X-Plane\ 864.app/Contents/MacOS/X-Plane --fps_test=123

(Leider kann man unter Mac OS X keine Runstrings – ausser einem Dateinamen – dem open Kommando mitgeben)

Unter beiden Systeme wurde 3mal gemessen und dann gemittelt. Hier die Werte für die 3 Phasen die X-Plane ausgibt.

System Phase 1 [fps] Phase 2 [fps] Phase 3 [fps]
Mac OS X 4 9 9
Linux 8 33 34

Die Flugsimulation läuft tatsächlich mehr als 3mal schneller unter Linux! Sicherlich hängt es mit dem Treiber zusammen, welcher unter Mac OS X direkt mit dem Betriebssystem ausgeliefert wird, während unter Linux der Original NVidia Treiber installiert werden kann.
Dieser verfügt natürlich auch über eine Temperaturkontrolle die die Karte ab einem Threshold drosselt. Während des Benchmarkes fuhr NVidia’s PowerMizer sofort in den höchsten Performance Level 3 (470 MHz GPU,635 MHz VRAM).

Weiterhin fuhr ich auf diesem Rechner unter Linux noch den Benchmark von X2-The Threat:

Testlauf 1: 34.086 fps
Testlauf 2: 33.947 fps

Leider kann ich diese Werte nicht direkt vergleichen, da X2 auf Mac OS X nur auf PPC läuft. Die Werte erscheinen aber ebenso hervorragend, wenn man mal X2 auf einem PPC-Mac sieht.

kernel headers

Falls man einen selber gebackenen Kernel bootet und in dessen Umgebung arbeitet könnte man bei der Entwicklung gefahr laufen falsche header files zu inkludieren.

Zumindest in openSuSE 10.3 sind unterhalb von /usr/include folgende Unterordner nicht von glibc-devel sondern vom Paket linux-kernel-headers:

  • asm*
  • linux
  • mtd
  • rdma
  • sound
  • video

..und ev. weitere. Es bleibt einem nichts anderes übrig, als diesese Packet mit –nodeps (benötigt glibc-devel ab!) zu entfernen und alles von /usr/src/`uname -r`/include/* recursiv nach /usr/include zu kopieren

praxis tipps: iostat

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.

GTK-Qt Theme

Nach einem Gnome-Update auf 2.12 an einem SuSE Linux 10.1 Rechner mit primären KDE Desktop ging der Look der GTK Programme wieder baden (Firefox,Thunderbird,Adobe Reader usw..)

Auf der Konsole wurde das Problem schnell lokalisiert:

 Gtk-WARNING **: Unable to locate theme engine in module_path: "qtengine"

Das Problem kam offenkundig von der qtk-qt Theme Engine. Mit Hilfe dieses Programms kann das KDE Kontrollcenter das aktuelle Theme/Style des KDE Desktops für GTK mit Hilfe der dynamisch erzeugten Datei:

~/.gtk_qt_engine_rc

erzeugen. Leider ist diese Paket auf den SuSE Repositories nicht mehr auf dem aktuellen Stand. Das Projekt selber ist auf diese Seite umgezogen. Dort schreiben die Maintainer, das die aktuellen Versionen (>0.6) nur noch im SourceCode erhältlich sind. Also hab ich das SuSE rpm Paket (qtk-qt….) deinstalliert, das tarball (Version 0.8) gezogen und mit der auf der Webseite stehenden Anleitung installiert (cmake muss installiert sein). Nach einem SuSEconfig erscheint der Menüpunkt „GTK-Stile und Schriftarten“ wieder im Bereich „Erscheinungsbild“ im KDE Kontrollcenter – dort nochmals den Punkt „Use my KDE Style in GTK Applications“ angewählt und schon wieder sehen alle GTK Anwendungen bestens aus.

CalDAV

eMail gehört schon seit langem zu den selbstverständlichsten Dingen auf jedem Computer. Daneben wird aber ein zentraler Kalender immer mehr ebenso zu einer Selbstverständlichkeit, welche in der Implementierung im Netzwerk aber wesentlich problematischer ist.

Denn im Gegensatz zu den eMail Standards wie POP3/IMAP4 gab es bei der Kalenderverwaltung lange Zeit keinen (Industrie)Standard. Dies nutzte in erster Linie dem Platzhirschen Microsoft mit seiner Groupwarelösung Exchange Server / Outlook Client.

Tatsächlich ist das Produkt aber für viele Netzwerke ein Overkill, kostet doch etwas Geld und ist Clientseitig nur gut auf Windows nutzbar – äusserst dumm für ein UNIX zentriertes Netzwerk.

Seit März 2007 scheint gibt es aber für diesen Fall einen absoluten Exchange Killer

CalDAV / RFC 4791

Um was geht es dort:

  • CalDAV operiert aussschliesslich mit Daten im iCalendar Format (ics)
  • Im Gegensatz zum simplen ics over HTTP, kann CalDAV den Zugriff auf die Kalenderresourcen limitieren und greift molekular auf alle einzelnen Einträge in einem iCalendar zu
  • Diese Technik wird als Erweiterung von WebDAV implementiert.

Somit steht CalDAV in bester UNIX Tradition – keep it simple. Endlich lassen sich auf UNIX (aber auch Windows) Plattformen Kalenderinformationen beliebig austauschen und verwalten. Was folgt ist noch eine Auflistung der möglichen Clients und Server:

CalDAV Clients:
  • Mozilla Sunbird / Lightning (Thunderbird plugin)
  • iCal (ab Mac OS X 10.5)
  • Novell Evolution
  • KDE Kontact (wahrscheinlich ab KDE 4.1 )
CalDav Servers:

Java 1.6 Desktop-Performance

Tatsächlich wollte ein typisches Desktop Programm unter Linux das neueste Java 1.6 haben. Hab von SUN das JRE rpm package gezogen und installiert.

Zum ersten mal was das Feeling eines fetten Desktop Programmes analog zu einer nativen Anwendung. Alle Aktionen auf das User-Interface reagierten prompt ohne Verzögerung. Wäre schön wenn Java sich in diesen Performanceregionen etablieren könnte.

Die Schriften sehen jetzt auch einwandfrei aus – ein GTK Feeling kann ich allerdings noch nicht erkennen

(externe) iSight Kamera unter Linux (SuSE 10.1)

Bereits nach dem Einstecken in den FireWire Port ist die Kamera rudimentär erkannt. Im Linux Treiberbereich wurde ein zeichenorientiertes Device angelegt:
/dev/video1394-0
der Ordner
/dev/video1394
enthält einen Link auf die erste Datei, hat aber die Rechtemaske 0600 statt 0700, so dass hier ein Zugriffsfehler (kein Eintritt in das Directory) vorliegt. Diesen Mißstand (wahrscheinlich nur SuSE 10.1 spezifisch) muss man händisch beseitigen.

Wie komme ich zum Videobild? Das erste Problem ist schon das einschalten der Kamera. Unter Mac OS X wird Sie automatisch beim Zugriff eingeschaltet. Unter Linux brauche ich ein Programm, bspw coriander (package der Distribution)

Dieses (GUI-) Programm kann nicht nur die Kamera ein- und ausschalten, mittels

Services -> ISO Control: START
In diesem Bereich stllt man am Besten gleich die Auflösung 320×240 ein, die von den ganzen Kommunkationsprogrammen benötigt wird.

sondern auch die Auflösung einstellen und alle Anzeigewerte kalibrieren.
Messenger und VoIP Programme wie kopete und skype erwarten aber ein v4l device unter /dev/videoX (X als Ganzzahl)

Um das Video ieee1394 Device umzuleiten braucht man das Kernelmodul vloopback. Da dieses zumindest unter SuSE 10.1 nicht dabei ist, muss man die Quellen herunterladen und selberkompilieren (make;make install)

Danach muß man das Modul vloopback und videodev einladen – dauerhaft als Eintrag in MODULE_LOADED_ON_BOOT im Bereich sysconfig.

Danach geht man wieder ins das GUI Programm Coriander und drückt im Services Bereich den Knopf „Receive“ und „V4L“ um das Video Signal mittels vloopback in /dev/video0 einzuspeissen. Dieses Signal kann dann unter /dev/video1 von den Anwedungsprogrammen ausgelesen werden.

Lange Übergangszeiten bei Unicode und 64bit

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).