Verfluchtes Wissen

 (immich.app)
4 Punkte von GN⁺ 2025-08-08 | 1 Kommentare | Auf WhatsApp teilen
  • Immich teilt eine Liste des verfluchten Wissens, das im Entwicklungsprozess gesammelt wurde
  • Es werden unerwartete Probleme aus verschiedenen Software- und Infrastrukturumgebungen zusammengefasst
  • Es werden unter anderem Schwierigkeiten mit EXIF-Metadaten, YAML-Whitespace-Verarbeitung und PostgreSQL erwähnt
  • Einige Probleme stehen in direktem Zusammenhang mit Sicherheit, Plattform-Kompatibilität und Open-Source-Abhängigkeiten
  • Der Fokus liegt auf konkreten Beispielen und Ursachen, die Entwickler kennen sollten

Überblick

Das Immich-Entwicklungsteam hat eine Liste der verfluchten Erkenntnisse offen gelegt, die niemand noch einmal erleben möchte. Es handelt sich um eine Aufstellung echter Fallstricke und unerwarteter Probleme, die bei der Entwicklung und im Betrieb von Diensten in verschiedenen Tools, Sprachen und Umgebungen aufgetreten sind.

Liste verfluchter Erkenntnisse

  • 4. Juni 2025

    • Zitadels Actions ist eine verfluchte Funktion
    • Die von Zitadel angebotene Custom-Scripting-Funktion basiert auf einer JS-Engine, unterstützt jedoch benannte Capture Groups bei regulären Ausdrücken nicht, was ihre Grenzen zeigt

  • 30. Mai 2025

    • Microsoft Entra unterstützt PKCE, gibt dies aber nicht im OpenID-Discovery-Dokument an
    • Dadurch tritt das Problem auf, dass eine vorhandene Funktion vom Client nicht erkannt wird

  • 5. Mai 2025

    • Die Größeninformationen in EXIF-Metadaten zur Bildbeschreibung können von der tatsächlichen Bildgröße abweichen
    • Diese Abweichung führt zu Fehlern bei Beschneiden und Größenanpassung

  • 1. April 2025

    • Die Whitespace-Behandlung von YAML verhält sich häufig anders als erwartet
    • Sie ist formatting-sensitiv, was das Risiko birgt, dass Inhalte anders interpretiert werden als beabsichtigt

  • 20. September 2024

    • Versteckte Dateien unter Windows lassen sich nicht mit dem Flag "w" öffnen
    • In Kombination mit der SMB-Option "hide dot files" entsteht große Verwirrung bei Dateisuche und -verarbeitung

  • 7. August 2024

    • In Bash-Skripten kann ein Carriage-Return-Problem (CRLF) auftreten
    • Werden beim Checkout durch Git automatisch LF in CRLF konvertiert, führt das zu Fehlern bei der Skriptausführung

  • 7. August 2024

    • Bei Cloudflare Workers wird selbst bei explizitem https standardmäßig http verwendet
    • Das kann zu Netzwerkproblemen wie Redirect-Schleifen führen

  • 21. Juli 2024

    • Das GPS-Sharing auf Mobilgeräten entfernt bei fehlender Standortberechtigung stillschweigend die GPS-Daten aus Bildern
    • Das betrifft die Genauigkeit ortsbezogener Dienste und die Privatsphäre

  • 3. Juli 2024

    • NOTIFY von PostgreSQL funktioniert nur innerhalb von Transaktionen
    • In Kombination mit dem postgres-adapter von socket.io führt das zu WAL-Schreibvorgängen im 5-Sekunden-Takt, was Last erzeugt

  • 3. Juli 2024

    • Bei jedem Start eines npm-Skripts wird eine HTTP-Anfrage an das npm-Registry gesendet
    • Deshalb ist es ineffizient, Health Checks per Skript auszuführen

  • 28. Juni 2024

    • Einige Mitglieder der JavaScript-Community haben unter dem Deckmantel der Backward Compatibility über 50 zusätzliche Paketabhängigkeiten erzwungen
    • Alle diese Pakete werden von genau diesem Entwickler gepflegt

  • 25. Juni 2024

    • Bcrypt-Implementierungen berücksichtigen nur die ersten 72 Bytes eines Strings
    • Alle weiteren Zeichen werden ignoriert, wodurch lange Passwörter wirkungslos werden

  • 31. Januar 2024

    • Das JavaScript-Date-Objekt ist beim Jahres- und Tageswert 1-basiert, bei Monaten aber 0-basiert
    • Eine leicht verwechselbare Struktur

  • 9. Januar 2024

    • In Node.js vor Version 20.8 verursacht ein CommonJS-Projekt mit der Option --experimental-vm-modules ein Problem, wenn ein ES-Modul ein CommonJS-Modul lädt
      • Segfaults können auftreten, die zu Abstürzen von Node.js führen

  • 28. Dezember 2023

    • Das Parameterlimit von PostgreSQL liegt bei 65.535
    • Das verursacht Leistungsgrenzen bei Masseninsertionsvorgängen großer Datenmengen

  • 26. Juni 2023

    • Einige Web-APIs funktionieren nur in Secure Contexts
    • Beispielsweise funktioniert die Clipboard-API nur in HTTPS- oder localhost-Umgebungen

  • 23. Februar 2023

    • Die Implementierung von TypeORM remove verändert Eingabewerte direkt
    • Sie löscht sogar die id-Eigenschaft des Originalobjekts

Fazit

Diese verfluchten Erkenntnisse sind Stolperfallen, die in realen Entwicklungs- und Betriebsumgebungen häufig auftreten. Wer frühzeitig die in Tools, Programmiersprachen und Umgebungen verborgenen Beschränkungen und Probleme erkennt, kann als Entwickler zu effizienterer Fehlerbehebung und zu stabilerer Service-Entwicklung beitragen.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-08
Hacker News Kommentar

  • Das hat mir von Anfang an wirklich gut gefallen. Nach dem Blick auf den Beispiel-Commit (hier) hat es mir noch besser gefallen. Besonders hilfreich finde ich, dass dabei auch „verfluchtes Wissen“ mit dem Code festgehalten wird, der das Problem löst. Mein erster Gedanke war, dass so etwas in jedem Projekt nötig ist. Das Log ist nicht bloß eine Katharsis, sondern wandelt nervige Probleme in eine positive Lernerfahrung um. Wenn man es offenlegt, kann man sich mit anderen, die dieselben Probleme hatten, identifizieren, und es kann auch dazu dienen, Wiederholungen künftig zu verhindern.

    • Solche Infos schreibe ich normalerweise direkt in Commit-Nachrichten. Wenn jemand eine Codezeile sieht und denkt: „Warum wurde das so schlampig gemacht? Reicht es nicht einfach ___?“, ist es sofort nützlich, dass direkt eine Erklärung dabei steht.

  • Die Stelle mit den 65.000 PostgreSQL-Placeholders, die sich in einer Query nicht binden lassen, hat mich überrascht. Im Grunde ist das keine gute Idee gewesen, daher ist es schwer, PostgreSQL dafür verantwortlich zu machen. In den GitHub-Issue-Kommentaren habe ich gesehen, dass man das ORM refaktoriert hat und große Queries in mehrere kleinere Queries aufgeteilt hat – ein vernünftiger Ansatz. Persönlich erscheint mir ein Bereich von etwa 3.000 bis 5.000 Zeilen pro Query sinnvoll. Jemand schlug vor, die Daten zunächst in eine TEMP-Tabelle zu laden und später zu joinen — insbesondere COPY … FROM —, was performance-mäßig besser sein soll; das ist jedoch ein zu großer Code-Umbruch, und diese Strategie wurde letztlich verworfen. Insgesamt ist das ein nützlicher Pool wertvoller Erfahrungsberichte, gute Warnbeispiele.

    • Dass solche Ansätze selbst als „verfluchte Idee“ gelten, kann ich nachvollziehen. Wenn man die ganze Liste liest, wirkt die „Liste verfluchter Dinge“ eher wie praktische Erkenntnisse, die Entwickler durch echte Stolpersteine gelernt haben, statt wie ein echter Flaschenhals oder ein Architektur-Fallstrick. Natürlich variiert die Qualität der einzelnen Einträge und manche sind noch in Arbeit, aber als persönliche Engineering-Logs sind sie wertvoller.

    • Das fühlt sich an wie der Versuch, alle Dateinamen eines Dateisystems mit Werkzeugen wie xargs auf einmal zu verarbeiten, ohne NUL-Zeichen. Das ist problematisch, wenn es außergewöhnliche oder kaputte Dateinamen gibt oder nicht genug Speicher vorhanden ist. Besser ist es, find -print0 und Werkzeuge wie parallel -0/xargs -0 zu verwenden. Und bei sed, grep usw. muss man aufpassen: Ohne LC_ALL=C gibt es oft Fehler bei Multi-Byte-Zeichenfolgen.

    • Ich habe den Fehler mit 65.000 Bindungen selbst erlebt, als ich mit einem ORM massenhaft Datensätze upsertete. Gerade wenn eine Tabelle SQL-Array-Typ-Spalten hat, muss pro eingefügter Zeile gebunden werden, sodass die Zahl der Bindings schwankt. Deshalb kann die Anzahl der benötigten Bind-Variablen bei zwei Läufen unterschiedlich sein, obwohl Zeilen/Spalten gleich aussehen.

    • Eine andere Strategie ist, Werte als Array-Parameter zu übergeben (z. B. text[] oder int[]). PostgreSQL beherrscht das ebenfalls gut. ANY() ist etwas langsamer als IN(), aber damit lassen sich mehrere IDs in einem Parameter übergeben. Vielleicht unterstützte das ORM das nicht.

    • Das ist mir ebenfalls aufgefallen. So viele Parameter zu binden ist definitiv eine verfluchte Methode. Bei Massenverarbeitung sollte man meistens COPY nutzen. Noch ein wirklich verfluchtes PostgreSQL-Beispiel: prepared statement-Namen werden stillschweigend auf NAMEDATALEN-1 abgeschnitten (NAMEDATALEN ist 64). Das war so schon seit 2001 und hat es vermutlich sogar schon vorher gegeben. ORMs müssen das unbedingt wissen. Dass ein Mensch einen Prepare-Name mit über 60 Zeichen nutzt, ist selten, bei ORMs eher die Ausnahme.

  • Der Punkt „50 zusätzliche Pakete installieren“ war wirklich schockierend. Der Autor des Pakets hat damit wahrscheinlich die Downloadzahlen stark nach oben getrieben. Wenn man global betrachtet, wie viel Bandbreite und Speicherplatz dabei verschwendet wird, ist das wirklich schade. Man fragt sich schon, ob das nicht nur dem Aufbau von Ruhm diente.

    • Der in diesem „verfluchten Wissen“ genannte Paket-Maintainer ist ein Mitglied von TC39. Er ist eine Person, die in mehreren bekannten JavaScript-Projekten öfter für Kontroversen sorgte. Es gab zwar die Behauptung, dass hinter einem bestimmten Polyfill-Issue finanzielle Motive stehen könnten, aber da die Einnahmen aus GitHub Sponsors oder Tidelift nicht groß sind, denke ich, dass er wirklich aus Überzeugung an Kompatibilität festhält. Aus heutiger Sicht (2025) hat sich meine Einschätzung etwas geändert. Er liefert wichtige Wartung kontinuierlich, und die Rolle, in der Community immer wieder unkonventionelle Standpunkte einzubringen, ist vielleicht sogar nötig.

    • Es könnte auch am Ruf oder an seiner besonderen Art liegen, aber es gibt die extreme Deutung, dass dies eine Vorstufe zu einem riesigen Software-Supply-Chain-Angriff war.

    • Der Autor ist nahezu sicher ljharb.

  • NTFS Alternate Data Streams (ADS) von Windows erlauben es, unbegrenzt Dateien in einer vorhandenen Datei zu verstecken.
    macOS erzeugt per Default auf allen wechselbaren Datenträgern mit Data Fork, xattr und Spotlight(md)-Indexierung viele versteckte und temporäre Dateien. Abhilfe: mdutil -X /Volumes/path/to/vol
    Und es gibt viel zu viel Opt-out-Telemetrie (go, yarn, meilisearch, homebrew, vcpkg, dotnet, Windows, VS Code, Claude Code, macOS, Docker, Splunk, OpenShift, Firefox, Chrome, flutter usw.), mit Datenschutzbedenken.

    • Opt-out-Telemetrie: Bei Go werden die Telemetriedaten standardmäßig lokal gespeichert. Nur auf Wunsch werden einige freigegebene Daten an telemetry.go.dev hochgeladen. Das Hochladen wird mit „go telemetry on“ aktiviert, ein vollständiges Ausschalten mit „go telemetry off“ möglich (Dokumentation).

    • Nur Opt-out-Telemetrie ist wirklich sinnvolle Telemetrie.

  • Zur Meldung, dass bei jeder Ausführung von npm-Skripten eine HTTP-Anfrage an die npm-Registry gesendet werde, frage ich mich, ob das wirklich so ist. Wenn ja, wäre das als Paketmanager völlig absurd.

    • Vermutlich ist es ein Update-Check. Bei einer älteren Version wird manchmal ein Updatehinweis angezeigt.

    • Vermutlich geht es um Updateprüfungen. Gelegentlich wird ein Update-Banner eingeblendet.

  • Mir scheint, da fehlt noch etwas. Die Runde zu Datum- und Zeitbehandlung in EXIF-Metadaten ist ein ziemlich alter Streitpunkt.
    Issue-Referenz 1, Issue-Referenz 2, Issue-Referenz 3

    • Datum und Uhrzeit sind selbst anfällig dafür, verflucht zu werden. Auch wenn es scheinbar funktioniert, kann im zugehörigen Feature jederzeit ein Problem entstehen, besonders wenn Werte Zeitzonen oder Sommerzeit enthalten.

  • Mir wurde das Dokument „Madness beyond the gates“ zu Hadoop und Kerberos in Erinnerung Link. Dieses Dokument hat mich schon mehrmals davor bewahrt, durchzudrehen. Ich möchte Steve dafür danken. Ich kann mir kaum vorstellen, wie viel Mühe es gekostet hat, dieses verfluchte Wissen zu erarbeiten.

  • Die Idee, solches verfluchtes Wissen an einem Ort zu bündeln, ist wirklich gut. Ich kann gut nachvollziehen, dass es Stolpersteine sind, die man erst tief im Projekt wirklich erlebt. Ich werde mir für künftige Projekte vornehmen, solche Listen anzulegen.

  • Dieser Eintrag ist kein verfluchter Fall, sondern ein Sicherheits-/Datenschutzproblem rund um Berechtigungsverwaltung in mobilen OS.

  • Coole Idee! Ich frage mich, ob andere auch ihre verfluchten Erkenntnisse teilen wollen.
    Aus meiner Erfahrung sind MacOS-Dateinamen ebenfalls verflucht:

  1. MacOS behandelt Dateinamen standardmäßig nicht case-sensitive (file.txt und FILE.txt gelten als gleich).
  2. Wenn MacOS Dateinamen in NFC speichert, können sie manchmal in NFD konvertiert werden.

  • 1995 habe ich bei der Windows 95 Beta erstmalig CDDB aufgebaut. Ich habe Tracknamen der CDs in einer .ini-Datei gesammelt und verteilt, aber das Projekt wurde gestoppt, weil das .ini-Limit bei 64 KB lag.

  • Richtig. Wenn du ein case-sensitive APFS- oder HFS+-Volume als System- oder Daten-Volume anlegst, gibt es zwangsläufig Probleme.

  • Punkt 1 ist nur die Standardeinstellung. HFS und APFS haben beide eine Case-Sensitivity-Option. NTFS verhält sich ähnlich. Diese Dateisysteme sind case-retentive, deshalb geht das hier so:

 $ echo yup > README.txt
 $ cat ReAdMe.TXT
 yup
 $ ls
 README.txt

Das eigentliche Problem ist, dass Steam die Installation auf case-sensitive Dateisystemen verweigert (trotz vorhandener Linux-Version).