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 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 inode selbst keinen Platz hat.

Nun kann man sogenannte „hard-links“ anlegen, z.B. mit ln. Das bedeutet, daß ein inode 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 inode 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 inode 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 inode 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.

Share Button

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… 😉

Share Button

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, daß 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.

Share Button

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äßt sich doch heute erkennen, daß 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, daß 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, daß 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, daß 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, daß 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 Zahlenschloß 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äßt 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, daß man ähnlich wie man in der EU einem großen Betriebsystemanbieter das Bundling von OS und Browser eingeschränkt hat, auch den Herstellern von Mobiltelefonen und Mobiltelefonbetriebsystemen abverlangen könnte, daß 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?

Share Button

Versionsverwaltung

Versionsverwaltung (englisch „Source Code Management“ oder „Revision control“) ist für Software-Entwicklung, aber zunehmened 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 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, daß bei einer Änderung, die mehrere Dateien umfaßt, 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 Lizensierung 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, daß man sogar ohne Netzwerkverbindung noch mit dem immer vorhandenen lokalen Repository arbeiten kann, daß „Backups“ einfach durch die Vielzahl der Repositories „passieren“, sogar ohne daß man sie explizit durchführt (was man natürlich trotzem tun sollte) und daß 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 daß 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.

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 und Mercurial uns jetzt für eine sehr lange Zeit begleiten wird.

Share Button