Monat: Februar 2014

Back to the future

Fraglos ist das Parlament als ‚Legislative‘ und als Körperschaft, in der Volksinteressen gesetzgeberisch Ausdruck finden sollten, gegenüber der ‚Exekutive‘ bis zur Bedeutungslosigkeit herabgesunken. Es ist nicht mehr in der Lage, selbständig Entscheidungen zu treffen, da es als Ganzes nicht mehr an den konkreten Vorbereitungen der Gesetze und an der Aufarbeitung des Materials beteiligt wird.

Auch im Parlament bilden sich oligarchische Zentren, die den größten Teil der Abgeordneten aus dem engeren Informationskreis ausschließen und so den Eintritt in den eigentlichen Entscheidungsmechanismus verwehren. …

Überall in der westlichen Welt kann – hinter der Fassade verfassungsmäßig ausgewogener Gewalten- und Kompetenztrennungen – eine weitgehende Symbiose der Parlamentsführung mit den Spitzen des Exekutivapparates beobachtet werden… Der ‚harte Kern‘ des Parlaments wird jedoch nicht entmachtet. Nicht alle Entscheidungen werden ‚anderswo‘ getroffen, da ein Teil der entscheidenden Gruppen wenn nicht als Parlament, so doch im Parlament wirkt. …

Und genau das ist für eine erfolgreiche Herrschaftsmethode unerlässlich: dass ein Teil der politischen und gesellschaftlichen Oligarchien sichtbar im Parlament tätig (also dem Schein nach öffentlich kontrollierbar), sichtbar vom Volke gewählt (damit zum Herrschaftsakt demokratisch legitimiert) und sichtbar Träger von Macht (und in der Lage, moralisch verpflichtende Wählerwünsche durchzusetzen) ist.

Wäre dem anders, würde die Bevölkerung sich gar nicht auf das parlamentarische Spiel einlassen, und sie würde die Wahlen nicht mehr als den wesentlichen Ausdruck ihrer politischen Freiheit betrachten. Mit einem Wort: erst die Präsenz der Macht im Parlament (und nicht etwa: die Macht des Parlaments) ermöglicht die Erfüllung der Aufgaben, die ihm als Organ (als Ganzem) zukommen.

Johannes Agnoli: Die Transformation der Demokratie  (1967)

Was die Softwareentwickler wohl rauchen…

Also manchmal verstehe ich es einfach nicht, was in den Köpfen von Softwareentwicklern vorgeht. Irgendwie dreht sich in den letzten Jahren alles um das Thema Tablet und Vereinfachung der Benutzeroberflächen. Das ist im ersten Augenblick auch in Ordnung, wenn man dem Benutzer die Möglichkeit lässt, sein Programm so einzurichten, wie er es mag. Aber genau diese Wahlmöglichkeit nehmen die Entwickler einem häufig, die Ergebnisse gleichen sich häufig erstaunlich, und von den Fehlern der Vorgänger lernen? Fehlanzeige!

In Second Life war das der unglückliche Viewer 2, sozusagen das Vista von Linden Lab. Außer Haus entwickelt, eine nette Idee, aber total katastrophal und mit vielem Zeug wie Webprofilen, die keiner wirklich braucht. Kein Wunder, dass Firestorm da wohl nach wie vor der Marktführer ist.

Oder im Bereich der freien Software muss man sich nur mal GNOME anschauen. GNOME war bis zur Version 2.X unter Linux der beliebteste Desktop, doch dann erschien im Herbst 2010 die Version 3.0. GNOME 3.0 war, kurz gesagt, ein völliger Umbau, der dem Benutzer viele Wahlmöglichkeiten nahm. Aber genau diesen Wegfall pries man dem Nutzer noch als Fortschritt an und GNOME 3.0 würde sicher gut funktionieren, wenn es denn ein GNOME-Tablet geben würde. Das gibt es aber bis heute nicht, die Hauptanzahl seiner Benutzer sind nach wie vor klassische Desktopmausschubser und für die war GNOME 3.0 ein sofortiges Hassobjekt. Davon hat sich GNOME bis heute nicht erholt, die Benutzer verließen scharenweise das sinkende Schiff und selbst Debian hat GNOME als Standarddesktop rausgeworfen.

Dazu kam, dass mit Cinnamon und Mate zwei Forks entstanden, die auf unterschiedlicher Grundlage die althergebrachte Desktopmetapher weiter sponnen. Diese erhielten massiv Zulauf und GNOME selber hat Schadensbegrenzung betrieben, aber ist inzwischen in einem Zustand, dass es nur noch wenige benutzen dürften. Das Internet ist jedenfalls voll mit Postings Marke „GNOME 3 sucks“, und das zu Recht. Canonical hat mit Unity daher inzwischen auch seinen eigenen Desktop im Bau.

Microsoft wiederholte haargenau denselben Fehler mit Windows 8: man stülpte dem Desktop eine Tabletoberfläche über und entsorgte den Desktop. Nur machte das bei Microsoft noch Sinn, weil eben die auch wirklich Windows-Tablets herstellen. Dennoch ist auch hier Microsoft seit dem Erscheinen nur noch am Zurückrudern, den Startknopf gibt es inzwischen wieder, in Bälde soll man auch die Kacheloptik ganz auf dem PC abschalten können. Warum wohl trotz inzwischen 200 Millionen verkaufter Lizenzen? Ganz einfach weil kaum eine Firma Windows 8 bei sich einsetzen will, daher.

PS: wer meint, Apple sei da wirklich besser, der solle sich nur einfach einmal in Ruhe anschauen, was denn Apple in Mac OS X 10.7 mit dem Rollbalken verzapft hat. Mit 10.8 haben sie dann nachgebessert.

Die Beschleunigung des Viewer-Caches

Eines der Nadelöhre in der Architektur jedes Second Life Viewers ist sein Cache auf der Festplatte. In dem Cache legt der Viewer sowohl die dargestellten Texturen als auch der Objekte einer Sim ab. Klingt erst einmal nicht dramatisch, aber das hat seine Konsequenzen, die in der Natur der Festplatte liegen.

Nun ist es so, dass die meisten Texturen abgelegt auf der Festplatte für sich alleine nicht viel Speicherplatz benötigen. Ein typischer Cache-Ordner besteht aus 10000-30000 Dateien. Es sind eben pro Sim schon sehr viele Texturen, die ihren Weg auf die Festplatte finden, und damit greift dann letzten Endes die Festplatte als Nadelöhr.

Jedes moderne Betriebssystem ist sich der Tatsache, dass der Zugriff auf die Festplatte um Längen langsamer als auf den Hauptspeicher ist, bewusst. Deswegen nutzt jedes Betriebssystem automatisch den nicht durch Programme genutzten Teil des Hauptspeichers als Schreib-Lese-Cache. Das bedeutet, dass Schreibzugriffe auf die Festplatte zeitverzögert stattfinden und vorher noch vom System optimiert werden, sowie oft benötigte Dateien möglichst lange im Hauptspeicher gehalten werden. Fordert ein Programm eine solche Datei an, dann wird erst geschaut, ob sie im Cache vorliegt und wenn ja (das nennt man dann einen Hit), wird sie direkt aus dem Cache geliefert und nicht von der Festplatte gelesen. So weit, so gut.

Was aber passiert, wenn wir den Rechner gerade erst gestartet haben, dabei noch nicht in Second Life waren und einen recht gut gefüllten Viewercache haben? Dann bleibt dem System nichts anderes übrig, als alle diese Texturen nacheinander von der Festplatte zu lesen. Und da dies schon auf einer normalen Sim, auf der man sich bewegt und ein normales Blickfeld hat, durchaus mehrere Hundert Stück sein können, dauert das dann eine Weile.

Wieso kommt dies so? Ganz einfach daher, weil hier nun die mechanischen Beschränkungen einer Festplatte greifen. Die Leistungsfähigkeit einer modernen Festplatte wird an zwei Kennziffern gemessen, nämlich der maximale Schreib-/Lesedurchsatz sowie die Zugriffszeit. Die Zugriffszeit ist dabei der Zeitraum, den die Festplatte im Schnitt benötigt, um den Schreib-Lese-Kopf auf den Anfang der gewünschten Datei zu positionieren. Diesen Vorgang nennt man übrigens auch Seek. Typischerweise wird diese Zeit in Millisekunden gemessen, und eine moderne Festplatte hat eine Zugriffszeit im Bereich von irgendwo 5-10 ms. Dabei gilt natürlich die Devise: je niedriger die Zugriffszeit, desto besser. Eine gewisse Zugriffszeit aber wird man mit Festplatten niemals unterschreiten können.

So. Was bedeutet das? Wenn wir neu einloggen auf irgendeine Sim, dann will der Viewer aus einem gut gefüllten Cache einen Haufen an Texturen von der Festplatte lesen. Das bedeutet, dass es innerhalb kurzer Zeit zu einem Haufen an Seeks kommt, die die Festplatte abarbeiten muss.

Und hier nun eine einfache Rechnung: wieviel Seeks pro Sekunde schafft eine Festplatte maximal? 1 Sekunde sind 1000 Millisekunden, also meinetwegen 1000 ms / 8 ms = 125 Seeks/Sekunde. A-ha, damit kommen wir der Sache dann nämlich schon näher. Und sollte die Festplatte meinetwegen 6 ms Zugriffszeit haben, dann kommen wir da auf 1000 ms / 6 ms = 167 Seeks/Sekunde, was auch nicht wirklich besser ist.

Wenn wir uns dann noch klar machen, dass die Festplatte meist nicht nur von Second Life alleine benutzt wird, sondern zeitgleich auch andere Programme sie benutzen, dann wird einem klar, dass der Viewer längst nicht immer die theoretisch maximal mögliche Anzahl an Seeks pro Sekunde für sich alleine zur Verfügung haben wird.

Mit anderen Worten: die Festplatte ist in der Regel für den Anwendungsfall gut gefüllter Cache, neu gestartetes System und man loggt mit dem Viewer gerade ein, das Nadelöhr. Der Prozessor könnte mehr leisten, aber er kann es eben nicht, weil er auf die Festplatte warten muss und das ist schlecht.

Wenn man den Viewer-Cache für den obigen Fallo also beschleunigen will, dann muss man dafür sorgen, dass die Anzahl an Seeks pro Sekunde erhöht wird. Klingt einfach und ist es auch eigentlich, denn man könnte ja anstelle einer Festplatte eine billige Solid State Disk (SSD) im Rechner einbauen und den Viewercache darauf speichern. SSDs sind für solche Anwendungsfälle, also Ordnerstrukturen mit tausenden, kleinen Dateien, gerade zu ideal. Eine SSD hat keinerlei bewegliche Teile und ihre Zugriffszeit ist in der Regel um den Faktor 100 besser als einer Festplatte.

Die Zugriffszeit einer SSD beim Lesen liegt so im Bereich von 0,05 bis 0,08 Millisekunden. Einfache Rechnung also: 1000 ms / 0,07 ms = 14285 Seeks/Sekunden. Und selbst günstige SSDs sind nur unwesentlich langsamer. Das bedeutet klar, dass eine SSD ganz einfach das Speichermedium der Wahl für solche Anwendungsfälle ist.

Wenn man aber keine SSD hat oder erwerben will, dann kann man dennoch seinen Rechner beschleunigen. Voraussetzung dafür ist, dass man mindestens zwei Festplatten im Rechner installiert hat. Moderne Betriebssyssteme haben die Möglichkeit, zwei Festplatten oder zwei gleich große Partitionen auf zwei verschiedenen Festplatten zu einem sog. Stripe-Set  zusammenzufassen. Die Anwendung sieht nur ein Laufwerk in der Größe der beiden Partitionen zusammengerechnet, in Wirklichkeit aber handelt es sich dabei um diese beiden Festplatten, die das Betriebssystem als eine ansteuert.

Dabei verteilt das Betriebssystem nun Schreib-/Lesezugriffe möglichst gleich zwischen beiden Festplatten, ebenso die Dateien. Dies hat den Vorteil, dass ein Stripeset umso schneller wird, auf je mehr Festplatten es angelegt ist, denn die Zahl der Seeks pro Festplatte addiert sich (d.h. ein Set auf zwei Platten erreicht theoretisch bei 8 ms Zugriffszeit je Platte eben maximal 125 * 2 = 250 Seeks/s, bei 3 Platten 125 * 3 = 375 Seeks/s usw.), allerdings bietet es absolut keine Sicherheit für die darauf befindlichen Dateien. Geht eine Platte kaputt, dann ist das komplette Set unbrauchbar.

Das aber macht im Falle des Viewercaches absolut nichts aus, da dies ohnehin nur ein temporärer Zwischenspeicher ist, der jederzeit erneuert werden kann. Sollte man also beispielsweise unter Windows mehr als eine Festplatte im Rechner verbaut haben, dann kann sich der Aufbau eines Stripesets für den Viewercache durchaus lohnen, denn es bringt einem ohne Mehrkosten einen spürbaren Leistungsgewinn.

Eine Anleitung, wie man unter Windows 7 solch eine Konfiguration aufbaut, findet sich hier. Dabei ist wie immer zu beachten, dass man besser weiß, was man tut, denn man arbeitet an der Festplattenpartitionierung und ein falscher Handgriff kann da schlimmstenfalls Datenverlust nach sich ziehen. Also Vorsicht.