Linux direkt in einem Browser booten

Es gibt immer wieder diese Momente, die mich einfach nur staunen lassen. Wie jetzt z.B., wenn ich einen kompletten PC Simulator auf Basis von Javascript sehe, der direkt in einem Browser läuft und Linux bootet. Was ist das für ein krasser Scheiss?

Wenn man sich ein bisschen mit PC Technik auskennt, dann kann man erahnen wie komplex es sein kann, so etwas zu simulieren. Und dabei wird nicht irgendeine “simple” CPU simuliert – es handelt sich um eine 32 Bit x86 kompatible Implementierung. Da wird also ein Prozessor simuliert (hier natürlich trotzdem in stark eingeschränkter Form), wie er heute noch in sehr großen Teilen zum Einsatz kommt. Theoretisch könnte man darauf auch Windows laufen lassen.

Was erstmal wie ne Spielerrei aussieht, kann durchaus einen Nutzen haben. So ist das System in erster Linie sehr gut für Javascript-Engine-Benchmarks geeignet, aber auch, um etwa x86 Librarys direkt auf dem Clientrechner laufen zu lassen und mit ihnen per API zu kommunizieren. Konkret könnte eine Webseite das System einbinden, und dann per API auf Verschlüsselungsfunktionen von z.B. Linux zurückgreifen. Das ermöglicht eine sichere Verschlüsselung direkt auf dem Clientrechner, bevor die Daten zum Server gesendet werden…

Live ausprobieren könnt ihr das System hier – natürlich mit einem relativ aktuellen Browser…:
bellard.org/jslinux

Technische Details zum System findet ihr hier:
bellard.org/jslinux/tech.html

Versionsverwaltung mit git

Wie so oft in diesem Blog sprechen wir natürlich über ein technisches Thema – und zwar geht es um Versionsverwaltung. Vornehmlich im Bereich Softwareentwicklung angesiedelt kann man damit seinen Quellcode verwalten. Warum braucht man dazu ein eigenes Programm? Man hat die Dateien ja da und kann ab und zu ein Backup machen, oder?

Ganz so einfach ist es doch nicht, denn man kommt mit dieser Vorgehensweise sehr schnell an seine Grenzen. Ein paar Beispiele: mit einer einfachen Dateiverwaltung wird es teilweise unmöglich, im Team zu arbeiten, weil es zwangsläufig dazu kommt, dass mehr als eine Person an der gleichen Datei arbeiten muss. Software ist NIE fertig, es wird immer wieder Änderungen oder Bugfixes geben. Was macht man, wenn man zu einer älteren Version zurück will oder nur mal die Unterschiede zwischen zwei Versionen vergleichen will? Verbreite ich meinen Quellcode sinnvoll, damit mein Opensource-Projekt aktive Mitstreiter bekommt und diese ihr Änderungen auch wieder zu mir zurückfließen lassen können? Diese Liste kann man beliebig erweitern, und es wird immer wieder herauskommen, dass eine Versionsverwaltung doch immer der elegantere Weg sein wird.

Das haben Entwickler ziemlich zeitig bemerkt und entsprechende Programme entworfen, die einen bei diesem Problem unterstützen. Heraus kamen Systeme wie cvs oder Subversion. Die sind schon ganz gut, haben aber immer ein großes Problem: sie brauchen einen Server. Und das veringert die Geschwindigkeit sehr deutlich. Hinzu kommt, dass Arbeit von Unterwegs erheblich erschwert wird, weil man nur bei einer Verbindung zum Server Zugriff auf die Historie einer Datei hat.

Was mich persönlich am meisten gestört hat, war der Umstand, dass die bestehenden Systeme nur sehr schlecht mergen – also zusammenführen mehrerer Änderungen in der gleichen Datei – können. Auch sehr unschön war das Branching – also das Anlegen eigener Entwicklungszweige.

Git ist hier äußerst robust und bekommt nur Probleme, wenn man wirklich die gleiche Zeile verändert. Entwickelt wurde das System von keinem anderen als Linux Torvalds, dem Erfinder von Linux. Ihm war die Verwaltung des Linux Quellcodes schon lange ein Dorn im Auge und am Markt gab es kein Tool, was seinen Ansprüchen genügte. Also entwickelte er ein entsprechendes System selbst – heraus kam git.

Die großen Vorteile: Die Repositories liegen lokal auf jedem Rechner, merge-Prozesse sind sehr schnell und auch sehr genau und das Anlegen von Branches sowie der Wechseln zwischen ihnen stellt kein Problem mehr dar. Es zeigt sich einfach, dass man viel autarker arbeiten kann, da man alle benötigten Daten auf seinem PC hat und erst dann mit dem Server kommunizieren muss, wenn man Commits übertragen oder Updates ziehen möchte. Sehr schön gelöst ist auch die Aufbewahrung der Meta-Daten. Liegt bei Subversion oder cvs in jedem Ordner ein Unterordner mit den Daten, so ist es bei git pro Repository nur ein einziger Ordner, und der liegt im Hauptverzeichnis des Projekts. Möchte man also Dateien versenden, so kann man diese direkt nehmen und muss nicht erst anfangen, jeden Ordner einzeln zu reinigen. Wer schon einmal ein Subversion Projekt von Meta-Daten befreit hat, weiß, wovon ich spreche 😉

Um meine Einleitung zu diesem Artikel noch zu relativieren: Man kann mit git und auch anderen Versionskontrollsystemen jede Art von Datei verwalten. Es gibt z.B. viele Grafiker, die ihre Projekte mit git verwalten, weil sie dann einfach in der Historie vor und zurück springen können. Selbst Backup-Lösungen kann man damit aufbauen. Am effizientesten funktionieren die Systeme aber noch immer mit reinen Textdateien.

Zum Thema Versionskontrollsysteme sei euch übrigens auch folgender Podcast sehr ans Herz gelegt:
CRE 130 – Verteilte Versionskontrollsysteme

Links
git

[Quicktip] MySQL Query-Ergebnis per Console in eine CSV Datei exportieren

Mit phpmyadmin und Konsorten ist es kein Problem, Ergebnisse von SQL Abfragen in CSV-Dateien zu exportieren. Problematisch wird es allerdings, wenn man eine aufwändigere Abfrage hat, die den php Timeout provoziert, oder aber man keinen Web-Client zu Verfügung hat. Dann greift man zur Konsolenversion von MySQL – welche diesen Export nicht direkt anbietet. Mittels ein bisschen Bash-Magie kann man sich aber behelfen:

mysql --database=database --execute="select a from b where a>1;" | sed 's/\t/","/g;s/^/"/;s/$/"/;s/\n//g' > filename.csv

Was passiert? Die Abfrage wird ausgeführt und die Ergebnisse werden in Textform ausgegeben. Mittels Pipe wird die Ausgabe an “sed” weitergegeben, welches diese in das CSV Format umwandelt und anschließend in die Datei “filename.csv” schreibt.

Via snipplr.com

[Quicktip] ssh Verbindung ohne Known-Hosts Eintrag

Es gibt gute Gründe, warum ssh die Fingerprints (also die virtuellen Fingerabdrücke) der Server speichert, mit denen man sich verbindet. Tut man dies nämlich erneut, so kann ssh prüfen, ob sich hinter dieser IP bzw. hinter diesem Hostnamen noch immer der gleiche Rechner befindet. Wenn nicht, gibt’s eine Warnung.

Nun gibt es aber auch Fälle, bei denen will man diesen Schutz unterbinden – vornehmlich beim Scripting. Und das macht man so:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@server

Was passiert? Mit dem ersten Parameter wird das known-hosts-File “/dev/null”, also “nichts”, verwendet. Parameter 2 gibt an, dass die Überprüfung der Fingerprints deaktiviert werden soll. Lässt man den ersten Parameter weg, so werden trotzdem die Fingerprints in der normale known-hosts-File geschrieben.