SSDs und der Viewercache

Ich hatte neulich in der SL-Gruppe „slinfo.de“ eine Diskussion darüber, wie man Computer beschleunigen kann, die den Second Life Viewer benutzen. Neben den üblichen Verdächtigen, in Reihenfolge der Wichtigkeit: Grafikkarte, mehr Hauptspeicher, besserer Prozessor – empfahl ich den Einbau einer kleinen SSD, um darauf den Viewer-Cache zu speichern.

Der Grund liegt einfach darin, dass der Viewercache bei 1 GB typischerweise aus ca. 20.000 Dateien besteht und man bei dem Cache nach einem Neustart, wenn man in Second Life einloggt und auf eine seiner Stammsims geht, die Limitierung der Festplatte merkt.

Eine Festplatte hat nunmal typischerweise eine Zugriffszeit von 6-8 ms, eine Sekunde sind 1000 ms, das bedeutet wenn die Festplatte exklusiv nur für den Viewer arbeitet (was sie normal nicht macht), dann schafft sie es in einer Sekunde im Bestfall 1000/8 = 125 verschiedene Texturen zu laden.

Eine SSD ist mindestens um den Faktor 10 schneller und damit für solch ein Konstrukt wie lesende Zugriffe auf einen vollen Cache nunmal die erste Wahl.

Nun hält sich noch immer hartnäckig das Gerücht, dass SSDs ach so empfindlich seien und dann kam auch sofort wieder der Mist auf, wenn man das täte, wäre die SSD nach 1-2 Jahren kaputt. Nein, wäre sie nicht.

Zuerst einmal ist es so, dass auch mechanische Festplatten mit der Zeit kaputt gehen können und im Schnitt eine Lebensdauer von fünf Jahren haben. Bei SSDs ist es so, dass diese mit jedem Schreibzugriff bauartbedingt ein wenig altert.

Bei Tech Report wollte man es mal genau wissen und beschreibt verschiedene, aktuelle SSDs seit Monaten im Dauereinsatz. Das Ergebnis ist, kurz gesagt, dass eine SSD robuster ist, als viele denken und diese Datenmengen, welche da geschrieben worden sind, ein typischer Durchschnittsbenutzer wohl in 30-35 Jahren erreicht. Wenn man nur den Second Life Viewer Cache auf eine SSD packt, dann dauert das gar noch viel länger.

Von dem Argument mit der viel zu kurzen Lebensdauer einer SSD in einem solchen Fall ist daher absolut nichts mehr zu halten, es zeigt nur, dass derjenige, der es vorbringt, einfach keine Ahnung von modernen SSDs hat.

Leap Motion in Aktion

Bei all dem Gerede über Oculus Rift ist mir bisher eine Technologie weniger aufgefallen, die einfacher einzusetzen ist und auch die Handhabung eines Rechners ordentlich auf den Kopf stellt, nämlich Leap Motion.

Nun, was ist das? Einige mögen vielleicht Kinect von der Xbox kennen, eine Sensorphalanx, mit der man seine Xbox einfach per Körperbewegungen steuern kann. Nun stellen wir uns mal diese Sensoren ordentlich verkleinert und in einer Computertastatur eingebaut, dann haben wir Leap Motion. Es ist im Grunde der Computersteuerung sehr ähnlich, die manche im Scifi-Film „Minority Report“ sahen, nur mit dem Unterschied, dass man dazu keine Handschuhe anziehen muss und die Technik bereits heute verfügbar ist und gerade damit angefangen wird, sie in manchen Notebooks serienmäßig einzubauen.

Ein Video sagt mehr als tausend Worte, und es gibt schon seit über einem Jahr im Second Life Viewer von Linden Lab eine eingebaute Unterstützung für Leap Motion. So sieht das dann eben aus:

Ich kann mir vorstellen, dies ist für Leute, die hauptsächlich gerne per Voice unterwegs sind, sehr praktisch.

Man kann den Controller auch einzeln kaufen, er wird dann per USB an den Rechner gesteckt und ist in etwa so groß wie ein Feuerzeug. Windows steuern kann man damit übrigens auch:

Bitcoin – blablabla

Bitcoin ist ja gerade ein Hype, wie er im Buche steht und das wird momentan immer schlimmer. Angeblich zittern ganze Staaten vor dieser digitalen Wunderwährung, die sie nicht kontrollieren können und was weiß ich noch alles. Alles Käse – Bitcoin ist ein interessantes Experiment ohne besonders praktischen Wert, nicht mehr, aber auch nicht weniger.

Doch was ist Bitcoin eigentlich? Zum einen eine nach oben hin künstlich gedeckelte digitale „Währung“, zum anderen ein verteiltes Finanztransaktionsprotokoll im Bereich Micropayments. Die Transaktionen sind dabei der eigentlich interessante Teil, denn für so etwas gibt es nun wirklich Bedarf und hier ist ein Weg gezeigt worden, wie das geht. Die Frage dabei ist natürlich, wie gut das für zig Millionen skalieren würde, das wäre vermutlich ein Desaster.

Die Währung dagegen ist ein astreiner Fehlschlag. Bitcoin hat eine eingebaute Deflation, weil die maximale Geldmenge künstlich gedeckelt ist. Warum heute eine Ware für 1 Bitcoin kaufen, wenn man sie in vier Wochen auch für 0,50 Bitcoins bekommen könnte? Also hocken viele lieber auf ihren Coins, anstelle sie auszugeben.

Und überhaupt Geld: eine Währung lebt davon, dass ihr Wert recht stabil ist, fluktuiert und ausgegeben wird. Der Wert von Bitcoins bemisst sich einzig und alleine darüber in Wirklichkeit, wieviel echte Dollars und anderes man bereit ist zu bezahlen. Für den eigentlichen, angeblichen Nutzungszweck – als Währung – werden Bitcoins kaum genutzt. Bitcoins sind vielmehr ein astreines Spekulationsobjekt geworden und wenn man sich mal den Werteverlauf der Bitcoins anschaut, dann wird einem auch klar, dass dem so ist und mit so etwas kaum ein vernünftiger Mensch Sachen bezahlen würde noch Zahlungen annehmen würde.

Und ein Spekulationsobjekt, bei dem die Early Adopters recht einfach eine nette Menge anhäufen konnten, die sie nun teuer verkloppen könnten, ja das sind sie durchaus. Alles, was nun Bitcoins mined, wird es immer schwerer haben, noch einen einzigen Coin zu minen als früher. Und bei knapp 22 Millionen, also irgendwann um 2020 rum, wird damit Schluss sein. Es ist eine gigantische Umweltverschmutzung und Energieverschwendung für nichts und aber auch wieder nichts.

Und Bitcoins können unwiederbringlich verloren gehen – dazu reicht es schon aus, wenn die Festplatte mit der Wallet abraucht und man kein Backup hat. Diese Coins sieht man nie wieder und stehen auch dem Rest nie mehr zur Verfügung.

Kurz und gut es ist ein interessantes Experiment, eine Spekulationsblase allererster Güte ohne wirklich praktischen Nutzen, aber auch ein Anfang. Hoffentlich lernen spätere Ansätze dieser Art aus den Fehlern bei Bitcoin und machen es besser. Denn gut ist Bitcoin nun wirklich nicht, bestenfalls gut gemeint, das ist aber auch alles.

Firestorm Viewer Private Build Nr. 4.5.2.39868 zum Download verfügbar

Mir ist gerade ein wenig langweilig und daher dachte ich mir, ich könnte ja mal der Community einen möglicherweise kleinen Dienst erweisen – und das mache ich nun.

Ohne weiteren Umschweife: ab sofort biete ich nun einen sog. aktuellen Nightly Build vom Firestorm für Windows (32 bit) zum Download an. Nun wo das raus ist, der Reihe nach.

F: Was ist ein Nightly Build?
A: Ein Nightly Build ist eine möglicherweise lauffähige Version des Firestorm Viewers, die auf dem aktuellen Sourcecoderepository des Entwicklersteams beruht.

F: Auf welchem Quellcode basiert dieser Viewer?
A: Er basiert auf dem unter http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/ öffentlich verfügbaren Code. Er wurde mit Hilfe von Microsoft Visual C++ Express 2010 kompiliert und es handelt sich dabei um die 32bit-Variante des Viewers.

F: Gibt das Firestormteam nicht selber Nightly Builds heraus?
A: Nein, das haben sie noch nie.

F: Warum bietet das Firestormteam nicht selber einen Nightly Build zum Download an? Andere Viewer, wie beispielsweise Singularity, machen das doch auch!
A: Es ist keine Frage des Könnens, sondern des Wollens. Das Entwicklerteam vom Firestormteam will keine solchen Builds veröffentlichen. Wer es genau wissen will, der kann es unter http://modemworld.wordpress.com/2013/02/19/firestorm-meeting-13th-february-2013-video-and-transcript/7/ auf Englisch nachlesen. Jessica Lyon begründet es mit mangelnder Qualitätskontrolle. Nightly Builds sind das, was man auf Englisch als das Bleeding Edge bezeichnet. Es handelt sich dabei von der Qualität her nicht einmal um Alphaversionen. Ein Nightly Build kann funktionieren, muss aber nicht, und keiner wird garantieren, dass alle Funktionen richtig oder fehlerfrei funktionieren und man muss schlimmstenfalls auch mit Fehlern rechnen, die Datenverlust nach sich ziehen könnten.

Wer einen Nightly Build benutzt, der muss sich dieser Gefahr sicher sein, dass er auf eigenes Risiko handelt und keinerlei Support bekommen wird. Offensichtlich gehen die Firestormentwickler davon aus, dass die Benutzer dazu einfach in der Masse unfähig sind und daher veröffentlichen sie keine Nightly Builds.

F: Warum veröffentlichst du dann einen Nightly Build, wenn die Firestormentwickler selbst es nicht tun?
A: Weil ich es kann! Und weil das letzte Release von Firestorm von Oktober 2013 ist, und – seien wir da mal ehrlich – einfach nur schnarchlangsam rezzed. Ich persönlich benutze den Bleeding Edge selbst schon seit einiger Zeit und bin der Meinung, die bald vier Monate seit dem letzten Release machen sich durchaus bemerkbar.

Außerdem bin ich der Meinung, dass es ein Fehler des Firestormprojektes ist, bewusst keine Nightly Builds zur Verfügung zu stellen. Andere Viewer fahren sehr gut damit, und getreu dem Motto „Release early, release often“ stelle ich nun diese Kompilate zur Nutzung auf eigene Gefahr hin der Allgemeinheit zur Verfügung, weil einfach nicht jeder fähig ist, sich selbest eine Buildumgebung zu bauen und es selbst zu kompilieren. Das füllt damit eine Lücke.

F: Darfst du das denn veröffentlichen? Und was ist, wenn es den Firestormentwicklern nicht gefällt?
A: Ja, sicher darf ich das veröffentlichen. Der Viewer unterliegt einer Opensourcelizenz, der Quellcode ist ebenfalls verfügbar und wenn ich daraus kompilierte Binaries verteilen will, dann kann, darf und werde ich das tun, solange nicht proprietäre Bibliotheken wie von Kakadu mit dabei sind. Und wenn es den Firestormentwicklern mißfällt, dann können sie nicht viel mehr dagegen tun, als ihre Mißbilligung auszudrücken. Denn es ist absolut nichts illegales.

F: Ich vertraue dir nicht!
A: Schön, das musst du auch nicht. Eine gesunde Paranoia ist sogar besser. Nur wenn du mir nicht vertraust, dann benutze auch besser das Programm erst gar nicht, sondern besorge es selber aus einer anderen Quelle oder baue es einfach selber.

F: Mit welchen Einstellungen ist das Programm kompiliert?
A: Es benutzt als Grafikbibliothek OpenJPEG und ist mit Opensimulatorunterstützung kompiliert. Dies entspricht der Autobuild-Konfiguration ReleaseFS_open.

F: Kannst du nicht noch X, Y oder Z ins Programm kompilieren? Kannst du nicht noch X, Y oder Z für mich machen?
A: Nein! Kein Support, keine Unterstützung für Sonderwünsche. Entweder das Programm ist so, wie es vorliegt, für dich brauchbar, oder eben nicht. Ich habe nicht die Zeit dazu, auf solche Wünsche eingehen zu können!

F: Was kann das Ding, was fehlt?
A: Das Ding kann alle Grundfunktionen, die Firestorm eben auch kann. Fehlen tun u.a. fortgeschrittene Baufunktionen, wie beispielsweise Havok. Erwartet alles, nur keinen stabilen Betrieb oder eine vollständige Funktionalität wie im offiziellen Lindenviewer! Dieser Viewer ist eine Baustelle, und das merkt man auch mitunter!

F: Ist es gefahrlos möglich, mit dem Ding auf dem Second Life Grid zu arbeiten?
A: Im Zweifelsfalle: nein. Es handelt sich hierbei um eine Version, die offiziell mit Opensimunterstützung arbeitet und für Opensim gedacht ist. Das bedeutet, dass höchstwahrscheinlich viewerseitige Einschränkungen, die Linden Lab von Second Life Viewern fordert, in dieser Version abgeschaltet sind. Daher rate ich von einer Benutzung des Programms auf dem Second Life Grid ab.

F: Ist das hier nicht dein eigenes Viewerprojekt?
A: Nein. Es wäre mein eigenes Viewerprojekt, wenn ich Änderungen am Code vornehmen würde oder bereits vorgenommen hätte. Das aber habe ich nicht getan. Ich habe einzig und alleine den öffentlich zugänglichen Viewerquellcode unverändert genommen und kompiliert.

Rechtliche Hinweise
Ich biete keinerlei Support! Weder für den Firestormviewer an sich, noch für das kompilierte Programm oder beides. Ich stelle das Kompilat so zur Verfügung, wie es ist, nicht mehr und nicht weniger.. Weder bin ich ein Entwickler noch ein Mitarbeiter des Firestormentwicklerteams, sondern agiere von ihnen unabhängig und damit eigenständig!

Ich weise ausdrücklich darauf hin, dass es sich bei diesem Kompilat um eine Version handelt, deren Qualität noch vor Alpha ist. Das bedeutet, dass das Kompilat unvollständig sein kann, schwere Fehler enthalten kann und schlimmstenfalls Datenverlust nach sich ziehen kann. Ich gebe keinerlei Gewährleistung auf das Kompilat noch hafte ich für mögliche Schäden, die durch seine Nutzung entstehen könnten!

Ich erkläre, dass ich beim Kompilieren ausschließlich die öffentlichen Quellen unter http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/ verwandt habe, und den Code in keinster Weise modifiziert habe. Ich erkläre, dass ich dem Setupprogramm weder Trojaner, Keylogger oder andere Schadprogramme beigefügt habe und es zum Zeitpunkt des Uploads vorher auf Virenbefall überprüft habe.

Weiterhin weise ich ausdrücklich darauf hin, dass es sich hierbei um eine Version handelt, die für Opensimulator gedacht ist! Die Benutzung dieser Version auf dem Second Life Grid kann schlimmstenfalls den Verlust des Zugangs nach sich ziehen!

Kurz und gut: ich übernehme keine Haftung – für gar nichts, weder für Datenverlust, möglichen Schäden an der Hardware noch den möglichen Verlust des Second Life Zugangs oder falls der Viewer deinen Kaffee verschüttet! Die Nutzung des Programms geschieht ausschließlich und ausdrücklich auf eigene Gefahr hin! Wer das Programm nutzt, der ist sich dieser Sache bewusst und erklärt sich damit einverstanden!

Nichts destotrotz freue ich mich natürlich über Kommentare. Und hier geht es zum Download: https://drive.google.com/file/d/0B_BpSLqaUY_dUlBPby0yYk5qVmM/edit?usp=sharing

„Das neue Second Life – Jetzt noch schärfer und endlich in HD dank 64 bit!“

Ich habe heute in irgendeinem Kanal in Second Life – welcher, spielt keine Rolle – interessante Neuigkeiten über den Firestormviewer (oder war es der normale? Egal!) gehört.

Und das ging so: der Viewer käme bald in 64bit raus, und dann würden endlich die Texturen in HD rendern und viel klarer zu sehen sein als bisher. Ja holla, so viel Schwachsinn kreativer Wissensdrang auf einem Haufen war dann doch schon ein wenig zu viel, da musste ich dann einfach dagegen halten.

Zunächst mal bedeutet 64bit-Viewer nichts anderes, als dass der Viewerprozess mehr Speicher als bisher adressieren kann und es ggf. auch ein wenig flotter läuft. Aber was bedeutet es für die Grafik? Die Bilder in Second Life sind allesamt im Format JPEG2000 gespeichert. Die offiziellen Viewer benutzen dabei die Bibliothek dazu von der Firma Kakadu, manch anderer Openjpeg.

Die Bildkomprimierung in Second Life ist dabei verlustbehaftet, reversibel und vor allem qualitätstreu. Sprich, wenn man ein Bild einmal komprimiert hat und es mit derselben Routine tausend Mal dekomprimiert, dann kommt dabei immer wieder genau dasselbe Bild heraus. So und nicht anders arbeiten nun einmal Computer, sie sind berechenbar. Ob dabei die Routine in 32bit oder 64bit läuft, spielt dabei keine Rolle, die Qualität ist dabei absolut dieselbe.

Dann meinten sie da noch, man könnte in Second Life Texturen mit der Dimensionierung 2048×2048 speichern und benutzen. Früher ging das wegen eines Fehlers in der Tat, dass sich solche Monstertexturen im Assetserver ablegen ließen, aber das ist schon seit Jahren vorbei.

Niemand wird einen daran hindern, eine Textur mit 2048×2048 Pixeln uploaden zu wollen; das klappt auch. Nur: bevor diese Monstertextur gespeichert wird, skaliert das System sie zuerst automatisch auf 1024×1024 Pixel herab und speichert dann diese runter skalierte Größe im Assetserver.

Und das ist auch besser so, denn solche Monstertexturen braucht kein Mensch und solange der Viewer sich weigert, auch bei Grafikkarten mit 2 GB VRAM mehr als 512 MB VRAM zu benutzen, ist das einfach nur unnötige Speicherverschwendung.

Mein Wochenendprojekt: ich bastele mir einen Firestorm unter Windows

Da der offizielle Firestorm unter Windows momentan lahm ist wie Sau und dafür meine eigens aus dem Sourcecoderepository kompilierte unter Linux rennt wie Sau, baue ich mir heute mal unter Windows selbst eine aus dem aktuellen Code.

Das dauert ein wenig, da man erst einmal ja die gesamte Infrastruktur dafür runter laden und installieren muss (Compiler, Header, Utilities usw.), aber kostet außer Zeit ansonsten nichts, da alles ja umsonst verfügbar ist. Auf das Ergebnis bin ich jedenfalls sehr gespannt und werde dann darüber mal berichten.

Microsoft verlängert Verkauf von Windows 7

Habt ihr es bemerkt? Nach dem ursprünglichen Plan von Microsoft hätte Windows 7 bereits ab Ende Oktober 2013 nicht mehr verkauft werden sollen. Aber im Gegensatz zum ursprünglichen Plan kann man die Retail-Lizenzen nach wie vor verkaufen und das Ende der Lebenszeit ist „to be determined“, also sie denken nun darüber nach, wann es offiziell der Fall sein wird.

Anders gesagt: Microsoft hat damit endlich eingesehen, dass Windows 8 Schrott ist und dies keiner wirklich haben will. Da ab April 2014 der Support für Windows XP endet, stehen nun langsam viele Firmen vor dem Problem, auf welches Windows sie umsteigen sollen. Windows XP hat schließlich schlappe 13 Jahre gehalten und damit viel länger, als ursprünglich geplant und gedacht.

Alle Firmen jedenfalls, die ich persönlich kenne, wollen dabei auf Windows 7 umsteigen. Windows 8 ist ihnen zu zappelig, krank zu bedienen und fremdartig. Windows 7 hat damit beim momentanen Stand der Dinge das Zeug zum neuen Ewig-Windows und wird damit ziemlich sicher nun Windows XP ablösen. Endlich hat auch Microsoft das eingesehen, bleibt nur zu hoffen, dass Windows 9 wieder besser werden wird.

Kleiner Exkurs: Dateisysteme unter Linux

Einfach mal so, gerade weil mir danach ist, ein kleiner Exkurs zum Thema „Dateisysteme unter Linux.“ Das sind die Arbeitspferde, die im Hintergrund eines Betriebssystems hoffentlich unbeachtet ihren Dienst tun. Sollten sie mucken, dann ist es wie Zahnschmerz: besser, man hat ihn nicht.

Zunächst einmal: was ist ein Dateisystem? Das ist eine Ablageorganisation für Dateien auf einem Datenträger (Festplatte, Bandlaufwerk, CD-Rom, Diskette…) des Computers. Es ist eine Abstraktionsschicht zwischen der Hard- und der Software: Dateien/Ordner müssen angelegt, umbenannt und gelöscht werden können. Die Dateien können dabei von sehr klein (einige wenige Bytes) bis sehr groß (mehrere Gigabyte und mehr wie bei Videos) im selben Dateisystem schwanken. Für unterschiedliche Einsatzzwecke gibt es dabei unterschiedliche Systeme.

Linux als quelloffenes Betriebssystem kommt dabei, im Unterschied zu Windows das im Grunde nur mit NTFS arbeitet, von Hause aus mit einer Myriade an unterschiedlichen Systemen daher. Hier nun in einigermaßen chronologischer, kurzer Auflistung die Wichtigsten.

ext2

ext2, die Abkürzung für Extended Filesystem 2, war lange Zeit der Betriebssystemstandard von Linux. Der Vorgänger war ext, welches sich wiederum an UFS von BSD orientierte. Im Grunde ist es inzwischen veraltet, da es maximal 16 TB als Dateisystemgröße erlaubt, was heutzutage schnell erreicht ist und kein Journaling (dazu später mehr) erlaubt.

Aber es ist ein robustes System und wird für diverse Zwecke, wie Bootpartitionen, nach wie vor gerne benutzt.

ReiserFS

Dieses System wurde von Hans Reiser entwickelt und brach mit etlichen Dingen. Es verwendete intern Bäume und war das erste System, welches ein brauchbares Journaling benutzte. Journaling war und ist die Antwort auf das Problem eines Stromausfalls. Setzte dieser ein, so musste beim anschließenden Dateisystemcheck bei ext2 die komplette Festplatte überprüft werden. Anfangs war das kein Problem, als dann aber die Platten zu Gigabytegröße und mehr anschwellten, wurde es das, denn der Check konnte so schlimmstenfalls einen stundenlangen Ausfall bedeuten, den man sich nicht leisten konnte oder wollte.

Journaling bedeutet dabei, dass das Dateisystem jedwede Änderung zuerst in ein Journal, im Grunde ein Transaktionslogbuch, schreibt und dann auf die Platte. Kommt es also zu einem Stromausfall, dann muss man nur noch das Journal verifizieren und hat danach wieder ein Dateisystem in einem konsistentem Zustand. Das dauert im Vergleich zu Dateisystemen ohne Journal höchstens wenige Minuten, dazu recht unabhängig von der Größe des Dateisystems. Ein Schutz vor Datenverlust ist aber auch das nicht, den bietet nur ein anständiges Backup. Das Journal ist nur dafür da, den Check deutlich zu beschleunigen.

ReiserFS Version 3 ist inzwischen in die Jahre gekommen und Reiser arbeitete danach an der Mutter aller Dateisysteme, ReiserFS 4. Dazwischen kam ihm allerdings, dass er seine Frau ermordete und man ihn dafür ins Gefängnis warf. Ein ehemaliger Mitarbeiter übernahm die Entwicklung, und während das System noch immer einige, wenige lautstarke Fans hat, so ist im Grunde vom Produktiveinsatz aller Reiserdateisysteme inzwischen abzuraten.

ext3

Dies ist eine Weiterentwicklung von ext2. Die Dateisystemgröße wuchs auf 32 Terabyte an, man spendierte dem System ein Journal und einen schnelleren Mechanismus, Dateien in Verzeichnissen anzuzeigen. Aber auch dies ist in die Jahre gekommen, aber es ist zu ext2 vom On-Disk-Format her weitgehend kompatibel.

ext4

Die Weiterentwicklung von ext3 und der aktuelle Stand, was diese Systeme anbelangt. Dies wird von vielen Distributionen nach wie vor als Standarddateisystem eingesetzt. Das Journal wurde verbessert, die Geschwindigkeit erhöht und die Dateisystemgröße ordentlich aufgemotzt, so dass diese momentan bei einem Exabyte liegt. Auch wie hier gilt: ältere Partitionen von ext2 oder ext3 können von dem System eingehängt werden, nach unten ist es nicht wirklich kompatibel.

Es ist ein robustes Dateisystem und wenn man nichts falsch machen will, dann greift man dazu, so schnell wird dieses nicht mehr veraltet sein.

JFS

JFS ist ein Dateisytem, welches ursprünglich von IBM 1990 für AIX entwickelt worden ist und steht dabei ganz einfach für Journale File System. Von den Eigenschaften her mit ext4 vergleichbar, aber fristet im Einsatz mehr ein Schattendasein.

XFS

XFS wurde 1994 von Silicon Graphics Inc. für deren eigenes Unix-Derivat entwickelt und später auf den Linux-Kernel portiert. Auch dies ist von den Features her mit ext4 vergleichbar, aber es ist eines der wenigen Dateisysteme, welches beispielsweise unter Linux eine garantierte Lese/Schreibleitung liefern kann, was beispielsweise für Videostreamingserver wichtig ist. Das System wurde dabei auf höchstmögliche Leistung getrimmt. Es ist ein stabiles, ausgereiftes Dateisystem.

Btrfs

Btrfs ist ein noch in der Entwicklung befindliches Dateisystem, welches eines Tages das Standarddateisystem von Linux sein könnte. Es wurde ursprünglich von Chris Mason, damals angestellt bei Oracle, eingeführt und die Features lesen sich dabei wie eine Kopie von ZFS von damals Sun. Btrfs ist ein sog. Copy-on-Write-Dateisystem, was bedeutet, wenn Dateien geschrieben werden, werden die alten Blöcke nicht überschrieben, sondern freie Stellen dafür genutzt und erst dann die alten frei gegeben. Es versieht jede Datei mit einer Prüfsumme, man kann es im laufenden Betrieb vergrößern oder verkleinern, Platten ein- oder aushängen und vieles mehr. Inzwischen wurde Sun von Oracle aufgekauft und Mason ist nun bei einer anderen Firma namens Fusion IO angestellt.

Da es aber noch offiziell als experimentell gilt, ist die Performance in vielen Bereichen verbesserungsbedürftig und es ist nicht als fehlerfrei anzusehen. Ein Einsatz im Produktivbetrieb ist nicht empfehlenswert. Wer ein COW-Dateisystem im Serverbetrieb haben will, der sollte lieber zu ZFS wie mit FreeBSD oder ZFS on Linux greifen. Da ist man eben einfach weiter und ZFS ist eben schon längst stabil.

ext5?

Ein ext5 ist unwahrscheinlich, da der Autor der ext-Dateisysteme selbst bisher in der Sache nichts hat verlautbaren lassen und außerdem Btrfs als zukünftigen, möglichen Standard ansieht.

NiranVs Viewer wird eingestellt – oder auch nicht

Das mit den Gemütslagen mancher Opensourcentwickler ist ja so eine Sache. Das Leben ist natürlich nicht einfach, meistens ist es sogar recht undankbar, längst nicht alles, was man programmiert, wird auch von Projektleitern dann übernommen. Das empfinden viele als einen Schlag ins Gesicht, kommt aber täglich vor und damit muss man eben einfach leben, fertig. Nicht umsonst hieß das Essay von Eric S. Raymond damals „Die Kathedrale und der Basar.“

NiranV Dean hat nun bei Linden Lab einen Bugreport eingereicht, dass die Attachments im Viewer nicht genau symmetrisch dargestellt werden und, wie es sich gehört, das alles schön fein säuberlich dokumentiert plus eine mögliche Problemlösung gleich mitgeliefert. Das klingt im Prinzip erstmal nach einer runden Sache, das Ticket nennt sich Open-162. Da gibt es auch einige Bilder dazu, inwieweit nun sich der bisherige Fehler genau auswirkt. Eigentlich ist es mehr eine Kleinigkeit kosmetischer Natur.

Nun hat Linden Lab aber den Bugfix nicht angenommen und das Ticket geschlossen. Warum? Ganz einfach, weil dieser Bugfix Unmengen an bereits existierendem Content kaputt machen würde, und die Besitzer per Hand nachbessern müssten. Die meisten Designer haben nämlich drum herum gebaut und fertig, also es ist kein wirklich weltbewegender Fehler, sondern mehr so eine Sache mit der man leben gelernt hat und an die man sich gewöhnt hat. Second Life ist voll davon, und würde man nun hergehen und das korrigieren, dann wäre der Schaden eindeutig größer als der Nutzen. Also ist es besser, man lässt es so bleiben wie es ist und fertig.

NiranV Dean weiß zwar darum, aber er ist folgender Meinung:

better break all available content that has been attached to those bones instead of creating even more broken stuff in the future making it unnecessarly harder for avatar and clothing creators to align their stuff symetrically correct. If this issue would have never happened , i wouldnt have lost so many hours on finetuning my legs and other attachments because they are simply not symetric to each other.
And instead of saying „it breaks content“ we actually DO it and prevent more broken stuff to be created which makes this shitstorm just bigger.

Und mit der Meinung eben flog er auf die Schnauze, fertig. Das kommt vor, und es ist einmal wirklich einer der Fälle, wo ich die Meinung von Linden Lab absolut unterstütze, die da lautet:

Real bodies are not perfectly symmetric, and neither is our avatar model; changing this now would be more disruptive than symmetry justifies.

Also Linden Lab erspart seinen Zigtausend Benutzern hunderte von Stunden unnötiger Arbeit. Schön. Die Reaktion von Niran darauf ist trotzig, er hat nun angekündigt, deswegen mit der Entwicklung seines Viewers aufhören zu wollen.

Er selber schrieb dazu das noch: 

for my users , i will do one last release sometime soon (not sure yet) and i guess thats it then , i will just return to what i´ve done prior to creating a Viewer that doesnt try holding the users hand and wants to improve Second Life instead of keeping its broken state

Da sage mal noch einer, dass Programmierer keine Diven sein können.