Karl Brodowsky's IT-Blog – Seite 40 – IT Sky Consulting GmbH

Ein paar Gedanken zu ssh

Früher, als man noch jedem im Internet und sogar im Intranet vertraute, hat man sich ja einfach mit telnet in andere Rechner eingeloggt. Oder mit rlogin, damit die Umlaute auch funktioniert haben. Leider ging dabei das Password im Klartext über das Netz, was natürlich unverantwortlich ist.

Nun hat man also stattdessen ssh und es funktioniert recht ähnlich wie damals telnet, kann aber gleich noch sehr viel mehr, auch wesentlich mehr als ich hier in ein paar Zeilen schreiben kann. Wichtig ist nicht nur, dass man das Password verschlüsselt überträgt, sondern auch, dass man sicherstellt, dass die Gegenseite wirklich der gewünschte Rechner ist, sonst kan ein „man in the middle“ das Password abfangen und man ist wieder da, wo wir mit telnet standen.

Dazu gibt es im .ssh-Verzeichnis diese Zertifikate, also solche Dateien wie id_rsa und id_rsa.pub. Die id_rsa sollte man hüten wie seinen Augapfel, da die Sicherheit des ganzen Protokolls davon abhängt. Mit ssh-keygen kann man sich solche Zertifikate auch anlegen, wahlweise auch so, dass man bei deren Verwendung ein Password eingeben muss (das nur auf dem lokalen Rechner bleibt). Die Zertifikate haben sogenannte „Fingerprints“, die man sich mit ssh-keygen -l anzeigen lassen kann. Genau dieser Fingerprint wird beim ersten mal angezeigt und man muss ihn bestätigen. Man sollte diesen also auf einem sicheren Kanal vorher überprüfen, dass er auch wirklich stimmt, zum Beispiel wenn man zwischen zwei Rechnern in einem verkabelten Netz, dem man traut, aufeinander zugreift, oder indem an sich den Fingerprint notiert oder ausdruckt. Wenn man ihn einmal bestätigt hat, wird er in .ssh/known_hosts eingetragen und man kann dort natürlich auch aufräumen, indem man unnötige Einträge löscht. Oder sogar mit USB-Stick übertragene Fingerprints reineditieren, wenn man das Format verstanden hat. Solange known_hosts keine falschen Einträge enthält, hat ein „man in the middle“ es sehr schwer und das Verfahren bietet eine vernünftige Sicherheit.

Nun lässt sich der „public key“ aus id_rsa.pub des eigenen Rechners in .ssh/authorized_keys des Rechners, auf dem man sich einloggen will, eintragen. Damit erreicht man, dass das ohne Password-Abfrage möglich ist, außer das lokale Zertifikat braucht eine Password-Abfrage. Die kann man aber auch einmalig pro Session mittels ssh-add durchführen.

ssh wird auch für andere Zwecke verwendet, weil man andere Protokolle darüber tunneln kann, z.B. Subversion oder git.

Sehr schön ist es auch, wenn man unter X11 ein
ssh -X user@host
aufruft. Dann kann man auf dem entfernten Rechner grafische Applikationen starten und das Display wird über den ssh-Tunnel umgeleitet.

Display umleiten ist in der Unix- und Linux-Welt schon seit über 25 Jahren gängige Praxis, aber mit ssh geht es nun auch sicherer als mit den unverschlüsselten Protokollen, die man damals gerne verwendet hat. Wer kennt noch xhost +?

Diese Überlegungen beziehen sich auf ssh unter Linux, gelten aber auch für alle möglichen Unix-Systeme, wie z.B. Solaris. Auf MS-Windows-Rechnern gibt es putty als verbreitete SSH-Client-Implementierung. Mit Putty findet man sicher vieles von dem wieder, was das Linux/Unix ssh kann, nur in etwas anderer Verpackung. Ich bevorzuge aber auf MS-Windowsrechnern cygwin und dessen ssh-Implementierung, die sehr ähnlich funktioniert. Es ist sogar möglich, mit cygwin einen ssh-Server aufzusetzen. Allerdings ist der Vorgang nicht ganz einfach.

MS-Windows-Bug oder Feature mit CMD

English

Jeder der mit MS-Windows-Rechnern zu tun hat, kennt diese schwarzen Fenster, mit dem cmd-Kommamdozeileninterpreter, wenn auch kaum jemand sie mag. Die Unix- und Linux-Leute mögen sie nicht, weil cmd einfach verglichen mit typischen Linux- und Unix-Shells lächerlich wenig kann und die MS-Windows-Leute wollen nicht in der Kommandozeile arbeiten, jedenfalls nicht in dieser. Es gibt Alternativen wie Powershell und cygwin mit bash, aber das schwarze Fenster wird doch meist mit cmd assoziiert. Unter Linux gibt es auch solche Fenster für die Shell, z.B. xterm, aber dort sind sie meistens weiß. Dabei kann man auf beiden Systemen die Farben konfigurieren, wie man will.

NT-basierende MS-Windows-Systeme (NT 3.x, 4.x, 2000, XP, Vista, 7, 8, 10) haben jeweils verschiedene Subsysteme und Programme laufen in diesen Subsystemen, z.B. Win64, Win32, Win16, cygwin, DOS. Weil nun Programme für das DOS-Subsystem typischerweise im CMD-Fenster gestartet wurden und einige der Kommandos, die im CMD angeboten werden, ihren gleichnamigen Vorläufern aus der DOS-Ära von vor 30 Jahren nachempfunden wurden, wurde dieses CMD-Fenster früher (und vielleicht gelegentlich noch heute) oft fälschlicherweise als DOS-Fenster bezeichnet. Dabei kommt dieses schwarze Fenster eigentlich in vielen Situationen zum Vorschein, wenn z.B. ein Win32-Programm gestartet wird, das Ein- und Ausgabe (stdin, stdout, stderr) hat. Wenn diese umgeleitet sind, z.B. in eine Datei oder an ein anderes Programm, kann das Programm unsichtbar ohne schwarzes Fenster starten und gegebenenfalls graphisch in Erscheinung treten. Wenn es keine Umleitung der Ausgabe gibt, wird dem Programm ein solches schwarzes Fenster für die Anzeige der Ausgabe automatisch zur Verfügung gestellt. Und eines dieser Programme mit stdin und stdout ist nun einmal cmd, deshalb wird beim starten von cmd das schwarze Fenster drumherum dazu geliefert. Unter Linux (und Unix mit X11) ist es umgekehrt, man startet xterm bekommt darin die übliche Shell, außer man gibt explizit an, dass etwas anderes darin gestartet werden soll.

Nun empfehle ich einmal ein kleines Experiment. Wir brauchen dazu einen beliebigen graphischen Editor wie z.B. emacs, gvim, ultraedit, textpad, scite, es darf sogar notepad sein. Und ein cmd-Fenster.

Diese Befehle abschreiben nicht mit Copy&Paste übertragen.
Im cmd-Fenster mit cd in ein Verzeichnis wechseln, in dem Dateien angelegt werden können (Schreibrecht), falls nötig..
echo "xäöüx" > filec.txt
Die dabei angelegte Datei filec.txt mit dem graphischen Editor öffnen. Wie sehen die Umlaute aus??
Mit dem Editor im selben Verzeichnis eine neue Datei fileg.txt anlegen, die etwa folgende Zeile enthält: yäöüy.
Im CMD-Fenster diese ausgeben:
type fileg.txt
Wie sehen jetzt die Umlaute aus?

Es ist ein Feature oder ein Fehler aller gängigen MS-Windows-Versionen, dass diese schwarzen Fenster in der Standardeinstellung die Umlaute auf andere Positionen legen als die graphischen Editoren. Vielleicht weiß jemand, wie man das ändern kann, es würde mich interessieren.

Was ist hier genau passiert? Als die ersten DOS-Versionen Anfang der 1980er-Jahre aufkamen, gab es nur einen halbwegs etablierten Standard für Zeichensatzcodierungen, das war ASCII oder ISO-646-IRV, was immerhin ein großer Fortschritt gegenüber EBCDIC war. Aber dieser normierte nur die unteren 128 Zeichen (7 Bit) und enthielt keine Umlaute oder in Varianten Umlaute statt „irrelevanter“ Zeichen wie „@“, „[„, „~“ u.s.w. So fingen Hersteller und Softwaresysteme an, für die oberen 128 Plätze im Zeichensatz ihre eigene Lösungen zu erfinden. Commodore, Atari, MS-DOS, Apple, NeXT, TeX und überhaupt „alle“ hatten im Laufe der Jahre ihre „Lösungen“ für verschiedene Sprachregionen gefunden, die natürlich jeweils inkompatibel miteinander waren, meist sogar noch zwischen verschiedenen Produktgenerationen oder Ländereinstellungen desselben Herstellers inkompatibel. In Zeiten, wo man sowieso noch kaum Netzwerke hatte, wo es auch eine Sammlung von verschiedenen herstellerspezifischen Formaten für Disketten und herstellerspezifische Netzwerktechnologien gab, fiel das noch nicht so auf. Aber relativ früh wurde es bei X11 (dem gängigen graphischen System für Unix und Linux) üblich, Standardzeichensätze aus der ISO-8859-x-Familie oder später sogar Unicode mit utf-8 und utf-16 zu unterstützen. Linux hat schon in den 0.99-Versionen auch ohne graphische Oberfläche diese ISO-8859-1-Zeichensätze verwendet und nie versucht, seine eigene Zeichensatzcodierung zu erfinden.

Inzwischen sind wohl alle relevanten Systeme auf zum Unicode-Standard kompatible Zeichensatzcodierungen wie ISO-8859-x, utf-8 und utf-16 umgeschwenkt. Aber MS-Windows hat dies nur teilweise umgesetzt. Während das graphische System nur die modernen Codierungen verwendet oder zumindest mit Cp1252 dem recht nahe kommt, hat man für das textbasierte System (schwarze Fenster wie bei cmd) die Codierungen aus der DOS-Zeit von vor über 30 Jahren, wie z.B. Cp850 beibehalten und so einen Bruch innerhalb des System in Kauf genommen, der sehr ärgerlich ist, wenn man mit Daten mit Umlauten in cygwin oder cmd-Fenstern arbeiten will.

Wenn man mutig ist, kann man dieses Verhalten in der Registry ändern. Man muss dazu in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage die Einträge OEMCP und OEMHAL gleichzeitig ändern. Einer ist für die Eingabe und einer für die Ausgabe zuständig, wenn man die also nicht gleichzeitig ändert, wird es sogar innerhalb des schwarzen Fensters inkonsistent. Sucht man danach im Internet, finden sich Beispiele, wo jemand versucht haben will, utf-8 (CP65001) einzustellen und das Ergebnis war, dass er nicht mehr booten konnte. Ich habe nicht überprüft, ob das manipulierte Behauptungen sind, um einer beliebten Firma zu schaden, oder ob es reale Erfahrungen sind. Man kann es mit Virtualisierung relativ risikofrei probieren, indem man sich ein funktionierendes System kopiert und es mit der Kopie testet. Auf jeden Fall ist das Editieren in der Registry nicht ganz risikofrei und geschieht „auf eigene Gefahr“…. Und in vielen Umgebungen ist es nicht möglich, weil die Berechtigungen dafür nicht ausreichen. Man kann es noch mit chcp im schwarzen Fenster selber ändern, vielleicht muss man dort auch noch so etwas wie chhal oder so eingeben, damit der Font passend zur Eingabe codiert ist.

Ob man das als „Bug“ oder lieber wegen der Kompatibilität zu älteren Versionen bis 30 Jahre zurück als Feature bezeichnen sollte, überlasse ich dem Leser.

Wo bleiben die Transaktionen bei den NoSQL-Datenbanken?

Jetzt war mal wieder so ein Vortrag bei einer der vielen User-Groups, in der ich drin bin. Diesmal ging es um Riak und der Vortrag war von einem der Entwickler und war wirklich gut. Ein Stück weit wurde die Grundsatzthematik der NoSQL-Datenbanken behandelt, wobei natürlich Riak im Zentrum stand.

Während es bei den SQL-Datenbanken vielleicht etwa vier gibt, die einigermaßen austauschbar sind, was die Funktionalität betrifft (Oracle, MS-SQL-Server, DB2 und PostgreSQL, mit Einschränkungen auch mySQL und MariaDB), ist hier die Frage relevant, das richtige Werkzeug für die richtige Aufgabe zu verwenden. Und das richtige Werkzeug sind oft die relationalen transaktionalen Datenbanken. Die Austauschbarkeit der relationalen Datenbankprodukte gilt natürlich nur, wenn man eine neue Applikation entwickelt, nicht wenn man Software nachträglich umschreiben muss und die Datenbankadministrationsprozesse nachträglich ändern muss.

Nun sind die Daten ja immer sehr wichtig, sonst könnte man sich den Aufwand ja sparen, sie zu speichern. Und wenn die Datenbank nicht transaktional ist, dann ist das gruselig, weil die Daten nicht zuverlässig und nicht genau genug gespeichert werden. Das Versprechen der transaktionalen Datenbanken für Transaktionen wird ja kurz mit „ACID“ bezeichnet:

„Atomic“ bedeutet, dass die Transaktion entweder komplett oder gar nicht ausgeführt wird
„Consistent“ bedeutet, dass die Daten immer in einem konsistenten Zustand sind.
„Isolated“ bedeutet, dass verschiedene gleichzeitig laufende Transaktionen sich nicht gegenseitig beeinflussen.
„Durability“ bedeutet, dass die Daten nach Abschluss der Transaktion garantiert dauerhaft gespeichert sind.

Super, da kann nichts mehr schief gehen. Und Software von Oracle oder IBM ist serienmäßig komplett fehlerfrei, von Microsoft sowieso und bei PostgreSQL bauen die Entwickler der Software, die die Datenbank verwendet, allfällige Fehler der DB-Software selbst noch kurz in der Nacht aus… Aber fairerweise muss man sagen, dass die Kernfunktionalität der Datenbankprodukte tatsächlich recht zuverlässig funktioniert und die nervigen Fehler eher am Rande bei unwichtigen Dingen wie Installern oder Security-Features aufgetreten sind, die hier nicht das Thema sind. 😉

Also gut, man kann also mal annehmen, dass die DB-Software vernünftige Zuverlässigkeit hat. Was ist mit der Hardware? In einem großen Rechenzentrum muss rein rechnerisch immer irgendwo ein Hardwaredefekt sein. Ist aber kein Problem, man baut die Hardware und damit die Datenbankinstallation einfach redundant auf. Und es gibt tolle Mechanismen, die mit erheblichem Aufwand sicherstellen, dass ACID immer noch gilt. Man hat also eine Datenbank, die auf mehreren Rechnern läuft und sich gegen außen wie einer verhält. Eine Transaktion kann auch mehrere dieser Rechner involvieren. Egal was passiert, soll immer ACID-Transaktionalität gelten. Mit „Two-Phase-Commit“ und solchen Werkzeugen kann man das hinbekommen. Zumindest sagt man, dass es in der Praxis zuverlässig funktioniert. Vielleicht bis zu einer gewissen Größe, denn wenn eine einzige Datenbank ein ganzes großes Rechenzentrum beansprucht, kann man sich sicher auf einen hohen Stromverbrauch verlassen, aber mehr will ich dazu hier nicht sagen. Reale Rechenzentren, die transaktionale Datenbanken betreiben, haben erfahrungsgemäß auch viele mehr oder weniger unabhängige Datenbanken am Laufen.

Man kann also mit recht großen ACID-transaktionalen Datenbanken die Unzuverlässigkeit der Hardware recht gut in den Griff bekommen. Das ist nicht billig und es lohnt sich gute Datenbankberater heranzuziehen.

Wie sieht es mit der Applikationssoftware aus? Die wird heutzutage ja oft in Java geschrieben und läuft deshalb in der Sandbox, was ja alle Probleme verhindert, weil die Sandbox unterbindet, dass irgendwas gefährliches gemacht wird… 😉

Ist die Applikationssoftware fehlerfrei? Oder zumindest so fehlerfrei, dass nie mit den Daten etwas schief gehen kann? Vielleicht, wenn man optimistisch ist? Wenn wir schon bis hierher Optimismus aufbauen konnten… Die transaktionale Datenbank ist ein nütziches Werkzeug, wenn man sie mit hinreichend korrekter Software benutzt. Aber das machen wir alle und auf dem Laptop des Entwicklers hat es wirklich funktioniert, es sind halt die Benutzer schuld, die mehrere Requests gleichzeitig abschicken. Was ist mit dem „I“ aus ACID passiert? Ja, die Datenbank macht es schon richtig, aber die Applikation stürzt ab oder erzeugt korrumpierte Daten. Oder verwendet zu kleine oder zu große Transaktionen. Schade…

Nun kommt aber noch die Software- und Systemarchitektur ins Spiel. Man fängt an, ein großes System über mehrere Server zu verteilen, Caching wird verwendet, Teilbereiche der Daten werden über Services angesprochen. Natürlich arbeitet man mit tollen Frameworks und die Datenbank ist für den Applikationsentwickler schon recht weit weg, aber immer noch macht man irgendwo implizit oder explizit schöne Transaktionen auf und beendet sie mit commit oder rollback. Niemand weiß mehr, in welcher Schachtelungstiefe von solchen Methoden, die implizit Transaktionen durchführen, man sich befindet und mit bestimmten Mustern kann man das aus Versehen austricksen, aber so etwas passiert natürlich nicht. Wie sieht es jetzt mit ACID aus?

Kurz gesagt, für reale Applikationen muss man genauer hinschauen, ob ein etwas schwächeres Modell als ACID wirklich ein Nachteil ist.

Nun muss man aber noch einmal auf den Ausgangspunkt zurückkommen. Transaktionen lassen sich sehr gut für nicht-relationale Datenbanken definieren und auch implementieren. Umgekehrt kann man für manche Zwecke durchaus relationale SQL-Datenbanken verwenden, die nicht transaktional sind. Oder man hat wie bei MongoDB Transaktionen für einzelne DB-Operationen, kann diese aber nicht zusammenfassen.

MongoDB im RAM

Hier ist eine interessante Beschreibung, wie man MongoDB (unter Linux) komplett im RAM betreiben kann:

How to use MongoDB as a pure in-memory DB (Redis style)

Die Idee ist einfach und interessant, weil sie sich auch für viele andere, ähnlich gelagerte Anwendungsfälle eignet.

Für die Entwicklung von Mongo-DB-basierenden Applikationen und vor allem für die Unit-Tests kann das auch eine sehr nützliche Sache sein.

Responsive Design

Neu ist dieser Blog mit „responsive design“ ausgestattet. Das bedeutet, dass das Layout sich von selber kleinere Bildschirme von Mobiltelefonen anpasst.

Auch die Seite IT Sky Consulting GmbH hat responsive Design. Dies ist nur mit CSS umgesetzt, die HTML-Seiten existieren nur einmal.

Ein paar Besonderheiten von Linux/Unix-Filesystemen

Unix und in der Folge auch Linux liegt ein gewisses Verständnis darüber zugrunden, wie die Dateisysteme (Filesysteme) funktionieren. Man kann zwar unter Linux auch Filesysteme wie FAT32 einbinden, die diese Eigenschaften nicht haben, sollte das aber nur tun, um Daten mit einem Medium auszutauschen, das auch von anderen Betriebssystemen verwendet wird, nicht aber für die eigentliche Linux-Installation, nicht einmal für das Home-Verzeichnis.

Man hat aber heute eine Vielzahl von guten Filesystemen zur Verfügung, die die benötigten Features haben.

Grundsätzlich ist ein Verzeichnis (engl. Directory) selbst eine spezielle Datei, die die darin vorkommenden Dateinamen und jeweils eine Referenz zu einem sogenannten I-Node (inode) enthält, wo u.a. gespeichert ist, welche Berechtigungen, welche Änderungs- und Zugriffsdaten und welche Größte die Datei hat und wo man deren Inhalte finden kann. Normalerweise sind die Dateien in „Blöcken“ gespeichert, die z.B. 1024 Bytes groß sind, wobei der letzte Block normalerweise nicht vollständig ausgenutzt wird. Zusätzlich benötigt man bei größeren Dateien mit vielen Blöcken eine Struktur, um diese zu finden, die im I-Node selbst keinen Platz hat.

Nun kann man sogenannte „hard-links“ anlegen, z.B. mit ln. Das bedeutet, dass ein I-Node von mehreren Verzeichnissen referenziert wird. Der hard-link und sein
Original sind dabei völlig gleichberechtigt, es gibt keinen Unterschied zwischen dem zuerst vorhandenen Eintrag und dem neuen, als Hardlink angelegten. Deutlich zu unterscheiden ist das von sogenannten Softlinks, die auf einen anderen Verzeichniseintrag verweisen und damit indirekt auf eine Datei, wenn dieser Verzeichniseintrag tatsächlich existiert. Wegen der hard-links kann eine Datei also beliebig oft im Dateisystem eingetragen sein und wenn man sie mit rm löscht, dann wird in Wirklichkeit nur der eine Eintrag im Verzeichnis gelöscht. Nur wenn diese Datei wirklich nirgendwo sonst mehr referenziert wird, wird sie auch selber gelöscht. Dazu führt der I-Node noch einen Referenzzähler.

Was passiert nun, wenn man eine Datei mit einem Programm öffnet und löscht, bevor das Programm beendet ist? Etwa so etwas:

In xterm1:

$ sort grosse-datei.txt > sorted.txt

Und in xterm2 direkt nachdem das sort gestartet wurde, aber bevor es beendet wurde:

$ rm grosse-datei.txt

?
Die Datei wird wirklich aus dem Verzeichnis gelöscht, ist also mit ls nicht mehr zu sehen.

Das „sort“ greift aber über den I-Node darauf zu und hat noch weiterhin zugriff, zählt also auch als eine Referenz in der Zählung. So kann sort seine Arbeit noch beenden, aber kein anderes Programm mehr auf diese „halb-gelöschte“ Datei zugreifen. Man kann das mit df -k erkennen. Sobald das sort fertig ist, wird der Referenzzähler im I-Node heruntergezählt und wenn nicht noch Hardlinks oder andere Programme darauf zugreifen, dann geht er auf 0 runter und die Datei wird wirklich gelöscht, erkennbar mit df.

Vorsicht ist natürlich geboten bei Programmen, die eine Datei zwar lesen, aber dabei eine raffinierte File-Handle-Verwaltung benutzen, also die Datei immer wieder kurz zum Lesen öffnen, ein paar Daten lesen und wieder schließen, um aufwendige Berechnungen mit den Daten zu machen, bis der nächste Lesezugriff erfolgt. Bei so einem Programm würde das Wiederöffnen der Datei in unserem obigen Szenario zu einem Fehler führen, weil die Datei vom System als nicht mehr referenziert erkannt und
definitiv gelöscht worden wäre.

Die typischen Unix/Linux/Posix-Tools wie grep, sort, uniq, cat,…. öffnen aber die betreffende Datei nur einmal und lesen alles sequentiell. Dieses raffinierte Öffnen und Schließen ist eher bei Datenbanksytemen und datenbankähnlicher Software zu üblich.

Wenn man dieses Verhalten kennt, kann man damit viel anfangen, wenn man es nicht kennt, gibt es wohl gelegentlich Überraschungen.

Design-Patterns: Singleton

English

Dieses Singleton-Pattern hat den Vorteil, dass man es sich merken kann und damit beim Thema Design-Patterns dabei ist.

Interessant ist höchstens die Frage der Initialisierung („lazy“ oder „eager“) und vielleicht noch die Frage der Abhängigkeiten, wenn man sehr viele Singletons hat.

Aber ich möchte hier einmal auf zwei Verallgemeinerungen eingehen.

Ein Singleton ist „einmal“ „im ganzen Programm“ vorhanden. Verallgemeinerungen können also bei dem „einmal“ oder bei dem Universum (hier „im ganzen Programm“) ansetzen.

Das „einmal“ auf eine bestimmte endliche Anzahl zu erweitern ist für viele Routine. Bei den Java-Entwicklern nennt sich das enum, aber in anderen Programmiersprachen gibt es oft ähnliche Konstrukte oder man kann sie sich leicht selber aufbauen, indem man die Erzeugung bestimmter Objekte einschränkt und nur für die endlich vielen „enum-Einträge“ Instanzen anlegt und entsprechend erreichbar macht.

Die andere, etwas komplexere Verallgemeinerung setzt bei dem „Universum“ an. Eine Applikation kann verteilt sein oder mehrere parallele Prozesse (nicht nur Threads) verwenden, womit man ein potentiell größeres Universum als beim klassischen Singleton hat. Frameworks kennen so etwas oft und es sind dort Komponenten oder „Beans“ mit „Application-Scope“. Entsprechend gbit es kleinere Universen, zum Beispiel „Session Scope“.

Wenn man also nur diese Komponenten richtig als Verallgemeinerungen des Singleton-Patterns liest, werden diese obskuren Frameworks vielleicht etwas verständlicher und nützlicher. Und die Investion, mal mit diesem einfachen Design-Pattern anzufangen, hat sich gelohnt. Irgendwann werden wir sehen, ob sich noch andere Patterns lohnen… 😉

SSD billiger als magnetische Festplatten?

In der vergangenen Woche war ein interessanter Vortrag bei der Elastic Search User Group in Zürich, vom Gründer der Firma und des Projekts…

Eine Bemerkung war, dass es in typischen Elastic-Search-Anwendungen billiger sein kann, SSDs als magnetische Festplatten einzubauen. Magnetische Festplatten sind natürlich für das gespeicherte Byte viel billiger, aber wenn man Durchsatz in Bytes/sec braucht, seien SSDs billiger.

Ein interessanter Gedanke, erst einmal verwirrend.

Aber man baut letztlich eine Serverfarm auf, um die nötige Leistung zu erbringen. Wenn nun die Hauptaufgabe dieser Server in geschickten Lesezugriffen auf ihren Daten besteht, dann braucht man mit vollständiger Verwendung von SSDs weniger Server. Das könnte kostengünstiger sein. Und gerade für überwiegendes Lesen sind SSDs unumstritten gut.

Mobiltelefon-Betriebssysteme

Heutige Mobiltelefone sind meisten kleine Computer, die abgesehen von den Bedienelementen und der Anzeige etwa dem Stand eines Laptop- oder Desktopcomputers von vor 10 Jahren entsprechen. Das trifft für die sogenannten Smartphones zu, aber wohl auch für einen Teil der nicht als Smartphone bezeichneten Geräte. Witzigerweise gibt es sogar dieselben drei Betriebssysteme, die wir auf Desktoprechnern heute häufig finden, jeweils in Varianten für Mobiltelefone, wobei Linux bei den Mobiltelefonen in Form von Android klar dominiert, was beim Destop ja erst für 2014 erreicht werden könnte ;-), während das MS-Windows-Phone im Gegensatz zu seinem großen Bruder auf dem Desktop eher eine Randerscheinung ist.

Nokia war Anfang 2011 mit Symbian Marktführer und hatte mit Maemo und Meego aussichtsreiche Systeme in der Entwicklung, um diesen Stand zu halten, hat sich aber selbst abgeschossen bzw. ist vom Management versenkt worden und jetzt nur noch ein unbedeutender Nischenanbieter für diejenigen, die gerne ein MS-Windows-Mobiltelefon haben wollen und dieses nicht von einem der ostasiatischen Anbieter kaufen. Die Entwicklungsabteilungen sind 2011 weitgehend abgewickelt worden, aber vielleicht ist das auch eine Chance für innovative Startup-Firmen, die in Finnland und anderen ehemaligen Nokia-Standorten sehr gute Entwickler für Mobiltelefone und Mobiltelefonsoftware finden können. Eine solche Startup-Firma ist Jolla, die das ehrgezeige Ziel verfolgen, mit einem kleinen Teil der ehemaligen Nokia-Entwickler an die Tradition dieser Firma anzuknüpfen und die besten Mobiltelefone zu bauen. Ob das ein Erfolg wird, werden wir sehen, es ist sicher noch zu früh, darüber etwas zu sagen. Und was die besten Telefone sind, darauf gehe ich weiter unten noch kurz ein.

Blackberry (bzw. damals als Firma noch RIM) hatte für ein Marktsegment ein gutes Telefon mit einem Gesamtkonzept angeboten und für den Zweck, EMails zu schreiben, sind diese Geräte mit einer echten Tastatur wohl immer noch den reinen Touch-Screen-Geräten von Samung, HTC und Apple überlegen, aber ihr Marktanteil ist trotzdem zurückgegangen. Waren „Coolness“ und „Mode“ und die bessere Spielesammlung wichtiger als ein zweckmäßiges Arbeitsgerät? Oder reicht es in der Regel, die Mails unterwegs lesen zu können? Wir werden sehen, ob die neuen Blackberry-Geräte nach dem „Relaunch“ diesen Trend aufhalten können.

Android ist sicher im Moment mit großem Vorsprung Marktführer, was Apple mit iOS trotz Hype nie war und wahrscheinlich auch nicht mehr werden wird, weil sie ihren Zenit schon überschritten haben und jetzt auf dem absteigenden Ast sind. Wir werden in ein paar Jahren sehen, ob Apple es schafft, sich als Nischenanbieter zu stabilisieren. Man weiß nicht, was die Zukunft bringt, aber es lässt sich doch heute erkennen, dass Leute, die Android und iOS-Telefone (oder sagen wir Samung- und Apple-Geräte?) kennengelernt haben, meistens die Android-Geräte präferieren. Den „Coolness“-Faktor haben heute selbst in der sehr Apple-orientierten Schweiz eher die Top-Android-Geräte. Da nun das Apples Geschäftsmodell mit dem App- und Musikstore sehr auf einen Massenmarkt fixiert ist, wird es spannend, wie es sich auswirken wird, wenn der Rückgang nicht nur in Marktanteilprozenten, sondern auch in absoluten Zahlen spürbar wird. Aber es ist ja gut, dass wir eine gewisse Vielfalt und damit einen Wettbewerb der Systeme haben.

Auf der Linux-Seite gibt es übrigens noch andere Systeme außer Android, die interessant werden können. Fast zu viele, könnte man sagen. Maemo ist auf dem Nokia N900 eingesetzt worden, mir sind aber keine zukünftigen Mobiltelefon-Projekte bekannt, die Maemo verwenden wollen. Meego war ein gemeinsames Projekt von Nokia und Intel, das auf dem N9 zum Zuge kam und für das es gerüchteweise Entwicklungen bei Nokia gab, um recht „kleine“ Smartphone zu bauen, die relativ wenig kosten, wenig Strom verbrauchen oder nicht so schwer und groß im Gepäck sind, aber diese Entwicklungen sind alle eingestellt worden, bevor die ersten Geräte damit erschienen sind, deshalb werden es wohl Gerüchte bleiben. Meego selbst wird wohl von keinem großen Anbieter mehr verfolgt, aber daraus sind Tizen, das Samsung in Zukunft verstärkt einsetzen möchte, und Sailfish von Jolla entstanden. Nun gibt es noch ein Ubuntu-Derivat für Mobiltelefone, Ubuntu Mobile, FirefoxOS und vielleicht noch WebOS. Eine schöne Sammlung an Systemen und wer noch ein altes Zweit-Smartphone hat, kann vielleicht sogar ein paar von diesen Systemen ausprobieren. Vielleicht mache ich das selber auch einmal, dann wird es hier Erfahrungsberichte gbeben…

Da die allermeisten Anwender, zu denen ich mich auch zähle, das Betriebssystem nutzen, das mit dem Telefon ausgeliefert wird, ist die Frage also auch, was die Gerätehersteller so anbieten werden. Vielleicht wird es aber auch wie bei Desktop- und Laptop-Computer Angebote geben, die nur die reine Hardware verkaufen und dem Benutzer die Wahl lassen, welches der Systeme darauf installiert wird? Wenn sich für die Entwicklung von Mobiltelefonapplikationen HTML5 weitgehend durchsetzt, wird es auch kein Nachteil mehr sein, eine seltene Plattform zu haben. Zumindest von Sailfish weiß ich aber auch, dass sie auch die Möglichkeit vorsehen, Android-Apps zu installieren und auszuführen, was vielleicht nicht so schwierig ist, da ja beides Linux-basierte Systeme sind, allerdings ist die Grafikschicht wohl sehr verschieden, was doch noch eine größere Hürde sein könnte. Interessant ist noch, dass der Linux-Kernel bei diesen Systeme praktisch derselbe Linux-Kernel ist, der auch auf größeren Systemen bis zu den größten Supercomputern läuft, abgesehen von kleineren Unterschieden bedingt durch die Prozessorarchitektur und die Versionsnummern. Wie es bei iOS und MS-Windows-Phone ist, ob diese Systeme viele Gemeinsamkeiten mit ihren großen Brüdern MacOS X und MS-Windows haben oder nur kleine Teile gemeinsam nutzen und einfach gemeinsam vermarktet werden, weiß ich nicht.

Welches System ist nun das beste? Ich denke, dass das jeder selber entscheiden möchte. Die Grundfunktionen, die man eigentlich braucht, können alle. Das sind gar nicht viele:

Telefonieren
SMS (ja, dafür gibt es Flatrates)
Licht, um ein Schild zu lesen oder ein Zahlenschloss zu öffnen oder so
Fotografieren (ja, da gibt es Unterschiede, Nokia soll mit dem am besten gewesen sein)
Musik hören
EMails lesen und schreiben (beim Schreiben sind Geräte mit physikalischer Tastatur wie Blackberry oder N900 im Vorteil)
Webseiten lesen, Webapplikationen verwenden (das können alle)
Landkarten und Navigation (da ist Android gut, Nokia war noch etwas besser und Apple will und wird das auch irgendwann einmal können)
Kalender
Uhr
Wecker

Und natürlich braucht man noch sehr viele Apps, was ich auf dem N900 auch habe, obwohl das ein eher seltenes System ist. Ja, einige Apps sind schon schön zu haben, wie zum Beispiel die SBB-App oder das Äquivalent von der deutschen Bahn, die man nur für Android und iOS bekommt, aber dort helfen auch die entsprechenden Web-Applikationen ganz gut weiter. Aber wenn man die Unmengen an Apps anschaut und diejenigen, deren Funktion sich gut durch vorhandene Webapplikationen ersetzen lässt oder die nicht wirklich viel bringen, aussortiert, bleiben sicher ein paar interessante Apps übrig, die man vielleicht sogar in die obige Liste hinzufügen möchte. Man kann sich noch überlegen, ob man Freude daran hat, Firmen zu unterstützen, die durch exzessive Patentklagen auf sich aufmerksam machen, zum Teil mit Trivialpatenten, wie man sie nur in den Vereinigten Staaten bekommen kann. Oder Firmen, die bei Einkäufen mit dem Mobiltelefon, die mit einer App getätigt werden, 30% vom Umsatz einsammeln, was mehr als Wucher ist. Ich denke, dass man ähnlich wie man in der EU einem großen Betriebssystemanbieter das Bundling von OS und Browser eingeschränkt hat, auch den Herstellern von Mobiltelefonen und Mobiltelefonbetriebssystemen abverlangen könnte, dass sie es dem Anwender ermöglichen, einen anderen App-Store und einen anderen Musik-Store zu verwenden als den vom Systemanbieter betriebenen.

Letztlich ist es wie bei Kleidung überwiegend eine subjektive Entscheidung, welches Mobiltelefon und welches zugehörige Betriebssystem man bevorzugt und deshalb auch schwierig, darüber zu diskutieren, welches besser ist. Welche Kleidung wird primär mit technischen Eigenschaften wie z.B. der Reißfestigkeit verkauft?

Versionsverwaltung

Versionsverwaltung (englisch „Source Code Management“ oder „Revision control“) ist für Software-Entwicklung, aber zunehmend auch für andere Bereiche in der Informatik nicht nur nützlich, sondern geradezu unentbehrlich. Vielleicht das erste derartige System war SCCS, das durch das von Walter Tichy entwickelte RCS ersetzte aber fast SCCS vollständig. RCS mag noch eine gewisse Existenzberechtigung haben, wenn man lokal einzelne Dateien versionieren will und dies schon seit langer Zeit mit RCS macht, aber die Einschränkungen waren doch erheblich: RCS funktionierte nur innerhalb des Dateisystems. Mittels NFS oder SMB kann man zwar gemeinsame Dateisysteme mounten oder als Netzwerklaufwerke verbinden, aber die Restriktion war letztlich störend und unnötig. Außerdem konnte man nur einzelne Dateien, nicht aber Verzeichnisse und Gruppen von Dateien verwalten. Gewisse Wrapper wie z.B. SNiFF+ oder MKS versuchten diese Einschränkungen teilweise zu umgehen, letztlich war aber die auf der Basis von RCS entstandene Neuentwicklung CVS die bessere Lösung. Auch wenn CVS heute längst obsolet ist. Etwa gleichzeitig kam ClearCase auf, ein ebenfalls heute nicht mehr empfehlenswertes System. Sowohl CVS als auch ClearCase haben aber Konzepte eingeführt oder populär gemacht oder auch nur getestet, die man für heutige Versionsverwaltungssysteme verwendet oder auch für überflüssig erkannt hat, man konnte auch wieder aus den Schwächen dieser Systeme lernen. CVS hat keine Konsistenz sichergestellt, das heißt, dass bei einer Änderung, die mehrere Dateien umfasst, jemand, der zeitnah mit dem Einfügen der Änderungen ins CVS daraus liest, unter Umständen eine nicht lauffähige Mischung aus alt und neu erhält. Das Umbenennen und Verschieben von Verzeichnissen und Dateien, insbesondere in der Java-Welt als „Refactoring“ bekannt und populär, wird sehr schlecht unterstützt bzw. durch das Löschen und Neuanlegen behelfsmäßig abgebildet. Und binär-Dateien werden schlecht unterstützt. ClearCase hat zusätzlich noch weitere Nachteile: Es ist sehr langsam, unzuverlässig und braucht einen hohen Administrationsaufwand. Außerdem waren die Lizenzen einmal sehr teuer, was aber heute egal sein sollte, da es keinen vernünftigen Grund gibt, neue Projekte mit ClearCase anzufangen und bei vorhandenen Projekten die Lizenzierung gelöst und bezahlt sein sollte. Immerhin macht einem der Lizenz-Manager noch zusätzlich gelegentlich das Leben schwer. MS-VisualSourceSafe habe ich eine zeitlang sporadisch benutzt und es war etwa zwischen RCS und CVS anzusiedeln, soll aber durch ein besseres TFS ersetzt worden sein, das ich nicht kenne.

Nun kommen wir zu den Systemen, die man heute noch benutzen kann, auch ohne durch Altlasten dazu gezwungen zu sein. Ein Ersatz für CVS war SubVersion, das die wesentlichen Schwächen von CVS behebt. Wenn auch durchaus Linus‘ Torvalds Kommentar dazu bedenkenswert ist: „SubVersion is CVS done right, but CVS can’t be done right“ oder so ähnlich, z.B. in diesem Tech Talk von 2007. Git hat ein funktionierendes verteiltes Repository gebracht. Das bedeutet, dass man sogar ohne Netzwerkverbindung noch mit dem immer vorhandenen lokalen Repository arbeiten kann, dass „Backups“ einfach durch die Vielzahl der Repositories „passieren“, sogar ohne dass man sie explizit durchführt (was man natürlich trotzdem tun sollte) und dass die parallele Arbeit von sehr vielen Entwicklern an verschiedenen Orten erleichtert wird. Ein Problem ist dabei sicher die Benennung von Versionen, wenn man nicht von einem zentralen „Zähler“ abhängig sein will. Für Google mag es sinnvoll sein, in vielen größeren Rechenzentren eine Atomuhr aufzustellen, so dass man recht zuverlässige Zeitstempel hat, aber mein Laptop ist offline doch schon einmal etwas ungenau mit seiner Uhrzeit. Git verwendet eine SHA1-Prüfsumme von 128 Bit Länge, die ihren Zweck einigermaßen zuverlässig erfüllen, weil es schwierig ist, eine Datei zu konstruieren, die denselben Prüfsummenwert liefert, selbst wenn man es gezielt versucht. Mercurial und vielleicht auch Bazaar sollen ähnliche Features wie git bieten und es ist teilweise eher eine Geschmacksfrage, welches dieser Systeme man verwendet. Vielleicht hat git einen kleinen Vorteil wegen der hohen Verbreitung und wegen github.

Kurze Zusammenfassung: Subversion ist nicht schlecht, man kann das für kleine Projekte nehmen oder es beibehalten, wenn es in vorhandenen Projekten eingesetzt wird. Aber für neue Projekte oder für Projekte, die heute auf CVS, ClearCase oder anderen veralteten Versionsverwaltungssystemen entwickelt werden, empfehle ich, git, mercurial oder eventuell bazaar einmal genauer anzuschauen und auf eines dieser Systeme zu wechseln. Grundsätzlich sind die sicher alle gut, aber man kann sagen, dass sich git durchgesetzt hat, weshalb es wohl die beste Wahl darstellen dürfte, weil es alle kennen, weil es dafür Infrastruktur gibt u.s.w..

Auch wenn diese Versionsverwaltungssysteme primär für Software-Quelltexte gemacht sind, kann man sie auch für andere Dateien einsetzen. Allerdings gibt es auch Software, die implizit eine Versionsverwaltung enthält, zum Beispiel Wikis wie MediaWiki oder ECM-Systeme oder Dokumentenmanagementsysteme wie z.B. OpenText oder SharePoint, wo die Versionsverwaltung nur einen Teil der angebotenen Funktionalität ausmacht. Für die Details würde ich Experten für ECM-Systeme fragen…

Es wird noch interessant, ob uns die Zukunft noch neue interessante Versionskontrollsysteme mit neuen Konzepten bringt oder ob die Generation von Git uns jetzt für eine sehr lange Zeit begleiten wird.