Kategorie: Programming

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!

Hypergrid 2.0: die Zukunft ist jetzt!

Diva Canto (bürgerlicher Name Crista Lopes), die Erfinderin des Hypergrids, erklärt in einem ihrer seltenen Blogposts bei sich, was für die Version 2.0 des Hypergrid-Protokolls geplant ist und wie es funktionieren soll.

Zunächst geht sie dabei ein wenig auf die Geschichte der verschiedenen Versionen ein: so war HG 1.0 ausschließlich als „proof of concept“ gedacht gewesen, um zu testen, ob das Konzept überhaupt funktionieren könnte, nicht mehr aber auch nicht weniger. Die Implementierung irgendwelcher Sicherheitsmaßnahmen stand dabei noch nicht zur Debatte, es ging ausschließlich darum, ob man dem Viewer glauben machen könnte, dass er sich noch im selben Grid bewege – und man konnte. Das Hauptziel zu testen, ob und wie man den Viewer für Zwecke mißbrauchen könne, für die er niemals gedacht gewesen war, war erfolgreich erreicht.

Als nächstes Ziel mit HG 1.5 ging es darum, erste einfache Sicherheitsmaßnahmen zu etablieren. Mit dieser Version wurde eine fälschungssichere Identität eingeführt, ein etwas sicherer Zugriff auf das Inventar und gridübergreifende IMs sowie Freundeslisten. Das ist der aktuelle Stand der Dinge, für den große Teile von Opensimulator umgeschrieben werden mussten, damit es überhaupt funktionierte.

Also was wird mit Hypergrid 2.0 kommen, was sind die Ziele?

Inventar
Zuerst einmal  soll das Inventar zu 100% abgesichert werden und der Ordner „My Suitcase“ wird endlich ohne externe Webapplikationen benutzbar sein [Anm.: 100% Sicherheit kann und wird es niemals geben, bei solchen vollmundigen Claims werde ich immer skeptisch!]. Wenn ein Benutzer in ein anderes Grid teleportiert, dann hat das Grid nur noch Zugriff auf den Ordner „My Suitcase“ und der Rest ist nicht sichtbar. Teleportiert der Benutzer dann zurück, wird der Ordner „My Suitcase“ wieder durch den echten Root-Ordner ersetzt und fertig.

Ob und wie der Ordner genau genutzt werden kann, wird dabei konfigurierbar sein. Es kann beispielsweise sein, das manche Grids den Export ihrer Assets mit diesem Ordner nicht erlauben wollen, und so wird der Benutzer dann extern leicht anders ausseehen.

Zugriffskontrolle auf Benutzerebene
Es werden verschiedene Richtlinien an Zugriffskontrollen implementiert werden: wer teleportieren kann und wie, wer zu einem teleportieren kann und von wo. Diese Kontrollen werden auf verschiedenen Richtlinien basieren, die die Information über die Benutzer selber als auch deren Herkunftsgrids berücksichtigen werden.

So wird es beispielsweise möglich sein, dass nur Benutzer ab einem bestimmten Level über das Hypergrid andere Grids besuchen können werden, während andere unterhalb dieses Levels es nicht können – das ist ein Wunsch, den gerade Bildungseinrichtungen häufig fordern. Es wird möglich sein, eine Liste an Grids festzulegen, die die Benutzer besuchen dürfen – oder nicht.

Für mögliche Gäste ist es ebenfalls analog möglich zu bestimmen, von welchen Grids Besucher erlaubt sind und für welche nicht – oder es ganz einfach ganz abzuschalten.

Zugriffskontrolle auf Asset-Ebene
Es wird eine Möglichkeit geben um einzustellen, ob das Grid Assets exportieren darf und wenn ja, zu welchen Grids oder generell. HG 2.0 wird dabei allerdings keine feinere Einstellungsmöglichkeit unterstützen, man wird also nicht sagen einstellen können, das ein bestimmtes Set an Assets exportiert werden darf und das andere nicht. Dies benötigt eine Möglichkeit, so etwas einzustellen und bisher ist diese noch nicht existent.

Jaja, die Ewiggestrigen 1er-Viewer-Benutzer – mal historisch aufgedröselt

Zasta hat es heute mal wieder in seinem Blog mit den Leuten hat, die noch die 1er-Viewer wie Phoenix und dergleichen benutzen und nicht mehr versteht, wieso man diese Viewer noch freiwillig einsetzen kann, wo ihnen doch z.B. ganz einfach die multiplen Tattoolayer fehlen und der aktuelle Lindenviewer mit Abkömmlingen wie Firestorm inzwischen um einiges weiter ist. Dabei ist die Antwort darauf recht einfach, wenn auch vielschichtig.

Die wichtigste Erkenntnis dabei ist diese: der Viewer ist für die Bewohner von Second Life das Tor nach SL, damit ihr Werkzeug und wichtigstes Programm zur Nutzung von Second Life überhaupt.

Machen wir uns dabei ruhig nichts vor: der 1er-Viewer war und ist von der Usability her gesehen eine Katastrophe gewesen, ein historisch gewachsenes Chaos, das innerhalb von fast 9 Jahren entstand und immer mehr und mehr üppig wucherte. Er hatte dabei einige wirklich gute Ideen gehabt, wenn man sie entsprechend zu nutzen weiß, wie das Tortenmenü. Jaja, ich weiß manche können das nicht leiden, aber es ist auch nicht totzukriegen. Während sie im offiziellen Lindenviewer verschwanden gibt es Spekulationen darüber, ob in MS Office 15 nicht diese eingeführt werden, um die Nutzung auf Touchscreens zu erleichtern.

Aber wie auch immer: der 1er-Viewer war von der Usability her gesehen die reinste Katastrophe, der Punkt dabei ist allerdings der: wir kannten und hatten nichts besseres zur Hand gehabt. Jeder, der früh genug mit Second Life anfing, musste sich erst einmal mühsam durch diesen Viewer quälen und sich mit ihm anfreunden – oder er hörte irgendwann in dieser Arbeit einfach auf. Die Lernkurve zur Beherrschung dieses Viewers war extrem steil gewesen und für viele frustrierend hoch, zu hoch. Es gab zwar Projekte wie Imprudence, die sich auf die Fahnen schrieben, alles besser machen zu wollen und es in Details auch taten, aber niemals den Drive und die Masse entwickelten, in Second Life wirklich relevant zu werden.

Wer noch heute davon schwadroniert, wie leicht und einfach die 1er-Viewer zu bedienen seien, der lügt sich selbst in die Tasche. Es fällt einem nur deswegen leicht, weil man es eben so gewohnt ist und sich da inzwischen mit schlafwandlerischer Sicherheit bewegen kann, aber bis man diese Sattelfestigkeit erreicht hatte, das dauerte mitunter Wochen! Ein wirklich einfach und intuitiv zu bedienendes Programm sieht anders aus, mir fallen da beispielsweise von früher Kais Power Tools unter Windows ein.

Das ist auch der Grund, weswegen Linden Lab irgendwann einmal damit anfing, seinen Viewerdschungel 1 genauer zu analysieren und – ich finde zu Recht – einen der Hauptgründe, warum viele Benutzer nur einmal einloggten und danach nie wiederkamen in der absolut unterirdischen Usability dieses Viewers ausmachte. Im Klartext: das Programm hat einfach die Mehrheit der potentiellen Benutzer so dermaßen überfordert gehabt, dass sie genau einmal einloggten und dann nie wiederkamen, weil sie sich einfach diesen Mist nicht geben wollten.

Die richtige Entscheidung von diesem Desaster ist gewesen, dass man den Viewer grundauf von der Benutzeroberfläche her renovieren wollte – und das auch tat. Damit wollte man die Zahl der Benutzeranmeldungen steigern und dafür sorgen, dass man sich sofort einfacher zurecht findet in Second Life. Das ist im Prinzip eine Entscheidung gewesen, die nach wie vor richtig ist, nur die Umsetzung an sich ist das absolute Debakel gewesen.

Es ist nunmal so, und da kann man sich auf den Kopf stellen und mit den Beinen wackeln wie man will, das ändert nichts daran: der Mensch ist ein Gewohnheitstier. Hat er sich erst einmal an eine Plattform gewöhnt, dann will er diese auch in der Art und Weise damit arbeiten können, wie er es gelernt hat und sich nicht auf einmal durch eine neue Version der Software wieder vorkommen wie ein kleiner Pennäler in der Schule. Er erwartet einfach, dass die Menüs genauso weiterhin aufgebaut sind, wie er es gewohnt ist, die Buttons da sind, wie er es gewohnt ist und genauso aussehen, und und und…

„Jaja, die Ewiggestrigen 1er-Viewer-Benutzer – mal historisch aufgedröselt“ weiterlesen

Firestorm 4

Heute ist der neue Firestorm in der Version 4 erschienen (wer den Phoenixviewer nutzt, der sollte sich ebenfalls das heute erschienene Update für den holen, damit das Inventar weiter richtig funktionier).

Dieses Release ist als Wartungsrelease zu betrachten; es gibt nicht wirklich neue und nennenswerte Features, statt dessen hat man die Performance hoch geschraubt, Fehler bereinigt und allgemein dafür gesorgt, dass der Firestorm einen flotteren und runderen Eindruck hinterlässt.

Das ist auch wirklich diesmal gelungen; als ich ihn unter Windows startete, war das auf derselben Maschine ein gefühlter Unterschied wie Tag und Nacht. Es ist die erste Version vom Firefox die locker fluffig genug läuft, dass ich mir vorstellen kann, sie zu meinem neuen Hauptviewer zu machen.

Lange genug haben die Macher vom Firestorm daran auch gearbeitet, dies ist das Ergebnis von über 15 Monaten Arbeit und noch mehr, und diese Arbeit trägt nun endlich Früchte.

Mit diesem Release vom Firestorm gibt es nun so langsam wirklich keinen Grund mehr, sich in Second LIfe noch einen 1er-Viewer anzutun, vor allem da gewisse Sachen wie Multiple Tattoolayers bei Mesh geradezu Pflicht sind.

Blinder Aktionismus und Kony

All diejenigen, die gerade bei der von Internetaktionisten losgetretenen Kampagne „Kony 2012“ mitmachen, sollten mal fünf Minuten ihrer Zeit opfern und sich diesen Artikel in der Telepolis genau durchlesen, der die Hintergründe und vor allem die Macher dieser Kampagne genauer beleuchtet.

Und dann solltet ihr mal genauer überlegen, vor wessen Karren ihr euch da alle bereitwilligst habt spannen lassen. Die Absichten der Organisation „Invisible Children“ und anderer Leute sind nämlich alles andere als nur redlich noch offensichtlich, die haben alle eine geheime Agenda.

Dann schaut euch noch an, was für Bodenschätze in Uganda liegen (die weltgrößte Kobaltmine, Erdöl u.a.), und denkt mal in Ruhe darüber nach: es geht dabei gar nicht um Kony, es geht dabei nur um die Rohstoffe und dass die USA einen Fuß nach Uganda rein kriegen und nicht, wie sonst meistens in Afrika, die Chinesen. Mal wieder.