In diesem extrem guten Vortrag geht Jonathan Blow auf die Problematik des Wissensverlustes von Zivilisationen ein. Er erklärt Anfangs das Grundproblem, warum viele alte Zivilisationen, die einst sehr mächtig und effizient waren, irgendwann einfach verschwunden sind – wie die Römer oder die Maya. In allen genannen Beispielen war es auf der einen Seite kein Untergang innerhalb eines Tages, sondern über viele Jahre, Jahrzehnte oder gar Jahrhunderte und sie hatten auf der anderen Seite vor allem eines gemeinsam: immer spielte der Verlust von Wissen die entscheidende Rolle.
Und mit diesen erkannten Prinzipien schwenkt er dann in die Neuzeit und münzt das Ganze auf die Problemantik, dass die moderne Welt nahezu komplett auf Hardware/Software basiert – was an sich ja erstmal nicht verkehrt ist. Allerdings befinden wir uns aktuell in einer Phase, in der nahezu viele Techniker zwar auf ihrem hohen Level sehr gut sind, aber die wenigsten noch die Grundlagen beherschen: wie funktioniert eine CPU bzw. wie baut man eine CPU, wie funktioniert ein Compiler im Detail, wie werden Daten im Speicher abgelegt und verwaltet und was exakt macht eine Garbage Collection? Das sind nur einzelne Bereiche, aber sie zeigen das Problem auf: je weniger Leute sich mit Basiswissen auskennen, desto höher die Wahrscheinlichkeit, dass dieses Basiswissen einmal verloren geht. Ja, natürlich kann man alles dokumentieren und archvieren. Trotzdem braucht es ja weiterhin Leute die dieses Wissen dann auch anwenden können.
Blow erklärt das sehr gut anhand der Situation in der Spielewelt (die Konferenz auf der er spricht ist eine Spielekonferenz) – genauer gesagt in der Welt der Indygames – in der es aktuell mehr oder weniger nur noch zwei führende Technologien gibt: Unity und Unreal. Keiner der entsprechenden Entwickler weiß, wie man selbst eine 3D Engine baut noch wie man absolut Low-Level einen Pixel auf den Bildschirm zeichen kann. Ich habe dafür mal von dem tollen Begriff des “Glue-Developers” gelesen: also ein Entwickler, der “nur noch” Libraries/Frameworks “zusammenklebt” und damit komplexe Applikationen baut. Das ist an sich etwas tolles, weil es effizient und wahrscheinlich sehr schnell ist. Aber was passiert, wenn es zu einem Fehler in einer darunter liegenden Library kommt?
Wie repariert man diesen Fehler bzw. wie findet man ihn überhaupt noch. NodeJS bzw. NPM ist ein gutes Beispiel wie absurd diese Abstraktion von Wissen werden kann, da dort selbst einfachste Funktionen in externe Libraries ausgelagert werden. Mit fatalen Konsequenzen.
Mich hat der Vortrag auf jeden Fall inspieriert, mal wieder einen Blick auf Basics zu werfen und lieber grundlegende Dinge wie Assembler/C Programmierung anzuschauen und mein Grundwissen da etwas auszubauen statt dem nächsten neuen Tech-Trend hinterherzueifern.
Da hat Apple mit dem M1 was ziemlich heftiges rausgehauen. Die ersten Benchmarks zeigen, dass das Macbook Air (passiv gekühltes Einsteigergerät) mit dem neuen M1 Chip das am besten ausgestattete Macbook Pro 16″ in nahezu allen Kategorien schlägt. Man kann sich ausmahlen was dann die neuen Macbook Pros die hoffentlich im Frühjahr kommen leisten werden 😱
Wenn du den Output von Curl anpassen willst, um z.B. nur zu schauen, welcher http Code zurückgeben wird oder nur schauen möchtest, wie lange das laden der Seite gedauert hat, dann kannst du mit der Option “-w” genau das tun:
Du hast auf einem Docker Host diverse Container laufen, die teilweise auch untereinander kommunizieren. Nun möchtest du per docker compose ein paar weitere Container hinzufügen. Und dann bemerkst du, dass diese Container von den “alten” Containern (z.B. einem nginx Proxy) nicht erreichbar sind, weil docker-compose diese automatisch in ein eigenes Network packt.
Um das Problem zu lösen, ist die einfachste (wenn auch nicht schönste) Variante, dass die docker-compose container auch im “default” Netzwerk (“bridge”) teilnehmen. Dazu muss man einfach für jeden Container/Service der Eintrag
network_mode: bridge
Damit die Container aus der docker-compose Datei sich auch noch untereinander sehen können, kann man sie ganz klassisch per
Wenn das Monitoring meldet, dass die Platte eines Servers voll läuft, ein
du -hs /*
aber deutlich weniger verwendeten Speicher anzeigt als man es per df sieht – dann gibts erstmal Verwunderung.
Eine google Recherche hat mich dann auf den Trichter gebracht, dass dies ein Zeichen von zwar gelöschten Dateien, aber noch offenen Dateihandles auf diesen liegen kann. Sprich, man hat zwar eine Datei gelöscht, aber ein Programm hat die Datei aktuell noch geöffnet. Dann ist zwar der Dateiname nicht mehr sichtbar, aber die Inhalte der Datei liegen noch immer auf der Festplatte und verbrauchen natürlich auch ensprechend Platz. In meinem Fall ist filebeat nicht mit einem Logrotate klar gekommen und hatte somit eine relativ große Log Dateien weiterhin geöffnet. Mit jedem Logrotate kam eine dazu…
Wie kann man das sichtbar machen? So:
lsof | grep "/var" | grep deleted
oder gleich mit
lsof | grep deleted
wobei man bei letzterem vielleicht ein paar Ergebnisse sieht, die berechtigt noch Handles offen halten.
Hier mal eine Beispielhafte Ausgabe:
Ganz links sieht man den Dienst bzw. Command, und in der ganz rechten Spalte die jeweilige Datei.
Normalerweise sollte es reichen, den entsprechenden Dienst einfach neu zu starten und das Problem ist erstmal behoben. Sollte der Fehler wieder auftreten, müsste dann evtl ein Update/Patch oder als letzte Möglichkeit ein kontrollierter regelmäßiger Neustart das Problem beheben.
Beim Ausführen von Ansible Befehlen bekam ich seit kurzem immer wieder die Fehlermeldung
Abort trap: 6
angezeigt. Da ich Ansible direkt über pip installiert hatte, führte ich natürlich erstmal ein Update dort durch – was aber keine Abhilfe brachte. Irgendwie hatte das ganze mit dem Wegfall von python 2.7 mit Mac OS Catalina zu tun.
Die relativ plumpe, aber doch effektive Lösung war:
Das Update auf Mac OS Catalina lief bei mir eigentlich ohne Probleme durch, aber heute fiel mir dann auf, dass die Suchfunktion in der Mail App sich sehr komisch verhielt bzw. einfach kaputt war.
Mir war natürlich gleich klar, dass der Suchindex wahrscheinlich einen Treffer hatte, da ich die App ja trotzdem normal bedienen und Mails senden/empfangen konnte.
Um das Problem zu beheben, musste ich also den Suchindex der Mail App zurücksetzen und neu aufbauen lassen. Dazu sind folgende Schritte nötig:
Mail App beenden
Im Finder den Ordner ~/Library/Mail/V7/MailData öffnen (mit CMD+SHIFT+G)
Alle Dateien, die mit „Envelope Index“ beginnen löschen (oder in einen Backup-Ordner schieben)
Mail App wieder starten. Es empfängt euch ein Screen, der mitteilt, dass Mail sich selbst reparieren muss. Anschließend werden die Mails neu indiziert, in dieser Zeit ist Mail nicht benutzbar.