Kategorie: Programming

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.

Compiling Firestorm for dummies

Heute mal völlig unmotiviert eine kurze Anleitung, wie man Firestorm unter Linux selbst kompiliert.

Man benötigt: eine einigermaßen aktuelle Linuxdistribution wie Ubuntu, Debian, OpenSUSE, Fedora o.ä. mit funktionierendem C/C++-Compiler sowie installiertem Mercurial und Cmake, Python und Perl.

Zum Erstellen der Makefiles benutzt Linden Lab ein eigenes Tool namens autobuild. Dies installieren wir mittels

hg clone http://hg.secondlife.com/autobuild

Danach

cd autobuild; python setup.py build

Den Unterordner /bin nehmen wir dann in den Pfad auf, etwa so:

export PATH=/home/user/autobuild/bin:$PATH

Dann holen wir uns den Quellcode vom Repository mit

hg glone http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/

Wir wechseln in den Quellcodeordner von Firestorm und lassen nun Autobuild laufen mit:

autobuild configure -c ReleaseFS_open

Danach wechseln wir in den Ordner, dessen Namen mit build anfängt und beginnen mit dem Compilen. Dazu nehmen wir den Befehl

make -jX

X ist dabei ein Platzhalter für die Anzahl der Prozessorkerne +1.

Je nach Rechner dauert es dann 20 Minuten oder länger, bis er damit fertig ist.

Wenn alles geklappt hat, dann ist im Unterordner newview/packaged das lauffähige Programm. Das ist alles.

Chrome 30 für Android kann WebGL

Google hat heute Chrome Version 30 veröffentlicht. Die interessanteste Neuerung daran ist, dass es ab sofort WebGL unterstützt.

Warum ist das interessant? Ganz einfach, weil Cloudparty darauf basiert. Es könnte also nun sein, dass man ab jetzt Cloudparty auf Android-Tablets laufen lassen kann. Chrome für Android ist nun offiziell jedenfalls soweit.

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.

Creeping featurism

Bei Linden Research ist die Featuritis ausgebrochen: momentan gibt es so viele unterschiedliche Projektviewer wie schon seit Ewigkeiten nicht mehr.

Einerseits ist das natürlich eine gute Sache, so zeigt es doch, dass man zu technischen Verbesserungen und Innovationen bereit ist und diese auch voran treiben will.

Andererseits aber ist es wiederum schlecht, wenn man zu viele Baustellen gleichzeitig hat und sich so verzettelt. Momentan scheint das bei Second Life der Fall zu sein. Und was noch schlimmer ist, es macht gerade die Arbeit von Entwicklern der alternativen Viewer nicht gerade unbedingt einfacher. Einerseits sollen sie die „shared experience“ garantieren, aber wie sollen sie andererseits mit diesem Featuredschungel da noch gerade teilweise mithalten können?

So schön neue Features wie CHUI, SSA, das Materialsystem und weitere (wie der parametrische Meshdeformer) sein mögen, momentan scheint es doch ein wenig zu viel des Guten zu sein. Und so treten sich teilweise gerade alle Arbeiter gegenseitig auf den Füßen herum.