Schlagwort: linux

SteamOS ist ziemlich sicher tot

Die Spielefirma Valve und ihren CEO Gabe Newell dürften so ziemlich alle kennen, denn deren Spiele wie Counterstrike, Team Fortress 2 oder Half-Life kennt fast jeder. Valve drängt es ja seit einiger Zeit in die heimischen Wohnzimmer und das dazu auserkorene Mittel der Wahl war bisher eine eigene, auf Debian basierende Linuxdistribution namens SteamOS, an der Valve seit etwas über zwei Jahre arbeitet. Die Gründe dafür waren unter anderem die Offenheit von Linux, die Möglichkeit, einen eigenen Steamcontroller anzuschließen und die Kontrolle über das System. So sagte jedenfalls Gabe Newell.

Viele sahen das ja als den Durchbruch für Linux Gaming an und freuten sich, selbst Linus Torvalds war recht begeistert. Das Problem an Linux ist ja die Fragmentierung und wenn Valve eine Plattform für Spiele für alle bereit stellt, fällt das weitestgehend in dem Bereich weg. Andere Probleme waren und sind allerdings die manchmal grottige Performance von OpenGL, sowie dass unter Linux die Grafikkarten von Nvidia deutlich schneller als die von ATI laufen. Ein weiteres Problem ist, dass natürlich auch diverse Game Engines an Linux angepasst und optimiert werden müssten .Wenn man es richtig macht, dann sind Frameraten möglich, die mit Windows gleichauf sind oder sogar noch schneller, nur wird diesen Aufwand längst nicht jeder Entwickler oder jedes Studio betreiben, wie Valve das mit der Source Engine getan hat.

Jedenfalls nun gibt es, von der Öffentlichkeit recht wenig beachtet, seit einiger Zeit von Dells Alienware die erste Konsole zu Steam – und sie läuft mit Windows 8.1. A-ha. O-ho. Man hat keine Ahnung, wie Valve es geschafft hat, Microsoft weich zu kriegen, aber das Ding bootet nicht mal mit dem Windows-Logo, sondern einem von Alienware. Also hat Valve offenkundig von Microsoft bekommen was, anderen Firmen bisher nicht möglich war.

Da bleibt dann natürlich die Frage offen: Was wird nun aus SteamOS? Offenkundig war SteamOS ein gutes Druckmittel, um Microsoft klein zu kriegen und zum Einlenken zu bewegen. Das hat jetzt ja nun auch gut geklappt. Windows hat den Vorteil, dass auf der Plattform eben alle Spiele schon zur Verfügung stehen und nicht erst portiert werden müssen. Eine Steambox unter Windows hat den Vorteil, dass darauf natürlich sehr viel mehr Spiele laufen können, man hat den Leistungsabfall mit ATI-Treibern nicht und auch keinen extra Portierungsaufwand.

Da bleibt dann doch die Frage: was wird nun aus SteamOS werden? Der Grund, warum man mit der Entwicklung von SteamOS anfing, hat sich damit ja nun weitestgehend erledigt. Wird Valve nun wirklich weiterhin hinter SteamOS stehen oder aber es noch eine Weile pro forma weiter pflegen und dann gibt es einen „fade out of existance?“

Ich denke, letzteres wird der Fall werden. SteamOS hat seine Schuldigkeit getan und Valve benötigt es ganz einfach nicht mehr. Wozu also sollte Valve noch Energie in das Projekt stecken, was Zeit und Geld kostet, wo sie nun von Microsoft das bekommen haben, was sie wollten? SteamOS ist damit ziemlich sicher tot und wird irgendwann einfach aufhören zu existieren, ganz einfach weil SteamOS für Valve keinen Sinn mehr macht und seinen Zweck erfüllt hat.

Und wenn denn Microsoft dann doch irgendwann wieder meint, andere Bedingungen diktieren zu können, dann kann Valve einfach auf SteamOS verweisen und androhen, es weiter zu entwickeln. Das reicht dann schon aus, mehr muss es nicht mehr können.

Btrfs sucks

Btrfs wird ja unter Linux als das nächste, große Standarddateisystem angesehen. Es ist so eine Art „running gag“, jedenfalls ist es noch in der Entwicklung und wird als in zwei bis drei Jahren als möglicherweise stabil genug für den Alltagseinsatz angesehen.

Btrfs ist dabei ein Copy on write-Dateisystem und die Featureliste liest sich so, als habe man da fröhlich bei ZFS von Sun abgekupfert. Btrfs wurde ursprünglich von Oracle entwickelt, dann kauften die Sun und haben seitdem auch die Rechte an ZFS, nun wird es extern entwickelt. Wie auch immer.

Btrfs liest und fühlt sich wie eine schlechte Kopie von ZFS an. Da kann man auch besser gleich zum Original greifen, das stabiler ist, mehr Features hat und für den Produktionseinsatz bereit ist.

Beispiele gefällig, wieso ZFS saugt?

  • df unter Btrfs lügt und zeigt nicht den freien Plattenplatz an. Dumm aber, wenn es Skripte/Programme geben sollte, die auf die Ausgabe von df vertrauen. Der notwendige Befehl lautet „btrfs filesystem df /“. Ein Unding.
  • Btrfs ist im Vergleich zu Ext4/XFS in den meisten Fällen schnarchlangsam.
  • Btrfs ist für den Betrieb von Datenbanken oder virtuellen Maschinen denkbar ungeeignet. Dafür nimmt man besser Ext4 oder gleich XFS.
  • Tree Balancing, also das Verteilen von Daten über mehrere Festplatten, kann durchaus einen Tag oder länger dauern.
  • Es besteht noch immer die geringe Möglichkeit, dass sich wenn ein Fehler gefunden werden sollte, das On-Disk-Format geändert werden muss.

Wirklich ein dolles Ding, dieses Btrfs. Wer unter Linux solch ein Dateisystem nutzen will, der sollte besser gleich zu ZFS on Linux greifen.

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.

Rant: GNOME 3.0 saugt unendlich!

Für einen Großteil meiner Arbeit nutzte ich GNOME unter Linux, das neben KDE eines der beiden großen Desktop Environments ist. GNOME 2.X war zum Arbeiten einfach eine Freude, es war stabil und hatte ziemlich genau die Konfigurationsmöglichkeiten und Features, die man erwartet und braucht, ohne dabei überladen zu wirken noch stand es einem bei der Arbeit groß im Weg. Dabei ist es mir völlig egal, dass manche diese Version nicht sexy fanden oder zu sehr Windows ähnlich, denn mal ehrlich: seit dem Macintosh 1984 und Windows 95 hat sich doch in Hinsicht auf die am Computer verwandte Bedienungsphilosophie sich wenig geändert. Sie mag zwar nicht unbedingt der Weisheit letzter Schluss sein, aber sie ist wohlbekannt und funktioniert!

Irgendwie ist aber in letzter Zeit der Zug der Zeit, dass die Entwickler der Software der Meinung sind, besser zu wissen was die Anwender wirklich für ihre tägliche Arbeit benötigen und haben wollen als die Anwender selber! Diese Geisteshaltung führt dabei zu den merkwürdigsten Entscheidungen und häufig dazu, dass sich Entwickler und Benutzerbasis voneinander stark entfremden, die Benutzer die Entwickler bestenfalls als arrogant empfinden und sich nach Alternativen umsehen, ggf. diese starten und selbst entwickeln.

Kein Benutzer liebt die Software, die er benutzt wirklich, sondern er entscheidet sich aus dem vorhandenen Sumpf an Kröten für diejenige, die beim Runterschlucken am wenigsten Schmerzen verursacht. Wenn die bisher gewohnte Kröte auf einmal zu sehr das Wachsen anfängt, dann findet die Mehrheit sehr schnell eine neue Kröte, also neue Software auf die sie wechselt.

Bei GNOME ist es so, dass der Schritt auf 3.0 mit einem gehörigen Wechsel in der Bedienungsphilosophie einherging. Man baute einen Desktop zusammen, der so ziemlich jede bisher bekannte Bedienungsweise über den Haufen warf, dabei gut aussieht und völlig unbenutzbar ist. Jeder kennt beispielweise den System Tray, wo Benachrichtigungen angezeigt werden. Dieser ist bei GNOME 3 nun standardmäßig unten am Bildschirm und ausgeblendet, man muss erst mit der Maus hin um zu sehen, was sich tut. Fenster benötigen ja auch keinen Button mehr zur Maximierung, also weg damit, und wozu noch ein Startmenü, wenn es ein komischer Aktivitätenbildschirm auch tun kann, und und und.. .und bitte alle Konfigurationsmöglichkeiten weg, die es noch in GNOME 2.X gab, denn das stört ja nur.

Nun steht GNOME 3.6 vor der Türe, und die Entwickler feiern sich mal wieder heftig selber für ihre Runderneuerung am Dateimanager Nautilus, eine der großartigen Neuerungen ist die Entfernung der Compact View, einer Darstellung im Dateimanager die grob etwa mit der von „Kleine Symbole“ im Windows Explorer vergleichbar ist. Diese wurde nun ersatzlos trotz massivem Protests gestrichen! Warum? Weil einige Entwickler der Meinung sind, dass die Listen- und Symboldarstellung ausreiche, man in der Compact View häufig nicht alles sähe und vertikal scrollen müsse, und das sei bah! Also weg damit!

Und so arbeiten die Entwickler von GNOME 3 munter weiter daran, sich selber überflüssig zu machen, denn kein halbwegs vernünftiger Mensch möchte GNOME 3 wirklich auf seinem Rechner als Produktivumgebung benutzen. Was sie mit GNOME 3 hingelegt haben und hinlegen ist ein Undesktop der Extraklasse, eine Benutzerumgebung, die sehr gut für ein Tablet geeignet ist und mit einem solchen prima funktionieren würde – würde es denn ein GNOME 3 Tablet geben! Gibt es aber nicht und wird es so schnell nicht geben, was aber die Entwickler nicht davon abhält, ihren eingeschlagenen Weg in die selbstgewählte, völlige Bedeutungslosigkeit munter weiter zu beschreiten, indem sie GNOME 3 ohne Not für den Desktop völlig unbenutzbar machen! Übrigens sind sie damit ja nicht alleine, Microsoft hat mit Windows 8 genau denselben Weg beschritten, aber wenigstens hat Microsoft ein Tablet, auf dem sein Betriebssystem denn auch läuft! Dennoch, egal ob GNOME 3 oder Windows 8, beide sind und bleiben für den Desktop unbenutzbar und eine absolute Qual!

Dabei ist an GNOME 3 längst nicht alles schlecht, die Technik im Unterbau mitunter sehr gut brauchbar, aber die Präsentation ist einfach nur furchtbar. Kein Wunder also, dass mit MATE jemand die Quellcodebasis von GNOME 2.X geforkt hat und diesen nun unabhängig von GNOME 3.X weiter entwickelt, Canonical lieber sein eigenes Unity als Standarddesktop pflegt und es ein Projekt namens Cinnamon gibt, dessen erklärtes Ziel es ist, weitestgehend das alte Look&Feel von GNOME 2.X auf GNOME 3 zu portieren.

Währenddessen wundern sich einige GNOME-Entwickler inzwischen öffentlich darüber und beklagen sich, dass eine große Distribution nach der anderen ihr Engagement für GNOME massiv runterschraubt oder gar einstellt (SUSE, Nokia), sie lieber andere Desktop Environments anstelle von GNOME zum Standard erklären (Ubuntu, Linux Mint) und wichtige Applikationen bisher nicht auf GTK3+ portiert worden seien. Da könnte man ja meinen, da sei die Nachricht mal langsam so angekommen, aber Irrtum, wenn man sich dann mal wieder diesen Beitrag über Nautilus 3.6 durchliest, in dem u.a. das Entfernen der „Compact View“ des Dateimanagers als Fortschritt gefeiert wird, kann man nur sagen: Leute, ihr habt den Knall noch immer nicht gehört!

Und solange sich das nicht ändert und die Entwickler endlich mal aufgerüttelt werden, um aufzuwachen und wieder auf ihre Benutzer zu hören, bleibt nur noch eines zu sagen: Ruhe in Frieden, GNOME 3! Mit der Attitüde kann das ja nichts mehr werden und irgendwie ist XFCE auch nicht schlecht. Die Entwicklungszyklen dort sind zwar länger, aber immerhin hören die Entwickler dort noch deutlich mehr darauf, was ihre Benutzer wollen oder auch nicht.

The power of Linux

Heute mal etwas völlig anderes: man kennt das ja, da hat man eine externe Festplatte, die man unbedingt frei haben muss, um sie mit neuem Zeug zu füllen und muss sie mindestens für ein, zwei Tage auf dem eigenen Rechner speichern können. Auf der externen Festplatte sind vielleicht 300 GB an Daten und auf dem eigenen Rechner sind noch 350 GB an Plattenplatz frei. Dumm nur, dass sich diese 350 GB auf drei Festplatten verteilen und auf der ersten 200 GB frei sind, auf der zweiten 100 und der dritten ebenfalls.

Was also tun? Man könnte versuchen, den Inhalt von einer Platte auf die andere interne zu kopieren, um so zumindest auf einer genügend freien Platz zu schaffen – aber das dauert und besonders einfach ist das auch nicht immer. Nein.

Praktischer ist es dabei, sich ein billiges Raid-0 (Striping) über Loop-Devices zu basteln, deren Imagedateien auf den drei Festplatten liegen, das man dann mit einem beliebigen, geeigneten Dateisystem formatiert und die externe Festplatte wird darauf gesichert. Das geht standardmässig mit jedem einigermaßen, aktuellen Linux recht einfach.

Zuerst einmal fängt der Spaß damit an, dass man die Imagefiles auf den jeweiligen Festplatten als sog. Sparse File anlegt. Dies macht man praktischerweise mit dem netten Befehl dd:

dd if=/dev/zero of=file1.img bs=1k seek=128M

Das legt ein Sparsefile an, welches maximal 128 GB an Inhalt fasst. Man lege also so drei Sparse-Files auf den verschiedenen Festplatten an, nenne sie meinetwegen file1.img, file2.img und file3.img und passe natürlich auch die Größe an, meinetwegen 150 GB, 100 GB und 50 GB.

Als nächstes muss man dann Linux sagen, dass es diese Image-Files als Loopback-Device zur Verfügung stellt. Wer ein Loopback-Device nicht kennen sollte: damit tut der Kernel so, als sei das Image-File ein weiteres, physikalisches Gerät. Man kann diese Devices also z.B. nutzen, um ISO-Images direkt von der Festplatte zu mounten und auszulesen, eine praktische Sache.

Der Befehl, den wir dazu brauchen, ist losetup, und so sieht das dann auf:

losetup /dev/loop0 /file1.img
losetup /dev/loop1 /mnt/bla/file2.img
losetup /dev/loop2 /mnt/bla2/file3.img

Damit wird dem Device /dev/loop0 die Datei file1.img zugewiesen usw.

Als nächstes müssen wir dann aus den drei Devices ein Raid-0 basteln, was nichts anderes bedeutet als dass der Kernel aus dem Speicherplatz der drei Dateien einen einzigen, zusammenhängenden Bereich generiert, und das geht so:

md-adm --create /dev/md0 --level=0 --raid-devices=3 /dev/loop0 /dev/loop1 /dev/loop2

Damit wird der Kernel angewiesen, mit der Datei /dev/md0 ein Raid-0 zur Verfügung zu stellen, welches sich genau über die drei Loop-Devices erstreckt.

Als letztes formatiere man dann das Raid-Device md0 noch mit einem Dateisystem (hier: Ext4) seiner Wahl, beispielsweise so:

mkfs.ext4 /dev/md0

Und mounte es:

mount /dev/md0 /mnt/backup

Wenn man dann später das Backup nicht mehr braucht, kann man die Imagedateien einfach löschen und der Platz ist wieder frei, und fertig ist die Laube. Schön, nicht wahr?

Ach ja, und wenn man später mal die Dateien doch noch mal zusammen bauen will zum Raid-0, um nach einem Neustart wieder darauf zuzugreifen, muss man nur den Schritt mit losetup ausführen und danach das hier eintippen:

md-adm --assemble /dev/md0 /dev/loop0 /dev/loop1 /dev/loop2

Das ist alles.

PS: Für wen Linux und dessen Kommandozeile ein böhmisches Dorf ist, der sollte besser die Finger davon lassen, bevor er sich noch wichtige Daten zerschießt und ohnehin ist es sinnvoll, immer mindestens ein aktuelles Backup zur Hand zu haben! Ihr seid gewarnt!