Leserbriefe

Pardon, aber als sich der Autor bereits im einleitenden Text zu der Aussage verstieg, Mercurial benötige zentrale Repositories, wünschte ich mir kurz eine flüssigkeitsresistente iX-Ausgabe. Aber nichts, was sich nicht mit etwas Küchenpapier trocknen ließe.

Nicht nur, dass Mercurial zum Zeitpunkt des ersten Release von Git noch keinen ersten Release zu bieten hatte und daher als Grund für Herrn Torvalds’ „Störung“ nicht taugt, sondern es handelt sich dabei ebenso wie bei Git um eine dezentrale Versionsverwaltung. In der Tat begann die Entwicklung von Git und Mercurial fast zeitgleich und aufgrund des gleichen Ereignisses: BitKeeper war nicht mehr als VCS für den Linux-Kernel verfügbar.

Auch wenn Git-Verfechter nach wie vor den Mythos befeuern, Git habe mehr Features als Mercurial, sind Argumente, die dies stützen, bestenfalls als obskur zu bezeichnen. Aber bei Mercurial muss man fortgeschrittene Features in der Tat meist in Form von Erweiterungen aktivieren, während man sich bei Git auch als blutiger Anfänger sofort in den Fuß schießen darf. Eines kann ich allerdings konstatieren: Nach Jahren der Nutzung beider Versionsverwaltungen sowie CVS und Subversion bevorzuge ich Mercurial mit deutlichem Vorsprung. Denn um Mercurial zu benutzen, muss man kein GUI benutzen, das nicht vorhandene Glossar zu den vielen Man-Pages gelesen haben oder einen Abschluss in Gitologie haben.

Der vermeintliche Siegeszug von Git scheint mir eher ein Siegeszug von GitHub allein zu sein. Die Repositories zahlreicher quelloffener Projekte allesamt bei einem kommerziellen und zentralen Anbieter – das könnte eine neue Definition für Ironie werden.

Wann immer ich Freunde, Kollegen und Bekannte frage, warum sie Git benutzen, heißt es entweder „wegen GitHub“ oder weil ihnen „Git ausreicht“. Problem: GitHub ist nicht Git, sondern benutzt Git. Und dass Git ausreicht, stellt sich beim Nachhaken immer als Arbeitsweise heraus, bei der man ohnehin nur die grundlegendsten Git-Befehle benutzt und beherrscht und im Zweifelsfall halt neu klont und von vorn beginnt, falls etwas schiefgeht. Wenn ich auf der Kommandozeile Mercurial um Hilfe bitte, kommt immer etwas Nützliches zurück. Versuche ich das mit Git, lande ich wahlweise in der Man-Page irgendeines Unterbefehls oder es öffnet sich ein Browserfenster mit der HTML-Version besagter Man-Page (auf Windows).

Nomen est omen. Für mich ist Git der Inbegriff eines benutzerunfreundlichen Programms. Der besagte Siegeszug ist ein Pyrrhussieg, wenn anscheinend die Mehrheit der Benutzer nicht einmal über die grundlegendsten Git-Befehle hinauskommt oder direkt die von GitHub oder anderen Anbietern bereitgestellten GUIs verwendet, welche allenfalls die Nutzung eines Bruchteils der Befehle und Funktionen ermöglichen.

Ich nehme an, dass der Bezug zu Mercurial auch der Grund war, warum BitBucket verschwiegen wurde, welches wie GitLab auch für private Repositories kostenlos verfügbar ist und viele zu GitHub vergleichbare Features aufweist. Immerhin ist BitBucket eine vollständige Lösung für Git von vergleichbarem Umfang wie die vorgestellten – allein, es unterstützt zusätzlich noch Mercurial-Repositories.

Es ist keine Schande, für Git Partei zu ergreifen. Am Ende ist es ja auch eine Geschmacksfrage, welche Versionsverwaltung man bevorzugt. Aber dann sollte die Recherche zu den Konkurrenten (von Git) und den Alternativen (zu GitHub) vielleicht etwas gründlicher ausfallen.

Oliver Schneider, via E-Mail

Leser Schneider hat Recht: Mercurial nutzt kein zentrales Repository, sondern ein dezentrales wie auch Git (d. Red.).

Ich lese iX nicht regelmäßig. Aber wegen dieses Artikels habe ich mir mal wieder eine Ausgabe gegönnt und es nicht bereut. (Es ist auch noch ein recht interessanter Teil über TOR und das Darknet drinnen …)

Ähnlich wie die Autoren bin auch ich der Ansicht, dass man kein System betreiben sollte, in dem der Webbrowser vom Hauptsystem aus ins Internet kann. Mail ähnlich. Ideal finde ich physische Trennung, aber wie im Artikel angesprochen ist das schon sehr unpraktisch, je einen Rechner für Aufgaben wie Office, Mail, Web … zu administrieren und ggf. mit sich rumzutragen.

Erwähnt wird eine Firma „purism“, die vorkonfigurierte Notebooks mit Qubes OS anbietet – und das war dann doch eine Enttäuschung. Das teuerste Modell kommt mit einem Zweikerner (!) daher und maximal 16 GB RAM. Für ein System, das auf heftige Virtualisierung setzt, eine ziemlich erbärmliche Maximalausstattung, finde ich. Und: Tastaturlayout nur US/Englisch.

So sehr ich Qubes OS also nach der Lektüre des Artikels faszinierend finde, der sicherheitsbewusste Anwender ist wahrscheinlich mit einem Gerät seiner Wahl und einer eigenen Virtualisierung (VMware, Parallels, VirtualBox, was auch immer) besser bedient, auch wenn Qubes OS tatsächlich viel mehr bietet – z. B. kann man dem Hostsystem die Netzwerkkarte wegnehmen und die VMs trotzdem ins Internet lassen!

Letztlich, so traurig das ist, müsste man zumindest Web und Mail auf eigenen Maschinen betreiben, die man vom Hauptrechner aus bestenfalls fernsteuert. Es zeigt sich halt einmal mehr, dass eine Infrastruktur, die per Design fehlerhaft ist und noch dazu in einer Gesellschaft, in der sich die Staaten wie Kriminelle verhalten, weil sie sich deren Methoden bedienen wollen und daher aktiv zu weiterer Unsicherheit beitragen, eigentlich nicht durch technische Methoden repariert werden kann.

Das Internet, wie wir es heute haben, gehört abgestellt und mit den Erkenntnissen aus den letzten 20 Jahren ein neues System geschaffen, das von der Basis weg als sicher in allen Aspekten designt wird – also vollkommen vertrauliche Kommunikation ebenso zum Standard macht wie die Sicherheit vor Schadwirkungen und natürlich die Unantastbarkeit der Privatsphäre und der Datenhoheit des Nutzers über seine Daten.

Daran haben aber leider weder die Werbeterror-Netzwerke, die Konzerne noch die sicherheitshysterischen Überwachungs- und Polizeistaaten dieser Welt ein Interesse.

diwh, aus dem iX-Forum

Vielen herzlichen Dank für diesen informativen und motivierenden Artikel! Benutze Python seit ein paar Jahren sporadisch und bin ein großer Fan dieser Programmiersprache. pyenv war neu für mich.

Obwohl wxPython in letzter Zeit etwas aufholt, habe ich die Erwähnung aktuellerer, stabilerer UI-Bibliotheken (wie kivy oder PyQt/PySide) vermisst.

Wünsche mir für die Zukunft mehr Python-Artikel, zum Beispiel gerade über die aktuellen Python-Bibliotheken und -Distributionen Anaconda und ActiveState.

Andreas Ecker, via E-Mail