Linux verstehen: die Wiederentdeckung der Freude an Technologie

Seit Windows 10 verlieren Nutzer mehr und mehr die Kontrolle über ihre Systeme. Das Schlüsselwort ist Governance (oder besser Bevormundung), wo Unternehmen versuchen, ihre Nutzer zu erziehen. Keine Sorge, ich werde keine große Rede über die Willensfreiheit und die bösen Tech-Unternehmen halten. In diesem Artikel gebe ich Ihnen die Möglichkeit, die Kontrolle über Ihr Computergerät zurückzugewinnen. Verabschieden Sie sich von Microsoft und Windows und beginnen Sie Ihre Reise mit Linux.

Um das Jahr 2015 herum fasste ich den Entschluss, mich von Microsoft Windows zu lösen und zu 100% auf Linux umzusteigen. Ich hatte zu diesem Zeitpunkt bereits einige Erfahrungen mit Linux auf der Serverseite. Aber Linux täglich auf dem Desktop für alle Aufgaben zu verwenden, war eine neue Herausforderung, denn die Dinge sind nicht gleich. So verbrachte ich rund 4 Wochen und mehrere Versuche damit, eine Linux-Desktop-Distribution zu finden, die am besten zu meinen Bedürfnissen passt. Die Dinge, auf die man achten muss, um das beste Ergebnis für sich selbst zu erzielen, sind die Verfügbarkeit eines riesigen Software-Repositorys, aus dem man alle Anwendungen beziehen kann, die man braucht. Ein weiterer wichtiger Punkt ist das Aussehen und die Bedienung des Desktops. Auch hier gibt es mehrere Optionen, aus denen man auswählen kann. Bevor ich einen kurzen Überblick über Distributionen und Desktops gebe, muss ich das Problem der Softwareversionen und Repositories erklären.

Ein Software-Repository ist einfach ein großer Speicher, in dem die Binärdateien und Installationsprogramme für Ihre Anwendung abgelegt sind. Wenn Sie sich für eine Distribution und eine bestimmte Version entschieden haben, haben Sie ein definiertes Repository, in dem Sie Ihre Software und Distributions-Updates erwerben können. Nehmen wir an, wir haben eine Linux-Distribution mit einer Version von 2019. Der Support für diese Version läuft, sagen wir mal, bis 2020. Das bedeutet für das Software-Repository, dass die enthaltene Software nur einen Stand aus dieser Zeit enthält. Wenn Sie für diese Distribution die neueste GIMP-Version wie 2.10.36 vom November 2023 haben möchten, können Sie diese nicht aus dem ursprünglichen Distribution Repository beziehen. Die letzte Softwareversion für GIMP im ursprünglichen Repository ist die Version von 2020. Das gleiche Problem besteht bei älteren Softwareversionen. Dies ist ein sehr spezifisches Problem für Softwareentwickler und verfügbare Programmiersprachen. Wenn Sie alte PHP- oder JAVA-Anwendungen pflegen müssen, benötigen Sie ganz bestimmte Compiler und Interpreter, die möglicherweise nicht in Ihrem Software-Repository enthalten sind. Um dieses Problem zu lösen, gibt es verschiedene Lösungen. Entwickler können zum Beispiel Docker verwenden. Als normaler Benutzer können Sie versuchen, ältere oder neuere Versionen einer Software direkt vom Entwickler/Hersteller zu erhalten. Mit diesem Wissen können wir nun lernen, was eine Distribution ist und welche davon existiert.

Wenn Sie eine Linux-Distribution oder kurz Distro für sich auswählen möchten, haben Sie eine riesige Auswahl. Aber was ist eine Distro? Im Allgemeinen kann man sagen, dass ein Hersteller einen Linux-Kernel, eine Sammlung von Software und ein Repository zusammenstellt und alles mit seinem eigenen Look and Feel dekoriert. Es ist auch möglich, dass man sein eigenes Linux erstellt, einschließlich der Kompilierung eines eigenen Kernels. Aber Linux ist nicht gleich Linux. Wir müssen zwischen Linux und Unix unterscheiden. Linux ist ein Derivat von Unix, wie der Name LinUx eine Kombination aus Linus und Unix bereits vermuten lässt. Der große Unterschied zwischen Linux und Unix besteht in der Netzwerkfunktionalität, die bei Unix weiter fortgeschritten ist. Das Betriebssystem (BS) von Apple basiert beispielsweise auf Unix. Ein sehr verbreitetes Unix-Betriebssystem ist FreeBSD. BSD bedeutet Barkley Software Distribution und wird von der Barkley Universität in Kalifornien kontinuierlich weiterentwickelt.

0
Rate your favorite Linux Distribution

Daneben gibt es drei Haupt Linux-Zweige, die auch weitere Ableitungen enthalten. Als erstes gibt es das aus Deutschland stammende Suse mit dem YAST Paketmanager für den Zugriff auf die Software-Repositories. Suse 7.2 war übrigens mein erster Desktop-Test im Jahr 2002. Suse ist nicht so verbreitet. Deswegen ist es manchmal recht schwierig, für spezielle Fragen oder Probleme ausreichend Inhalte zu finden. Eine weitere Distribution kommt von Red Hat, einem Open-Source Pionier. RHEL oder Red Hat Enterprise Linux ist eine kommerzielle Linux-Serverdistribution. Der Grund dafür ist, dass ein kommerzielles Linux für Server-Produktivsystemen vorhanden ist. Mit einer RHEL-Lizenz erhalten Unternehmen von Red Hat professionelle Unterstützung in Notfällen. Der Red Hat Desktop wird nicht mehr unterstützt und wurde auf Fedora Linux gewandelt. Der Standardpaketmanager für deren Software-Repositorys ist YUM. Der letzte Zweig der wichtigsten Linux-Distributionen ist Debian mit einer großen Auswahl an Unterdistributionen. Alle beliebten Einsteiger-Distributionen wie Linux Mint, Ubuntu oder Zorin OS basieren auf Debian. Als ich 2015 auf den Linux-Desktop umgestiegen bin, habe ich mit Ubuntu Mate LTS angefangen und bin seit Ende 2023 auf Debian 12 mit einem Gnome 3-Desktop umgestiegen. Der Standardpaketmanager für Debian-Systeme ist APT. Ubuntu führte 2023 seinen eigenen SNAP Paketmanager ein.

Ein weiterer wichtiger Begriff im Linux-Universum ist der Desktop-Manager. Hier stehen zur Auswahl: KDE, Gnome, Mate, XFCE und Cinnamon. Wie meine Liste der Distributionen ist auch die Liste der verfügbaren Desktops nicht vollständig. Ich kann im Unfang dieses Artikels nur die häufigsten erwähnen. Die meisten Linux-Distributionen verfügen standardmäßig über mehrere Desktop-Manager. Sie können daher während des Anmeldevorgangs auswählen, welchen Desktop Sie verwenden möchten. So können Sie ganz einfach ausprobieren, welcher Desktop am besten zu Ihnen passt. Später, wenn Sie mehr Erfahrung haben und Ihre Wahl für Ihre tägliche Arbeit bereits getroffen haben, können Sie unerwünschte Desktops während des Installationsvorgangs abwählen, um etwas Speicherplatz zu sparen.

Das schwierigste am Anfang meines Linux-Abenteuer war es zu verstehen, wo die Dinge gespeichert werden. Beispielsweise wird Software von Drittanbietern normalerweise im Verzeichnis opt installiert. Kompliziert ist auch das Berechtigungssystem für Dateien und Verzeichnisse auf ext3/ext4. Dieses Konzept existiert nicht im Windows FAT- oder NTFS-Dateisystem. Aber keine Sorge das bekommt man recht schnell bei der täglichen Arbeit in den Griff.

Microsoft Surface 3 PRO mit Ubuntu Linux

Als ich zum ersten Mal Ubuntu ausprobierte war das etwa 2010 als der Herstelle Canonical standardmäßig den UNITY Desktop einführte. Es gefiel mir nicht, weil es viel Werbung und unerwünschte Apps wie Spotify und Facebook enthielt. Ich habe herausgefunden, dass Ubuntu eine Version mit einem Gnome Dektop-Klon namens Mate hat. Ich beschloss diesen auszuprobieren und war vom ersten Moment an begeistert. Nach der ersten Installation auf meinem Laptop im Jahr 2015 musste ich bis 2023 nur noch 2 Mal Ubuntu neu auf meinem System installieren. Der Grund dafür war, dass ich meine interne SSD zunächst gegen 1 TB und später gegenuna historia sobre el 2 TB ausgetauscht habe. Es gab keine Probleme, dass die Systeme langsamer wurden oder die Festplatte mit verwaisten Dateien zugemüllt wurde. Keine regelmäßigen Reinigungs- und Wartungsaufgaben wie sie unter Windows üblich sind. Das System funktionierte stabil und ohne schwerwiegende Abstürze. Ich hatte auch nie Probleme mit Hardwaretreibern. Alle meine neuen Komponenten wurden unter Linux immer korrekt erkannt und es gibt oft kleine Verwaltungstools. Zum Beispiel Stremdeck UI oder Noson für Sonos Lautsprecher. Als ich im Dezember 2023 meinen neuen Laptop bekam beschloss ich, von Ubuntu auf das Original Debian umzusteigen. Weil Ubuntu von einem Unternehmen gemacht wird und sie oft beschließen ihren eigenen Weg zu gehen. Wer weiß ob sie in Zukunft ein ähnliches Verhalten wie Microsoft an den Tag legen werden. Ich bevorzuge es meinen Übergang immer frühzeitig zu vollziehen ohne Druck, um vorbereitet zu sein bevor mir keine andere Wahl bleibt.

Natürlich verwende ich auf meinem System ein Antivirenprogramm und eine Firewall. Da Linux nicht vor bösen Angriffen geschützt ist, sind auch Schutzmaßnahmen erforderlich.

Viele Leute vermasseln den Wechsel von Microsoft Office zu Libre Office. Das wirkliche Geheimnis um das Layout nicht zu verlieren besteht darin, auf die Schriftarten zu achten. Wenn die MS Office-Originaldokumente die standardmäßigen Microsoft-Schriftarten verwenden, müssen diese auch auf dem Linux-Computer installiert sein. So wird das Layout des Office-Dokuments nicht zerszört.

Für mich besteht keine wirkliche Notwendigkeit, zu Windows zurückzukehren. Nun ja, ich bin auch kein Gamer aber auch dafür gibt es viele Lösungen. Steam ist zum Beispiel unter Linux verfügbar. Die meisten Leute, die ich kenne, spielen nicht einmal mehr auf PCs oder Laptops, sondern bevorzugen Konsolen wie PlayStation. Für mich ist Linux cool, weil ich die volle Kontrolle über mein System habe, es kostenlos ist und ich es nach meinen Wünschen anpassen kann. Wer einen alten Laptop besitzt, der mit Windows nicht mehr funktioniert kann versuchen Linux darauf zu installieren und das Ergebnis genießen.

Tschüß Privatsphäre, Tschüß Freiheit

Je öfter wiederholt werden muss wie gut unsere Meinungsfreiheit ist um so weniger können wir...

Arbeiten mit Textdateien auf der Linux-Shell

Die Kommandozeile ist unter Linux ein mächtiges Werkzeug. In diesem Artiekl lernen Sie verschiedene Helferlein...

Arbeiten mit Textdateien auf der Linux-Shell

Linux entwickelt sich mehr und mehr zu einem beliebten Betriebssystem für IT-Profis. Einer der Gründe für diese Entwicklung sind die Serverlösungen. Stabilität und geringer Ressourcenverbrauch sind einige der wichtigsten Eigenschaften für diese Wahl. Wer schon einmal mit einem Microsoft Server herumgespielt hat, wird den grafischen Desktop bei einem Linux Server vermissen. Nach dem Einloggen in einen Linux Server siht man nur die Kommandozeile, die auf Eingaben wartet.

In diesem kurzen Artikel stelle ich einige hilfreiche Linux-Programme zur Umgang mit Text Dateien auf der Kommandozeile vor. Auf diese Weise lassen sich leicht Informationen sammeln, zum Beispiel aus Protokolldateien (Logfiles). Bevor ich beginne, möchte ich noch einen einfachen und leistungsfähigen Editor namens joe empfehlen.

Strg + C – Abbrechen der aktuellen Bearbeitung einer Datei ohne Speichern der Änderungen
Strg + KX – Beenden der aktuellen Bearbeitung und Speichern der Datei
Strg + KF – Text in der aktuellen Datei suchen
Strg + V – Einfügen der Zwischenablage in das Dokument (CMD + V für Mac)
Strg + Y – Aktuelle Zeile an der Cursorposition löschen

Um joe auf einer Debian-basierten Linux-Distribution zu installieren, müssen Sie nur folgendes eingeben:

1. Wenn Sie Inhalte in einer großen Textdatei finden müssen, ist GREP Ihr bester Freund. Mit GREP können Sie nach Textmustern (Pattern) in Dateien suchen.

gerp <pattern> file.log
    -n : number of lines that matches
    -i : case insensitive
    -v : invert matches
    -E : extended regex
    -c : count number of matches
    -l : find filenames that matches the pattern
Bash

2. Wenn Sie Netzpakete analysieren müssen, ist NGREP das Werkzeug Ihrer Wahl.

ngrep -I file.pcap
    -d : specify the network interface
    -i : case insensitive
    -x : print in alternate hexdump
    -t : print timestamp
    -I : read a pcap file
Bash

3. Wenn Sie die Änderungen zwischen zwei Versionen einer Datei sehen wollen, ist DIFF genau das Richtige für Sie.

diff version1.txt version2.txt
    -a : add
    -c : change
    -d : delete
     # : line numbers
     < : file 1
     > : file 2
Bash

4. Manchmal ist es notwendig, die Einträge in einer Datei in eine bestimmte Reihenfolge zu bringen. SORT wird Ihnen bei dieser Aufgabe helfen.

sort file.log 
     -o : write the result to a file
     -r : reverse order
     -n : numerical sort
     -k : sort by column
     -c : check if orderd
     -u : sort and remove
     -f : ignore case
     -h : human sort
Bash

5. Wenn Sie Strings innerhalb eines großen Textes ersetzen müssen, z. B. durch Suchen und Ersetzen, können Sie dies mit SED, dem Stream-Editor, tun.

sed s/regex/replace/g
     -s : search
     -g : replace
     -d : delete
     -w : append to file
     -e : execute command
     -n : suppress output
Bash

6. Das Parsen von Feldern mit Begrenzungszeichen in Textdateien kann mit CUT durchgeführt werden.

cut -d ":" -f 2 file.log
     -d : use the field delimiter
     -f : field numbers
     -c : specific characters position
Bash

7. Die Extraktion von Teilstrings, die nur einmal in einer Textdatei vorkommen, erreichen Sie mit UNIQ.

uniq file.txt
     -c : count the numbers of duplicates
     -d : print duplicates
     -i : case insesitive
Bash

8.  AWK ist eine Programmiersprache, mit der Daten manipuliert werden können.

awk {print $2} file.log
Bash

Tschüß Privatsphäre, Tschüß Freiheit

Je öfter wiederholt werden muss wie gut unsere Meinungsfreiheit ist um so weniger können wir...

Arbeiten mit Textdateien auf der Linux-Shell

Die Kommandozeile ist unter Linux ein mächtiges Werkzeug. In diesem Artiekl lernen Sie verschiedene Helferlein...

Test First?

Als ich vor über 10 Jahren begonnen habe testgetrieben zu programmieren, waren mir sehr viele verschiedene Konzepte theoretisch bekannt. Aber diese Sichtweise erst Testfälle zu schrieben und dann die Implementierung umzusetzen war irgendwie nicht der Weg mit dem ich gut zurecht gekommen bin. Wenn ich ehrlich bin ist das bis heute der Fall. So das ich eine für mich funktionierende Adaption des TDD Paradigma von Kent Beck gefunden habe. Aber langsam der Reihe nach. Vielleicht ist mein Ansatz ja für den einen oder anderen ebenfalls recht hilfreich.

Ich komme ursprünglich aus einem Umfeld für hoch skalierbarer Webanwendungen auf die sich all die tollen Theorien aus dem universitären Umfeld in der Praxis nicht ohne weiteres umsetzen lassen. Der Grund liegt vor allem in der hohen Komplexität solcher Anwendungen. Zum einen sind verschiedene Zusatzsysteme wie In Memory Cache, Datenbank und Identität und Zugriffs Management (IAM) ein Teil des Gesamtsystems. Zum Anderen verstecken viele moderne Frameworks wie OR Mapper Komplexität hinter verschiedene Zugriffsschichten. All diese Dinge müssen wir als Entwickler heutzutage beherrschen. Deshalb gibt es robuste, praxiserprobte Lösungen die gut bekannt sind aber wenig Verwendung finden. Kent Beck mit ist eine der wichtigsten Stimmen für den praktischen Einsatz automatisierter Softwaretest.

Wenn wir uns auf das Konzept TDD einlassen wollen ist es wichtig nicht jedes Wort zu sehr auf die Goldwaage zu legen. Es ist nicht alles in Stein gemeißelt. Wichtig ist das Ergebnis am Ende des Tages. Aus diesem Grund ist es unabdinglich sich die Zielvorgabe aller Bemühungen vor Augen zu führen um dann einen persönlichen Mehrwert zu erzielen. Also schauen wir uns zu erst einmal an was wir überhaupt bezwecken wollen.

Der Erfolg gibt uns Recht

Als ich meine ersten Gehversuche als Entwickler unternommen hatte benötigte ich stetiges Feedback ob das was ich da gerade zusammen bauen auch wirklich funktioniert. Diese Feedback habe ich meist dadurch erzeugt, in dem ich meine Implementierung einerseits mit unzähligen Konsolenausgaben gespickt habe und andererseits habe ich immer versucht alles in eine Benutzeroberfläche einzubinden um mich dann ‚manuell durchzuklicken‘. Im Grunde ein sehr umständliches Test Setup, das dann auch am Schuß wieder zu entfernen ist. Wenn dann noch spätere Bugfixes vorgenommen werden mussten ging das ganze Prozedere wieder von Neuem los. Alles irgendwie unbefriedigend und weit entfernt von einer produktiven Arbeitsweise. Irgendwie musste das verbessert werden ohne das man sich jedes Mal neu erfindet.

Schließlich hat mein ursprünglicher Ansatz genau zwei markante Schwachstellen. Die offensichtlichste ist das ein und auskommentieren von Debug Informationen über die Konsole.

Viel schwerwiegender ist aber der zweite Punkt. Denn all das erworbene Wissen zu dieser speziellen Implementierung ist nicht konserviert. Es droht also über die Zeit zu verblassen und schlußendlich auch verloren zu gehen. Ein solches Spezialwissen ist für viele nachfolgende Prozessschritte in der Softwareentwicklung aber äußerst wertvoll. Damit meine ich explizit das Thema Qualität. Refactoring, Code Reviews, BugFixes und Change Requests sind nur einige der möglichen Beispiele wo tiefgreifendes Detailwissen gefragt ist.

Für mich persönlich kommt auch hinzu, das mich monoton wiederholbare Arbeiten schnell ermüden und ich diese dann sehr gern vermeiden möchte. Sich immer wieder aufs neue mit der selben Testprozedur durch eine Anwendung zu klicken ist weit davon entfernt was für mich einen erfüllten Arbeitstag ausmacht. Ich möchte neue Dinge entdecken. Das kann ich aber nur wenn ich nicht in der Vergangenheit gefangen gehalten werde.

Konferenzvortrag

Die trauen sich aber was

Bevor ich aber darauf eingehe wie ich meinen Entwicklungsalltag durch TDD aufgepeppt habe muss ich noch ein paar Worte über Verantwortung und Mut loswerden. Immer wieder wird mir in Gesprächen erklärt das ich ja recht habe aber man können das alles ja nicht selber umsetzen, weil der Projektleiter oder irgend ein anderer Vorgesetzter kein grünes Licht gibt.

Eine solche Einstellung ist in meinen Augen äußerst unprofessionell. Ich frage doch auch nicht den Marketingleiter welcher Algorithmus am besten terminiert. Er hat schlichtweg keine Ahnung, denn es ist auch nicht sein Aufgabengebiet. Ein Projektleiter der sich gegen das testgetriebene Arbeiten im Entwicklungsteam ausspricht hat aber auch seinen Beruf verfehlt. In der heutigen Zeit sind Testframeworks so gut in die Build Umgebung integriert, das die Vorbereitung für TDD sich selbst für unerfahrene Personen in wenigen Augenblicken umsetzen lässt. Es ist also nicht notwendig das Vorhaben an die große Glocke zu hängen. Denn ich kann versprechen das selbst bei den ersten Gehversuchen nicht mehr Zeit benötigt wird als mit der ursprünglichen Vorgehensweise. Ganz im Gegenteil sehr schnell wird sich eine merkliche Erhöhung der Produktivität einstellen.

Die erste Stufe der Evolution

Wie bereits erwähnt ist Logging für mich ein zentrale Teil der testgetriebene Entwicklung. Wann immer es sinnvoll erscheint versuche ich den Zustand von Objekten oder Variablen auf der Konsole auszugeben. Wenn wir hierfür die aus der verwendeten Programmiersprache zur Verfügung gestellten Mittel nutzen, bedeute dies das wir diese Systemausgaben nach getaner Arbeit mindestens auskommentieren müssen und bei späterer Fehlersuche wieder einkommentieren. Ein redundantes und fehleranfälliges Vorgehen.

Nutzen wir hingegen von beginn an ein Logging Framework so können wir die Debug Informationen getrost im Code stehen lassen und deaktivieren diese später im Produktivbetrieb über den eingestellten Log Level.

Ich nutze Logging aber auch als Tracer. Das heißt jeder Konstruktor einer Klasse schreibt während er aufgerufen wird einen entsprechenden Log Eintrag im Log Level Info. Damit kann man sehen in welcher Reihenfolge Objekte instanziiert werden. Hin und wieder bin ich so auch auf die übermäßig oft vorkommende Instanziierung eines einzelnen Objektes aufmerksam geworden. Dies ist hilfreich für Maßnahmen zur Performance und Speicheroptimierung.

Fehler die bei der Ausnahmebehandlung geworfen werden logge ich je nach Kontext als Error oder Warning. Das ist später im Betrieb ein sehr hilfreiches Mittel um Fehlern auf die Spur zu kommen.

Wenn ich also eine Datenbankzugriff habe, schreibe ich also eine Logausgabe im Log Level Debug wie das zugehörige SQL zusammen gebaut wurde. Führt dieses SQL zu einer Exception, weil ein Fehler enthalten ist so wird diese Exception mit dem Log Level Error geschrieben. Findet wiederum eine einfache Suchanfrage mit korrekter SQL Syntax statt und die Ergebnismenge ist leer wird dieses Ereignis je nach Bedarf entweder als Debug oder Warning klassifiziert. Handelt es sich beispielsweise um eine Loginanfrage mit falschem Benutzernamen oder Passwort neige ich dazu mich für den Log Level Warning zu entscheiden, da dies im Betrieb eventuell sicherheitstechnische Aspekte enthält.

Im gesamten Kontext konfiguriere ich das Logging für die Testfallausführung eher sehr geschwätzig und beschränke mich auf eine reine Konsolenausgabe. Im Betrieb wiederum werden die Logging Informationen in eine Logfile geschrieben.

Die Henne oder das Ei

Wenn wir mit dem Logging die Voraussetzung für eine zusätzliche Feedbackschleife gelegt haben stellt sich im nächsten Schritt die Frage wie geht es weiter. Wie bereits erwähnt tue ich mich sehr schwer erst einen Testfall zu schreiben um dann eine entsprechende Implementierung dafür zu finden. Vor diesem Problem stehen auch viele andere Entwickler die mit TDD beginnen.

Eine Sache die ich bereits voraus nehmen kann ist das Problem, das man bei einer Implementierung darauf achten muss diese auch testbar zu halten. Habe ich erst den Testfall so merke ich umgehend ob das was ich gerade erstelle auch wirklich testbar ist. Erfahrene TDD Entwickler haben recht schnell in Fleisch und Blut übernommen wie testbarer Code auszusehen hat. Der wichtigste Punkt hierbei ist das Methoden stets einen Rückgabewert haben sollten, der möglichst nicht null ist. So etwas erreicht man beispielsweise wenn man anstatt null eine leere Liste zurück gibt.

Die Vorgabe einen Rückgabewert zu haben liegt an der Art und Weise wie Unit Test Frameworks arbeiten. Ein Testfall vergleicht den Rückgabewert einer Methode mit einem Erwartungswert. Die Testzusicherung (engl. Assertation) kennt verschiedene Ausprägungen und kann entsprechend: gleich, ungleich, wahr oder falsch sein. Natürlich gibt es hier auch verschieden Variationen. So kann es unter Verwendung von Exceptions möglich sein Methoden die keinen Rückgabewert haben zu testen. Alle diese Details erschließen sich bei der Anwendung in sehr kurzer Zeit. So das jeder ohne langwierige Vorbereitungen umgehend loslegen kann.

Bei der Lektüre des Buches Test Driven Development by Example von Kent Beck finden wir auch schnell eine Erklärung warum die Testfälle zu erst geschrieben werden sollten. Es handelt sich um einen psychologischen Faktor. Es soll uns dabei helfen den üblichen Stress der im Projekt entsteht besser zu bewältigen. Es erzeugt in uns einen mentalen Zustand über den Zustand und Fortschritt der aktuellen Arbeit. Es leitet uns in eine iterativen Prozess die vorhandene Lösung schrittweise über die verschiedenen Testfälle weiter auszubauen und zu verbessern.

Für alle die wie ich aber zu beginn einer Implementierung noch keine konkrete Vorstellung über das fertige Ergebnis haben ist dieser Ansatz schwer umzusetzen. Der bezweckte Effekt der Entspannung kehrt sich ins negative um. Da wir Menschen alle unterschiedlich sind müssen wir also herausfinden wie wir ticken um das bestmögliche Ergebnis zu erzielen. Ganz so wie es mit Lernstrategien ist. Manche Menschen verarbeiten Informationen besser visuell andere eher haptisch und wieder andere extrahieren alles wichtige aus gesprochenem. Versuchen wir uns also nicht wider unserer Natur zu verbiegen um mittelmäßige oder schlechte Ergebnis zu produzieren.

Den ersten Strich zeichnen

Mir erschließt sich ein Thema eben erst während ich damit arbeite. Also Versuche ich mich solange an einer Implementierung bis ich ein erstes Feedback benötige. Genau dann schreibe ich den ersten Test. Es ergebenen sich bei diesem Vorgehen automatisch Fragen bei der jede einzelne einen eigenen Testfall wert ist. Finde ich alle vorhanden Ergebnisse? Was passiert wenn die Ergebnismenge leer ist. Wie lässt sich die Ergebnismenge eingrenzen? Alles Punkte die sich auf einem Zettel notieren und Schritt für Schritt abhaken lassen. Die Idee eine Aufgabenliste auf einem Zettel zu notieren hatte ich schon sehr lange bevor ich das bereits erwähnte Buch von Kent Beck gelesen habe. Es hilft mir schnelle Gedanke zu konservieren ohne mich von meinem aktuellen Tun ablenken zu lassen. Außerdem vermittelt es am Ende des Tages ein Gefühl etwas geschafft zu haben.

Da ich nicht warte bis ich alles Umgesetzt habe, um den ersten Test zu schreiben ergibt sich auch bei diesem Vorgehen ein iterativer Ansatz. Ich merke auch sehr schnell wenn mein Entwurf nur unzureichend testbar ist, da ich sofort eine Rückmeldung erhalte. Daraus ergibt sich meine eigene Interpretation für TDD die sich durch den permanenten Wechsel zwischen Implementieren und Test schreiben auszeichnet.

Als Ergebnis meiner frühen TDD Versuche habe ich bereits in der ersten Woche eine Beschleunigung meiner Arbeitsweise bemerkt. Ich bin auch sicherer geworden. Aber auch die Art und Weise wie ich Programmiere hat sich schon sehr zeitig zu verändern begonnen. Mir ist aufgefallen das mein Code kompakter und robuster geworden ist. Dinge die sich erst mit der Zeit aufgezeigt hatten ergaben sich bei Tätigkeiten wie Refactoring und Erweiterungen. Fehlgeschlagene Testfälle haben mich vor bösen Überraschungen bewahrt.

Ohne Übereifer beginnen

Wenn wir uns in einem bestehenden Projekt dazu entschließen TDD einzusetzen ist es eine schlechte Idee loszulegen und für bestehende Funktionalität Testfälle zu schreiben. Abgesehen von der Zeit die hierfür eingeplant werden muss wird das Ergebnis die hohen Erwartungen nicht erfüllen.

Eines der Probleme ist das man sich nun in jede Funktionalität neu einarbeiten muss und das ist sehr Zeitaufwendig. Die Qualität der so entstandene Testfälle ist auch unzureichend. Das Problem ergibt sich auch aus der Erfahrung. Wird die Erfahrung erst aufgebaut so ist die Qualität der Testfälle auch noch nicht ganz optimal und möglicherweise muss auch Code umgeschrieben werden, damit dieser Testbar wird. Es entstehen also eine Menge Risiken die für das tägliche Projektgeschäft problematisch sind.

Ein bewährtes Vorgehen TDD einzuführen ist es einfach für die aktuelle Implementierung an der man gerade arbeitet einzusetzen. Es wird also der ist Zustand des aktuellen Problems durch automatisierte Tests dokumentiert. Da man sich bereits auf vertrautem Terrain befindet muss man sich nicht erst in eine neue Thematik einarbeiten, so das man sich voll auf das formulieren von aussagekräftigen Tests konzentrieren kann. Abgesehen davon, das man ungefragt Verantwortung über fremde Arbeiten übernimmt wenn man für diese Testfälle umgesetzt.

Bestehende Funktionalität wird nur bei Fehlerkorrekturen entsprechend um Testfälle ergänzt. Für die Korrektur muss man sich eh mit den Implementierungsdetails auseinander setzen, so das hier genügend Wissen vorhanden ist wie eine Funktionalität sich verhalten sollte. Die so entstandene Tests dokumentieren zusätzlich auch die Korrektur und stellen für die Zukunft sicher das sich das Verhalten bei Optimierungsarbeiten nicht verändert.

Folgt man dieser Vorgehensweise diszipliniert verliert man sich nicht in sogenannter hektischer Betriebsamkeit, die wiederum das Gegenteil von Produktivität ist. Zudem erwirbt man so recht schnell fundiertes Wissen wie effektive und aussagekräftige Tests umgesetzt werden können. Erst wenn ausreichend Erfahrung gesammelt wurde und möglicherweise umfangreiche Refactorings geplant werden, dann kann man überlegen wie für das gesamte Projekt die Testabdeckung schrittweise verbessert werden kann.

Qualitätsstufe

Nur weil Testfälle vorhanden sind bedeutet dies nicht das diese auch eine Aussagekraft haben. Genausowenig beweist eine hohe Testabdeckung das ein Programm fehlerfrei ist. Eine hohe Testabdeckung stellt nur sicher das sich ein Programm im Rahmen der Tests verhält.

Wir kann man also sicherstellen das die vorhandene Tests auch wirklich eine Bereicherung sind und eine gute Aussagekraft haben? Der erste und meines Erachtens wichtigste Punkt ist Testfälle möglichst kurz zu halten. Das heißt im Konkreten, das ein Test nur eine explizite Fragestellung beantwortet, z. B. Was passiert wenn die Ergebnismenge leer ist? Entsprechend der Fragestellung ergibt sich dann auch die Benennung der Testmethode. Den Mehrwert dieser Vorgehensweise ergibt sich in dem Moment wenn der Testfall fehlschlägt. Ist der Test sehr kurzgefasst lässt sich oft schon an der Testmethode ablesen worin das Problem besteht, ohne sich erst langwierig in einen Testfall einzuarbeiten zu müssen.

Ein anderer wichtiger Punkt im TDD Vorgehen ist für meine umgesetzte Funktionalität sowohl die Testabdeckung für Codezeilen als auch für Verzweigungen zu überprüfen. Kann ich zum Beispiel in einer IF-Abfrage das Eintreten einer einzelnen Bedingung nicht simulieren, so kann diese Bedingung bedenkenlos gestrichen werden.

Natürlich hat man im eigenen Projekt auch genügend Abhängigkeiten zu fremden Bibliotheken. Nun kann es vorkommen das eine Methode aus dieser Bibliothek eine Ausnahme wirft, die durch keinen Testfall simuliert werden kann. Das ist genau der Grund wieso man zwar eine hohe Testabdeckung anstreben sollte aber nicht verzweifeln muss wenn 100% nicht erreicht werden können. Gerade bei der Einführung von TDD ist ein gutes Maß für die Testabdeckung größer als 85% üblich. Mit wachsender Erfahrung des Entwicklungsteams kann dieser Wert bis zu 95% angehoben werden.

Abschließend ist aber noch anzumerken, das man sich nicht zu sehr in den Eifer begibt. Denn es kann auch schnell übertrieben werden und dann sind die ganzen gewonnene Vorteile schnell wieder dahin. Und zwar geht es um den Punkt das man keine Tests schreibt die wiederum Tests testen. Hier beißt sich die Katze in den Schwanz. Das gilt auch für Bibliotheken von Fremdanbietern. Für diese werden ebenfalls keine Test geschrieben. Kent Beck äußert sich hierzu sehr klar: Selbst wenn es gute Gründe gibt dem Code anderer zu misstrauen, teste ihn nicht. Externer Code erfordert mehr eigene Implementierungslogik.

Lessons Learned

Gerade die Erkenntnisse die sich bei dem Versuch eine möglichst hohe Testabdeckung zu erzielen sind die, welche sich beim künftigen Programmieren auswirken. Der Code wird kompakter und robuster.

Die Produktivität steigt einfach durch die Tatsache, das fehleranfällige und monotone Arbeiten durch Automatisierung vermieden werden. Es entstehen keine zusätzlichen Arbeitsschritte denn alte Gewohnheiten werden durch neue, bessere ersetzt.

Ein Effekt den ich immer wieder beobachten konnten, wenn sich einzelne Personen aus dem Team für TDD entschieden haben, wurden deren Erfolge schnell beachtet. Innerhalb weniger Wochen hat dann das gesamte Team TDD entwickelt. Jeder einzelne nach seinen eigene Fähigkeiten. Manche mit Test First andere wiederum so wie ich es gerade beschrieben habe. Zum Schluß zählt das Ergebnis und das war einheitlich hervorragend. Wenn die Arbeit leichter fällt und am Ende des Tages jeder einzelne auch noch das Gefühl hat auch etwas geleistet zu haben bewirkt dies im Team einen enormen Motivationsschub, der dem Projekt und dem Arbeitsklima eine gewaltigen Auftrieb verschafft. Also worauf warten Śie noch? Probieren Sie es am besten gleich selber aus.

Faktor Mensch! – wiederholbare Projekterfolge mit SCRUM

Zu der Erkenntnis, dass Menschen Projekte machen, gelangt man nicht erst durch die Lektüre von...

Tschüß Privatsphäre, Tschüß Freiheit

Die im Oktober 2023 veröffentlichten neuen AGB für Microsoft-Dienste lösten in der IT-Welt einen Aufschrei aus. Der Grund war ein Absatz, in dem es hieß, dass mittlerweile alle Microsoft-Dienste auf künstlicher Intelligenz basieren. Diese K.I. soll dazu dienen, Urheberrechtsverletzungen zu erkennen. Dazu gehören Dinge wie Musik, Filme, Grafiken, E-Books und natürlich auch Software. Falls diese K. I. Urheberrechtsverletzungen auf dem System erkennt, sollten diese Dateien automatisch vom „System“ gelöscht werden. Derzeit ist nicht klar, ob diese Regel für die eigene lokale Festplatte oder nur für die Dateien in der Microsoft Cloud gilt. Microsoft hat außerdem erklärt, dass Benutzer, die gegen die Urheberrechtsbestimmungen verstoßen, künftig von allen Microsoft-Diensten ausgeschlossen werden sollen.

Dieser Ausschluss hat verschiedene ‘Geschmäckle’. Die ersten Fragen, die mir in den Sinn kommen, sind: Was passiert mit kostenpflichtigen Abonnements wie Skype? Werde ich gesperrt und anschließend wird mein ungenutztes Guthaben zurückerstattet? Ein noch schlimmeres Szenario wäre, dass ich möglicherweise auch all mein Guthaben und digitale Käufe wie den Zugang zu Spielen und anderen Dingen verliere. Oder sind kostenpflichtige Abonnements davon nicht betroffen? Bisher ist dieser Teil nicht klar.

Wenn Sie ein Apple-Benutzer sind und denken dass dies keine Auswirkungen auf Sie hat, stellen Sie sicher, dass Sie keinen Microsoft-Dienst verwenden, von dem Sie nicht wissen das dieser zu Microsoft gehört. Nicht jedes Produkt enthält den Firmennamen. Denken Sie darüber nach, denn wer weiß, ob diese Produkte Ihr System ausspionieren. Einige Anwendungen wie Skype, Teams, Edge Browser und Visual Studio Code sind auch für andere Plattformen wie Apple und Linux verfügbar.

Microsoft besitzt außerdem die Quellcode-Hosting-Plattform GitHub und ein soziales Netzwerk für Spezialisten namens LinkedIn. Mit Office 360 können Sie die gesamte Microsoft Office Suite per Webbrowser als Cloud-Lösung nutzen und alle Ihre Dokumente werden in der Microsoft Cloud gespeichert. Dieselbe Cloud, in der US-Regierungsinstitutionen wie die CIA, die NSA und viele andere ihre Dateien aufbewahren. Nun, es scheint wohl ein sicherer Ort für alle Ihre Gedanken zu sein, die in ein Office Dukument niedergeschreiben wurden.

Dieses kleine Detail zu Office-Dokumenten führt uns zu einer kleinen Randbemerkung in den neuen Geschäftsbedingungen von Microsoft. Der Kampf gegen Hassrede. Was auch immer das heißt. Öffentliche Beleidigungen und Verleumdungen werden seit jeher vom Gesetzgeber strikt als Straftat behandelt. Es ist kein Kavaliersdelikt, der mit einem kleine bußgeld geahndet wird. Daher ist mir nicht klar, was dieses ganze Gerede über Hassreden bedeutet. Vielleicht ist es ein Versuch, eine öffentliche Zensur der Meinungsfreiheit einzuführen.

Aber zurück zum Randhinweis der Microsoft-Nutzungsbedingungen zu Hassreden. Microsoft hat so etwas geschrieben wie: Wenn Hassreden festgestellt werden, wird der Benutzer verwarnt und wenn die Verstöße mehrmals auftreten, wird das Microsoft-Konto des Benutzers deaktiviert.

Wenn Sie vielleicht denken, dass dies nur etwas ist, was jetzt von Microsoft passiert, stellen Sie sicher, dass viele andere Unternehmen daran arbeiten, gleichwertige Dienste einzuführen. Die Kommunikationsplattform Zoom beispielsweise beinhaltete auch K. I. -Techniken, um die Benutzerkommunikation zu ‘Trainingszwecken’ zu beobachten.

Bei all diesen Neuigkeitenstellt sich eine große Frage die beantwortet werden muss: Was kann ich selbst tun? Die Lösung ist einfach. Verlassen Sie das digitale Universum und gehen Sie zurück in die reale Welt. Schalten Sie das Gehirn wieder ein. Benutzen Sie Stift und Papier, zahlen Sie bar, lassen Sie Ihr Smartphone zu Hause und dort niemals auf dem Nachttisch. Wenn Sie es nicht verwenden, schalten Sie es aus! Treffen Sie Ihre Freunde, wann immer es möglich ist physisch und bringen Sie dann nicht Ihr Smartphone mit. Es wird keine Regierung, keinen Präsidenten und keinen Messias geben, die eine Veränderung herbeiführen wird. Es ist an uns, dies zu tun.

Tschüß Privatsphäre, Tschüß Freiheit

Je öfter wiederholt werden muss wie gut unsere Meinungsfreiheit ist um so weniger können wir...

Arbeiten mit Textdateien auf der Linux-Shell

Die Kommandozeile ist unter Linux ein mächtiges Werkzeug. In diesem Artiekl lernen Sie verschiedene Helferlein...

README – gewusst wie

README Dateien haben in Softwareprojekten eine lange Tradition. Diese ursprünglich reinen Textdateien enthielten Lizenzinformationen und Anweisungen wie aus dem Quellcode das entsprechende Artefakt kompiliert werden konnte oder aber wichtige Hinweise zu Installation des Programms. Es gibt keinen wirklichen Standard wie man eine solche README Datei aufbauen sollte.

Seit dem GitHub (2018 von Microsoft übernommen) als kostenfrei Code Hosting Plattform für Open Source Projekte seinen Siegeszug angetreten ist, gab es schon recht früh die Funktion, dass die README Datei als Startseite des Repositories anzuzeigen. Dazu muss lediglich eine einfach Textdatei mit der Bezeichnung README.md im Hauptverzeichnis des Repository erstellt werden.

Um die README Dateien übersichtlicher strukturieren zu können wurde eine Möglichkeit für eine einfache Formatierung gesucht. Schnell hatte man sich für die markdown Notation entschieden, da diese einfach zu nutzen ist und auch recht performant gerendert werden kann. Somit sind die Übersichtsseiten besser für Menschen zu lesen und können als Projekt Dokumentation genutzt werden.

Es ist möglich mehrere solcher markdown Dateien als Projektdokumentation miteinander zu verknüpfen. Somit erhält man eine Art Mini WIKI das im Projekt enthalten ist und außerdem auch über Git versioniert wird.

Das ganze wurde so erfolgreich, das Selfhosting-Lösungen wie GitLab oder das kommerzielle BitBucket diese Funktion ebenfalls übernommen haben.

Nun stellt sich aber die Frage welche Inhalte man am besten in solch eine README Datei schreibt, damit diese für Außenstehende auch einen wirklichen Mehrwert darstellen. Dabei haben sich im Laufe der Zeit folgende Punkte etabliert:

  • Kurzbeschreibung des Projektes
  • Bedingungen unter denen der Quellcode verwendet werden darf (Lizenz)
  • Wie ist das Projekt zu verwenden (z.B. Anweisungen zum Compilieren oder wie wird die Bibliothek in eigene Projekte eingebunden)
  • Wer sind die Autoren des Projekte und wie kann man sie erreichen
  • Was ist zu tun wenn man das Projekt unterstützen möchte

Mittlerweile sind sogenannte Badges (Sticker) sehr populär. Diese referenzieren oft auf externe Dienste wie beispielsweise der freie Continuous Integration Server TravisCI. Diese helfen ausstehenden die Qualität des Projektes zu beurteilen.

Auf GitHub gibt es auch diverse Vorlagen für README Dateien. Man muss allerdings auch ein wenig auf die tatsächlichen Gegebenheiten des eigenen Projektes schauen und beurteilen welche Information für Nutzer bzw. Anwender wirklich relevant sind. Solche Vorlagen helfen aber sehr dabei herauszufinden ob man möglicherweise eine Punkt übersehen hat.

Das mittlerweile ziemlich jeder Hersteller von Source Control Management Serverlösungen die Funktion die README.md Datei als Projektstartseite für das Code Repository anzuzeigen integriert hat, bedeutet das eine README.me auch für kommerzielle Projekte eine sinnvolle Sache sind.

Auch wenn der Syntax für markdown leicht zu erlernen ist kann es bei umfangreichen Editierungen solcher Dateien durchaus komfortabler sein direkt eine MARKDOWN Editor zu nutzen. Dabei sollte man darauf achten, das die Vorschau auch korrekt dargestellt wird und nicht nur ein einfaches Syntaxhighligting angeboten wird.

Links sind nur für eingeloggte Nutzer sichtbar.

Links sind nur für eingeloggte Nutzer sichtbar.

Das Neueste wird nicht immer das Beste sein

Seit über einem Jahrzehnt hat sich die Erkenntnis durchgesetzt, das Computersysteme aktuell gehalten werden sollten. Wer regelmäßig Updates einspielt verringert das Risiko auf seinem Computer Sicherheitslücken zu haben, die Missbraucht werden könnten. Immer in der Hoffnung das Hersteller von Software stets in ihren Updates auch Sicherheitsmängel beheben. Microsoft hat beispielsweise seit der Einführung von Windows 10 seinen Nutzern ein Update-Zwang auferlegt. Grundsätzlich war die Idee durchaus begründet. Denn ungepatchte Betriebssysteme ermöglichen Hackern leichten Zugriff. Also hat sich vor sehr langer Zeit der Gedanke: ‚Latest is greatest‘ durchgesetzt.

Windowsnutzer habe hier wenig Freiräume. Aber auch auf mobilen Geräten wie Smartphones und Tabletts sind in der Werkseinstellung die automatischen Updates aktiviert. Wer auf GitHub ein Open Source Projekt hostet bekommt regelmäßige E-Mails um für verwendete Bibliotheken neue Versionen einzusetzen. Also auf den ersten Blick durchaus eine gute Sache. Wenn man sich mit der Thematik etwas tiefer auseinandersetzt kommt man sehr schnell zu dem Schluß das latest nicht wirklich immer das beste ist.

Das bekannteste Beispiel hierfür ist Windows 10 und die durch Microsoft erzwungenen Update Zyklen. Das Systeme regelmäßig auf Sicherheitsprobleme untersucht werden und verfügbare Aktualisierungen eingespielt werden müssen ist unumstritten. Das die Pflege von Rechnersysteme auch Zeit in Anspruch nimmt ist ebenfalls Einsichtig. Problematisch ist es aber wenn durch den Hersteller eingespielte Aktualisierungen einerseits das gesamte System lahmlegen und so eine Neuinstallation notwendig wird, weil das Update nicht ausreichend getestet wurde. Aber auch im Rahmen von Sicherheitsaktualisierungen ungefragt Funktionsänderungen bei den Nutzer einzubringen halte ich für unzumutbar. Speziell bei Windows kommt noch hinzu, das hier einiges an Zusatzprogrammen installiert ist, die durch mangelnde Weiterentwicklung schnell zu einem Sicherheitsrisiko werden können. Das bedeutet bei aller Konsequenz erzwungene Windowsupdates machen ein Computer nicht sicher, da hier die zusätzlich installierte Software nicht auf Schwachstellen untersucht wird.

Wenn wir einen Blick auf Android Systeme werfen, gestaltet sich die Situation weitaus besser. Aber auch hier gibt es genügend Kritikpunkte. Zwar werden die Applikationen regelmäßig aktualisiert, so das tatsächlich die Sicherheit markant verbessert wird. Aber auch bei Android bedeutet jedes Update in aller Regel auch funktionale Veränderungen. Ein einfaches Beispiel ist der sehr beliebte Dienst Google StreetMaps. Mit jeden Update wird die Kartennutzung für mich gefühlt unübersichtlicher, da eine Menge für mich unerwünschter Zusatzinformationen eingeblendet werden, die den bereits begrenzten Bildschirm erheblich verkleinern.

Als Nutzer ist es mir glücklicherweise noch nicht passiert, dass Applikationsupdates unter Android das gesamte Telefon lahmgelegt haben. Was also auch beweist das es durchaus möglich ist Aktualisierungen ausgiebig zu testen, bevor diese an die Nutzer ausgerollt werden. Was aber nicht heißt das jedes Update unproblematisch war. Probleme die hier regelmäßig beobachtet werden können sind Dinge wie ein übermäßig erhöhter Batterieverbrauch.

Reine Android Systemupdates wiederum sorgen regelmäßig dafür das die Hardware nach knapp zwei Jahren so langsam wird, das man sich oft dazu entscheidet ein neues Smartphone zu kaufen. Obwohl das alte Telefon noch in gutem Zustand ist und durchaus viel Länger genutzt werden könnte. So ist mir bei vielen erfahrenen Nutzern aufgefallen, das diese nach circa einem Jahr ihre Android Updates ausschalten, bevor das Telefon durch den Hersteller in die Obsoleszenz geschickt wird.

Wie bekommt man ein Update-Muffel nun dazu seine Systeme trotzdem aktuell und damit auch sicher zu halten? Mein Ansatz als Entwickler und Konfiguration Manager ist hier recht einfach. Ich unterscheide zwischen Feature Update und Security Patch. Wenn man im Release Prozess dem Semantic Versioning folgt und für SCM Systeme wie Git ein Branch by Release Modell nutzt, lässt sich eine solche Unterscheidung durchaus leicht umsetzen.

Aber auch der Fragestellung eine versionierbaren Konfigurationseinstellung für Softwareanwendungen habe ich mich gewidmet. Hierzu gibt es im Projekt TP-CORE auf GitHub eine Referenzimplementierung die in dem zweiteiligen Artikel Treasue Chest ausführlich beschrieben wird. Denn es muss uns schon klar sein, dass wenn wir bei einem Update die gesamte vom Nutzer vorgenommene Konfiguration auf Werkseinstellung zurück setzen, wie es recht oft bei Windows 10 der Fall ist, können ganz eigene Sicherheitslücken entstehen.

Das bringt uns auch zu dem Punkt Programmierung und wie GitHub Entwickler durch E-Mails dazu motiviert neue Versionen der verwendeten Bibliotheken in ihre Applikationen einzubinden. Denn wenn es sich bei einem solchen Update um eine umfangreiche API Änderung handelt ist das Problem der hohe Migrationsaufwand für die Entwickler. Hier hat sich für mich eine ebenfalls recht einfache Strategie bewährt. Anstatt mich von den Benachrichtigungen über Aktualisierungen von GitHub beeindrucken zu lassen, prüfe ich regelmäßig über OWASP ob meine Bibliotheken bekannte Risiken enthalten. Denn wird durch OWASP ein Problem erkannt, spielt es keine Rolle wie Aufwendig eine Aktualisierung werden kann. Das Update und ein damit verbunden Migration muss zeitnahe umgesetzt werden. Dies gilt dann auch für alle noch in Produktion befindlichen Releases.

Um von Beginn an der Update Hölle zu entrinnen gilt allerdings eine Faustegel: Installiere beziehungsweise nutze nur das was du wirklich benötigst. Je weniger Programme unter Windows installiert sind und je weniger Apps auf dem Smartphone vorhanden sind, um so weniger Sicherheitsrisiken entstehen. Das gilt auch für Programmbibliotheken. Weniger ist aus Sicht der Security mehr. Abgesehen davon bekommen wird durch den Verzicht unnötiger Programme noch eine Performance Vermessung frei Haus.

Sicher ist für viele privaten Anwender die Frage der Systemaktualisierung kaum relevant. Lediglich Neue unerwünschte Funktionen in vorhanden Programmen, Leistungsverschlechterungen oder hin und wieder zerschossene Betriebssysteme verursache mehr oder weniger starken Unmut. Im kommerziellen Umfeld können recht schnell erhebliche Kosten entstehen, die sich auch auf die gerade umzusetzenden Projekte negativ auswirken können. Unternehmen und Persone die Software entwickeln können die Nutzerzufriedenheit erheblich verbessern, wenn sie bei Ihren Release Veröffentlichungen zwischen Security Patches und Feature Updates unterscheiden. Und ein Feature Update sollte dann entsprechend auch allen bekannten Security Aktualisierungen enthalten.

Das Gesetz von Conway

Während meiner Arbeit als Konfiguration Manager / DevOps für große Webprojekte habe ich beobachtet, wie Unternehmen Conways Gesetzt missachten und dabei kläglich scheiterten. Ein solches Scheitern äußerte sich dann oft in erheblichen Budgetüberziehungen und Terminverzug.

Die interne Infrastruktur in der Projekt Kollaboration wurde genau der internen Organisationsstrukturen nachempfunden und sämtliche Erfahrungen und etablierte Standards so ‚verbogen‘, dass diese auf die interne Organisation passten. Daraus resultierten Probleme das die aufgesetzten CI / CD Pipelines besonders schwerfällig wurden und lange Ausführungszeiten hatten. Aber auch Anpassungen waren nur unter viel Aufwand vorzunehmen. Anstatt bestehende Prozesse zu vereinfachen und an etablierte Standards anzugleichen wurden Ausreden vorgeschoben um möglichst alles wie bisher zu belassen. Schauen wir uns daher einmal an, was Conways Gesetz ist und wieso man es beachten sollte.

Der US amerikanische Forscher und Programmierer Melvin E. Conway erhielt 1961 von der Case Western Reserve University die Doktorwürde. Sein Fachgebiet sind Programmiersprachen und Compiler Design.

Im Jahr 1967 reichte er bei The Harvard Business Review seinen Aufsatz „How Do Committees Invent?“ (dt.: Wie machen Ausschüsse Erfindungen?) ein und wurde abgelehnt. Die Begründung lautete, das seine These nicht belegt wurde. Das zu der Zeit größte IT Magazin Datamation akzeptierte allerdings seinen Artikel und veröffentlichte ihn im April 1968. Und diese Arbeit ist mittlerweile vielfach zitiert. Die Kernaussage lautet:

Jede Organisation, die ein System (im weitesten Sinne) entwirft, wird ein Design erstellen, dessen Struktur eine Kopie der Kommunikationsstruktur der Organisation ist.

Conway, Melvin E. “How do Committees Invent?” 1968, Datamation, vol. 14, num. 4, pp. 28–31

Als Fred Brooks in seinem 1975 erschienen legendärem Buch „The Mythical Man-Month“ den Aufsatz zitierte nannte er diese Kernaussage das Gesetz von Conway. Brooks erkannt den Zusammenhang von Conways Gesetz und der Managementtheorie. Hierzu finden wir in dem Artikel folgendes Beispiel:

Da der zuerst gewählte Entwurf fast nie der bestmögliche ist, muss möglicherweise das vorherrschende System Systemkonzepte ändern. Daher ist die Flexibilität der Organisation für eine effektive Gestaltung wichtig.

The Mythical Man-Month: Essays on Software Engineering

Ein oft zitiertes Beispiel für eine “ideale” Teamgröße im Sinne des Conway’schen Gesetzes ist die Zwei-Pizza-Regel von Amazon, die besagt, dass einzelne Projektteams nicht mehr Mitglieder haben sollten, als zwei Pizzen in einem Meeting satt werden können. Der wichtigste Faktor, der bei der Teamausrichtung zu berücksichtigen ist, ist jedoch die Fähigkeit, teamübergreifend zu arbeiten und nicht in Silos zu leben.

Conways Gesetz war nicht als Scherz oder Zen-Koan gedacht, sondern ist eine gültige soziologische Beobachtung. Schauen Sie sich dazu Strukturen aus Behörden und deren digitale Umsetzung an. Aber auch Prozesse in großen Konzernen zu finden sind wurden durch Softwaresysteme nachempfunden. Solche Anwendungen gelten als sehr schwerfällig und Kompliziert, so das diese wenig Akzeptanz bei Nutzern finden und diese lieber auf Alternativen zurückgreifen. Leider ist es oft aus politisch motivierten Gründen in großen Organisationsstrukturen schier unmöglich Abläufe zu vereinfachen.

Unter anderem findet sich ein ausführlicher Artikel von Martin Fowler, der expliziert auf Softwarearchitekturen eingeht und die Bedeutung der Kopplung von Objekten und Modulen herausarbeitet. Dabei spielt die Kommunikation der Entwickler untereinander eine wesentliche Rolle, um bestmögliche Ergebnisse zu erzielen. Dieser Umstand über die Wichtigkeit der Kommunikation wurde auch von der agilen Softwareentwicklung aufgegriffen und als essentieller Punkt umgesetzt. Besonders wenn rümlich verteilte Teams an einem gemeinsamen Projekt arbeiten ist die Zeitverschiebung ein limitierender Faktor in der Teamkommunikation. Diese muss dann besonders effizient gestaltet werden.

Im Jahr 2010 haben Jonny Leroy und Matt Simons in dem Artikel „Dealing with creaky legacy platforms“ den Begriff Inverse Conway Maneuver geprägt:

Conway’s Law … lässt sich wie folgt zusammenfassen: “Dysfunktionale Organisationen neigen dazu, dysfunktionale Anwendungen zu schaffen.” Um Einstein zu paraphrasieren: Man kann ein Problem nicht aus derselben Denkweise heraus beheben, die es geschaffen hat. Daher lohnt es sich oft zu untersuchen, ob eine Umstrukturierung Ihrer Organisation oder Ihres Teams verhindern würde, dass die neue Anwendung dieselben strukturellen Dysfunktionen aufweist wie die ursprüngliche. In einer Art “umgekehrtem Conway-Manöver” können Sie damit beginnen, Silos aufzubrechen, die die Fähigkeit des Teams zur effektiven Zusammenarbeit einschränken.

Seit den 2010 Jahren hat ein neuer Architekturstil in der Softwareindustrie Einzug gehalten. Die sogenannten Microservices, welche von kleine agilen Teams erstellt werden. Wichtigstes Kriterium eines Microservices zu einem modular aufgebauten Monolithen ist, das ein Microsoervice als eigenständig lebensfähiges Modul bzw. Subsystem gesehen werden kann. Das erlaubt zum einen eine Wiederverwendung des Microservice in anderen Anwendungen. Zum Anderen gibt es eine starke Kapselung der Funktionsdomäne, was eine sehr hohe Flexibilität für Anpassungen eröffnet.

Conways Gesetz lässt sich aber auch auf viele andere Bereiche anwenden und ist nicht ausschließlich auf die Softwareindustrie beschränkt. Das macht die Arbeit so wertvoll.

Ressourcen

Links sind nur für eingeloggte Nutzer sichtbar.

WordPress REST API ist nicht erreichbar

  • [English en] This article is only visible for logged in Patreons. With your Patreon membership you help me to keep this page up to date.
  • [Deutsch de] Dieser Artikel ist nur für eingeloggte Patreons sichtbar. Mit ener Patreon Mitgliedschaft helft Ihr mir diese Seite stets aktuell zu halten.
  • [Español es] Este artículo sólo es visible para los Patreons registrados. Con tu suscripción a Patreon me ayudas a mantener esta página actualizada.
To view this content, you must be a member of Elmar's Patreon at $2.99 USD or more
Already a qualifying Patreon member? Refresh to access this content.

Schreckgespenst künstliche Intelligenz

Der Hyphe um das Thema künstliche Intelligenz hält bereits mehrere Jahre an. Aktuell sorgen Firmen wie OpenAI mit frei zugänglichen neuronalen Netzen wie ChatGPT für erhebliches Aufsehen. Die Anwender sind fasziniert von den Möglichkeiten und einige intellektuelle Persönlichkeiten unserer Zeit warnen die Menschheit vor der künstlichen Intelligenz. Was ist also daran am Schreckgespenst KI? In diesem Artikel gehe ich dieser Frage auf den Grund und Sie sind zu dieser Reise herzlich eingeladen. Auf geht’s und folgen Sie mir in die Zukunft.

Im Frühjahr 2023 überhäuften sich die die Meldungen über die Leistungsfähigkeiten von künstlichen Neuronalen Netzen. Dieser Trend hält weiterhin an und wird meines Erachtens nicht so schnell abklingen. In mitten der gerade entstehenden Goldgräberstimmung machen aber auch vereinzelte Hiobsbotschaften die Runde. So verkündete das Unternehmen Microsoft im großen Stil in das Thema künstliche Intelligenz massiv zu investieren. Diese Meldung wurde im Frühjahr 2023 mit der Entlassung von knapp 1000 Angestellten unterstrichen und ließ altbekannte Ängste der Industrialisierung und Automatisierung aufkommen. Weniger spektakulär verlief es bei Digital Ocean, die das gesamte Team der Contenterstellung und Dokumentation freigesetzt hat. Schnell stellten einige Menschen zu recht die Frage ob KI nun Berufe wie Programmierer, Übersetzer, Journalisten, Redakteure und so weiter obsolet werden? Für den Moment möchte ich diese Frage mit einem Nein beantworten. Mittelfristig werden sich aber Veränderungen ergeben, wie es uns die Geschichte bereits gelehrt hat. Etwas altes vergeht, während neue Dinge entstehen. Folgen Sie mir daher zu einem kleinen historischen Exkurs.

Dazu schauen wir erst einmal auf die verscheiden Stufen der Industrialisierung, die in der zweiten Hälfte des 18 Jahrhunderts ihren Ursprung in England hatte. Bereits die Bedeutung des ursprünglich lateinischen Begriffs Industria, welche mit Fleiß übersetzt werden kann ist äußerst interessant. Was uns zu Norbert Wiener und seinem Buch aus den 1960 ern God and Golem Inc. [1] führt. Er dachte öffentlich darüber nach, ob Menschen die Maschinen kreieren die wiederum Maschinen erschaffen können Götter sind. Etwas das ich von meinem Empfinden nicht unterschreiben möchte. Aber kommen wir vorerst zurück zur Industrialisierung.

Die Einführung der Dampfmaschine und die Nutzung von standortunabhängigen Energiequellen wie Kohle ermöglichten eine präzise Massenfertigung. Mit einer günstigeren Automatisierung der Produktion durch Maschinen wurden manuelle Heimarbeitsplätze verdrängt. Dafür standen nun günstigere Produkte in den Geschäften. Aber auch im Transportwesen gab es erhebliche Veränderungen. Die Eisenbahn erlaubte ein schnelles, komfortableres und günstiges Reisen. Dies katapultierte die Menschheit in eine globalisierte Welt. Denn auch Waren konnten nun problemlos in kurzer Zeit lange Strecken zurücklegen. Wenn wir heute auf damalige Diskussionen zurückblicken, als die Eisenbahn ihren Siegeszug angetreten hatte, können wir nur noch Schmunzeln. Schließlich Argumentierten einige Intellektuelle der damaligen Zeit, dass Geschwindigkeiten in einem Zug von mehr als 30 Kilometer in einer Stunde die menschlichen Insassen förmlich zerquetschen würde. Eine Befürchtung, die sich glücklicherweise als unbegründet herausgestellt hat.

Während nun die Menschen in der ersten industriellen Revolution keine Einnahmen mehr durch Heimarbeit erzielen konnten fanden Sie mit der Anstellung in einer Fabrik eine Alternative um weiterhin den Lebensunterhalt bestreiten zu können.

Die zweite industrielle Revolution ist geprägt durch die Elektrifizierung, was den Grad der Automatisierung weiterhin erhöhte. Maschinen wurden weniger schwerfällig und präziser. Aber auch neue Erfindungen nahmen Einzug in das tägliche Leben. Telefax, Telefon und Radio verbreiteten Informationen im Eiltempo. Dies führte uns in das Informationszeitalter und beschleunigte nicht nur unsere Kommunikation, sondern auch unser Leben. Wir schufen eine Gesellschaft, die vornehmlich durch den Ausspruch „Zeit ist Geld“ geprägt ist.

Die dritte industriellen Revolution segnete die Menschheit mit einer universellen Maschine, welche ihre Funktionalität durch die darauf laufenden Programme (Software) bestimmte. Computer unterstützen uns in der heutigen Zeit bei einer Vielzahl an Tätigkeiten. Moderne Kassensystem leisten weitaus mehr als nur den Gesamtbetrag des getätigten Einkaufes auszuspucken. Sie protokollieren Geld und Warenströme und erlauben mit den erhobenen Daten Auswertungen zur Optimierung. Dies ist eine neue Qualität der Automatisierung die wir in den letzten 200 Jahren erreicht haben. Mit der breiten Verfügbarkeit künstlicher neuronaler Netze sind wir nun auf dem Weg diese Phase zu verlassen, weswegen wir uns gerade in der Transformation zur vierten industriellen Revolution befinden. Denn wie sonst gedenken wir als Menschen der stetig wachsenden Informationsflut Herr zu werden?

Auch wenn Industrie 4.0 den Fokus auf die Vernetzung von Maschinen legt, ist dies keine wirkliche Revolution. Das Internet ist nur eine Konsequenz aus der vorangegangen Entwicklung um zwischen Maschinen die Kommunikation zu ermöglichen. Wir können dies mit der Ersetzung der Dampfmaschine durch elektrische Motoren vergleichen. Die wirkliche Innovation lag in elektrischen Maschinen die unsere Kommunikation veränderte. Dies geschieht nun in unserer Zeit durch das breite Feld der künstlichen Intelligenz.

In naher Zukunft werden wir Computer nicht mehr so benutzen, wie wir es bisher getan haben. Denn die Computer von heute sind der bisher beschränkten Kommunikation zwischen Mensch und Maschine geschuldet. Tastatur und Maus sind eigentlich unhandliche Eingabegeräte. Sie sind langsam und fehleranfällig. Sprach- und Gestensteuerung über Mikrofon und Kamera werden Maus und Tastatur ersetzen. Wir werden uns mit unseren Computern unterhalten, wie wir mit andern Menschen reden. Das bedeutet aber auch, das Computerprogramme von heute obsolet werden. Wir werden nicht mehr langwierig in grafischen Benutzeroberflächen Eingabemasken ausfüllen um zu unserem Ziel zu kommen. Vorbei ist die Zeit wo ich meine Artikel umständlich tippe. Ich werde diese dann einsprechen und mein Computer stellt das dann visuell für mich zum gegenlesen dar. Vermutlich wird dann der Beruf des Logopäden einen erheblichen Aufwind erleben.

Sicher wird es auch genügend Aufschreie von Menschen geben, die den Zerfall der menschlichen Kommunikation befürchten. Diese Angst ist gar nicht so unbegründet. Schauen wir nur einmal auf die Entwicklung der deutschen Sprache in dem Zeitraum seit der Jahrtausendwende. Dies war geprägt durch das Aufkommen verschiedene Textnachrichtendienste und der Optimierung der Nachrichten durch möglichst viele Abkürzungen. Das wiederum schuf bei Eltern nur Fragezeichen auf die Stirn, wenn es darum ging den Inhalt der Nachrichten ihrer Kinder zu entziffern. Auch wenn der aktuelle Trend weg von Textnachrichten hin zu Audiomitteilungen geht, bedeutet es nicht das sich unsere Sprache nicht weiter verändern wird. Ich selbst habe seit Jahren beobachtet, das viele Menschen nicht mehr in der Lage sind sich einerseits schriftlich korrekt auszudrücken oder auch Inhalte aus geschriebene Texten zu extrahieren. Das könnte langfristig dazu führen, das wir die Fähigkeiten wie Lesen und Schreiben verlernen. Somit werden auch klassische Printartikel wie Bücher und Zeitschriften obsolet. Schließlich kann man die Inhalte auch als Video oder Podcast produzieren. Unsere intellektuellen Fähigkeiten werden sich langfristig degenerieren.

Seit der Jahrtausendwende wurde es für viele Menschen immer einfacher Computer zu benutzen. Daher zu erst die gute Nachricht. Es wird noch viel einfacher in Zukunft Computer zu benutzen, weil die Mensch Maschine Interaktion immer intuitiver wird. In der Zwischenzeit werden wir beobachten, wie zunehmend große Internetportale ihren Dienst einstellen, da sich deren Geschäftsmodell nicht mehr trägt. Dazu ein kleines Beispiel.

Als Programmierer nutze ich die Webseite StackOverflow sehr oft, um bei Problemen Hilfe zu finden. Die Informationen dieser Webseite zu Fragestellungen der Programmierung sind mittlerweile so umfangreich, das man über die Suche von Google und Co recht schnell passende Lösungen zum eigene Anliegen findet, ohne das man selbst Fragen formuliert. Soweit so gut. Bindet man aber nun in die eigene Programmierumgebung ein neuronales Netz wie ChatGPT um dort die Antwort auf alle Fragen zu finden, werden die Besucherzahlen für StackOverflow kontinuierlich sinken. Das hat wiederum Auswirkungen auf Werbeeinahnen um den Dienst kostenlos im Netz anbieten zu können. Anfänglich wird man das dadurch kompensieren, das Betreiber von KI Systemen, die auf die Daten von StackOverflow zugreifen eine Pauschalbetrag für die Nutzung der Datenbasis abführen. Dies wird aber den Schwund der Besucherzahlen nicht aufhalten. Was dazu führt, das entweder eine Bezahlschranke die freie Nutzung verhindert oder aber der Dienst komplett eingestellt wird. Es gibt sehr viele Angebote im Internet, die auf ähnliche Probleme stoßen werden was langfristig dafür sorgen wird, das dass Internet so wie wir es bislang kennen in der Zukunft verschwunden ist.

Stellen wir uns einmal vor, wie eine künftige Suchanfrage für den Suchbegriff ‚industrielle Revolution‘ aussehen könnte. Ich frage meinen digitalen Assistenten: Was weist du über industrielle Revolution? – Anstatt nun eine endlos scheinende Liste von tausenden Einträgen nach relevanten Ergebnissen zu durchsuchen, bekomme ich eine kurze Erklärung vorgelesen, mit einer personalisierten Ansprache passend zu meinem Alter und Bildungsstand. Wobei sich mir auch gleich die Frage aufdrängt wer beurteilt meinen Bildungsstand und wie?

Dies ist eine weitere Herabstufung unserer Fähigkeiten. Auch wenn es im ersten Moment als sehr komfortabel wahrgenommen wird. Wenn wir keine Notwendigkeit mehr haben unsere Aufmerksamkeit über einen langen Zeitraum auf eine konkrete Sache zu richten, wird es sicher schwer für uns künftig neue Dinge zu ersinnen. Unsere Kreativität wird auf ein absolutes Minimum zurück gefahren.

Es wird auch die Art und Weise wie Daten künftig gespeichert werden verändern. Komplizierte Strukturen die optimiert in Datenbanken abgelegt werden sind dann eher die Ausnahme anstatt die Regel. Vielmehr erwarte ich unabhängige Daten Brocken, die wie Listen verkettet werden. Schauen wir uns das gemeinsam an, um eine gute Vorstellung davon zu bekommen, von dem was ich meine.

Als Ausgangsbasis nehmen wir einmal das Buch von Aldous Huxley ‚Brave New World‘ aus dem Jahre 1932. Neben dem Titel, dem Autor und dem Erscheinungsjahr können wir als Sprache englisch den Metainformationen hinzufügen. Dies wird dann gefolgt vom gesamten Inhalt des Buches inklusive Vor- und Nachwort als einfacher ASCII Text. Generische oder veränderliche Dinge wie Inhaltsverzeichnis oder Copyright werden in diesem Stadium nicht berücksichtigt. Mit einem solchem chunk haben wir ein atomares Datum definiert, welches durch einen Hashwert eindeutig identifiziert werden kann. Da Huxleys Brave New World im Original in englisch verfasst hat, ist diese Datum auch eine unveränderliche Quelle für sämtliche davon abgeleiteten und generierten Daten.

Wird das Werk von Huxley nun ins Deutsche oder Spanische übersetzt, handelt es sich um die erste Ableitung mit der Referenz zum Orginal. Es kann nun vorkommen, das Bücher von verschiedenen Übersetzern in unterschiedlichen Epochen übersetzt worden sind. Daraus ergibt sich für die deutsche Übersetzung von Herbert E. Herlitschka, aus dem Jahre 1933 mit dem Titel ‚Schöne neue Welt‘ ein anderer Referenz Hash als für die von 1978 erschienene Übersetzung von Eva Walch mit dem gleichnamigen Titel ‚Schöne neue Welt‘.

Werden nun aus den verschiedenen Texten wiederum Hörbücher produziert, so sind diese Hörbücher die zweite Ableitung des originalen Textes, da sie eine gekürzte Fassung darstellen. Es entsteht vor dem Einsprechen ebenfalls ein Text als eigenständige Version. Die aus dem gekürzten Originaltext entstehende Tonspur hat als Urheber den Regisseur und verweist auf den beziehungsweise die Sprecher. Denn wie im Theater kann ein Text von unterschiedlichen Personen verschiedenen interpretiert und inszeniert werden. Identisch kann mit Verfilmungen umgegangen werden.

Bücher, Hörbücher und Filme besitzen wiederum Grafiken für das Cover. Diese Grafiken stellen wiederum eigenständige Werke dar, welche mit der entsprechenden Version des Originales referenziert werden.

Auch Zitate die aus Büchern stammen lassen sich so hervorragend verlinken. Ähnlich verhält es sich mit Kritiken, Interpretationen, Besprechungen und allen möglichen anderen Variationen von Inhalten, die sich auf ein Original beziehen.

Solche Datenblöcke sind aber nicht nur auf Bücher beschränkt, sondern können auch auf Musiknoten, Liedtexte etc. angewendet werden. Ausschlaggebend ist das man möglichst vom Original ausgehen kann. Die so entstehenden Dateien sind ausschließlich für Softwareprogramme optimiert, da sie keine für das menschliche Auge enthaltenen Formatierungen aufweisen. Schließlich genügt als Dateiname der entsprechende Hashwert über den Inhalt der Datei.

An dieser Stelle beginnt auch schon die Zukunftsvision. Denn wir können als Verfasser unseres Werkes nun künstliche Intelligenz nutzen um selbst von einem Buch automatisiert Übersetzungen, Illustrationen, Hörbücher und Animationen erstellen zu lassen. Ich möchte an dieser Stelle kurz auf das neuronale Netz DeepL [2] hinweisen, das bereits beeindruckende Übersetzungen liefert und sogar bei geschickter Handhabung den Originaltext verbessert. Macht DeepL nun Übersetzer und Lektoren arbeitslos? Ich meine nein! Denn auch wie wir Menschen sind künstliche Intelligenzen nicht unfehlbar. Auch Sie machen Fehler. Deswegen bin ich der Meinung das der Preis für diese Arbeiten künftig stark sinken wird, denn diese Personen können dank ihrer Kenntnisse und der hervorragenden Werkzeuge nun ein vielfaches der bisherigen Arbeit verrichten. Dadurch wird die Einzelleistung zwar erheblich günstiger, weil aber im gleichen Zeitraum mehr Einzelleistungen durch Automatisierung möglich sind, kompensiert dies die Preisreduktion für den Anbieter.

Wenn wir uns nun anschauen, welche neuen Möglichkeiten uns damit offen stehen schient es doch gar nicht so problematisch für uns zu werden. Wovor wollen uns also Leute wie Elon Musk warnen?

Wenn wir nun davon ausgehen, das durch die vierte industrielle Revolution das gesamte menschliche Wissen digitalisiert wird und alle neuen Erkenntnisse nur noch digitalisiert erschaffen werden, steht es Computeralgorithmen frei, mit geeigneter Rechenleistung diese Wissensbrocken so zu verändern, das wir Menschen dies nicht bemerken. Ein Szenario frei nach Orwells Wahrheitsministerium aus dem Roman 1984. Wenn wir aus Bequemlichkeit unsere Fähigkeiten verlernen haben wir auch wenig Möglichkeiten einer Überprüfung.

Wenn Sie denken, das wäre doch kein Problem, so möchte ich auf den Vortag „Traue keinem Scan“ von David Kriesel [3] hinweisen.Was war passiert? In Kurzform ging es darum das einem Bauunternehmen Unstimmigkeiten bei Kopien ihrer Baupläne aufgefallen sind. So entstanden vom gleichen Original verschieden Kopien, in denen die Zahlenwerte verändert wurden. Ein sehr fatales Problem bei einem Bauvorhaben für die ausführenden Gewerke. Wenn der Maurer andere Größenangaben bekommt als die Betonschaler. Der Fehler ließ sich letztendlich darauf zurückführen, das Xerox in ihren Scannern für die OCR und die anschließende Komprimierung eine KI als Software nutzte, die die eingelesene Zeichen nicht zuverlässig erkennen konnte.

Aber auch das Zitat von Ted Chiang „Think of ChatGPT as a blurry jpeg of all the text on the Web.“ sollte uns zu denken geben. Sicher ist der Sinn für Menschen die KI lediglich als Anwendung kennen, schwer nachzuvollziehen was mit dem Ausspruch: „ChatGPT ist nur ein verschwommenes Bild des gesamten Textes im Internet“. Es ist aber nicht so schwer zu verstehen wie es im ersten Moment scheint. Neuronale Netze sind auf Grund ihrer Struktur immer nur eine Momentaufnahme. Denn mit jeder Eingabe ändert sich der Interne Zustand eines Neuronalen Netze. Ganz gleich wie bei uns Menschen. Wir sind schließlich auch nur die Summe unserer Erfahrungen. Werden nun künftig immer mehr Texte die von einer KI erschaffen wurden unreflektiert ins Netz gestellt, bildet sich die KI ihr wissen aus ihren eigene Ableitungen. Die Original verblassen mit der zeit da si durch immer geringere Referenzen an Gewichtung verlieren. Käme nun jemand auf die Idee das Internet mit Themen wie flache Erde und Echsenmenschen zu überfluten, würden Programme wie ChatGPT unweigerlich darauf reagieren und dies in ihren Texten mit einfließen lassen. Diese Texte könnten dann entweder selbständig durch die KI im Netz automatisiert publiziert werden oder von unreflektierten Personen entsprechend ihre Verbreitung finden. Damit haben wir eine Spirale geschaffen, die nur dann durchbrochen werden kann, wenn die Menschen ihre Fähigkeit der Urteilskraft nicht aus Bequemlichkeit aufgegeben haben.

Wir sehen also die Warnungen zur Vorsicht im Umgang mit KI sind nicht unbegründet. Auch wenn ich Szenarien wie im Film WarGames von 1983 [4] für unwahrscheinlich halte, sollten wir uns sehr gut überlegen wieweit wir mit der Technologie der KI gehen wollen. Nicht das es uns wie dem Zauberlehrling ergeht und wir feststellen müssen, das wir es Sache nicht mehr Herr werden können.

Referenzen

Links sind nur für eingeloggte Nutzer sichtbar.

Schreckgespenst künstliche Intelligenz

Der Hyphe um das Thema künstliche Intelligenz hält bereits mehrere Jahre an. Aktuell sorgen Firmen...

Künstliche Intelligenz

Tut uns leid, aber dieser Inhalt kann nur mit ausreichender Berechtigung angezeigt werden...

Der digitale Werkzeugkasten

Dieser Artikel ist nur für eingeloggte Patreons sichtbar. Mit einer Patreon Mitgliedschaft helft Ihr mir...