Tech Teardown 038 | nibnib: Ein 4bpp-Bildformat für sechs Taktzyklen

Was ist es: Eine Bildformatierung, die extrem einfach zu dekodieren und extrem komplex zu kodieren

Am 30. Oktober 2026 veröffentlichte Raph Levien (GitHub-Konto raphlinus) ein neues Bildformat sowie eine passende Rust-Referenzimplementierung unter dem Namen nibnib. Die kurze Beschreibung des Repos lautet zurückhaltend: „Image Compression at 4bpp with extreme decompression speed“, also Bildkomprimierung mit 4 Bit pro Pixel und extrem schneller Dekomprimierung. Etwa 21 Minuten nach der Veröffentlichung des Repos postete er den Beitrag auf Hacker News, wo er 88 Punkte erhielt. Bis Anfang November 2026 hatte das Repository 58 Sterne, 2 Forkings, 0 offener Issues und keine Releases. Die gesamte Historie umfasst 10 Commits, und es wird unter Apache-2.0 oder MIT-Licence vertrieben.

Das Ziel von nibnib ist nicht der Kompressionsfaktor oder die Bildqualität, sondern eine Sache: Den Dekodierungsaufwand auf das Äußerste zu reduzieren. Es komprimiert das Bild auf 4 Bit pro Pixel und decodiert zwei Pixel pro Byte. Der Kernrechner hat nur einen einzigen Schritt der Multiplikation und Addition. Der Preis ist eine extrem unausgewogene Kodierungsebene, wie im README ausdrücklich erwähnt: Der aktuelle Koder ist um mehrere Grade langsamer als der Dekoder.

Der Autor sollte etwas näher beschrieben werden, denn dieses Projekt trägt seine jahrzehntelange Erfahrung in sich. Laut seiner persönlichen Website arbeitete Levien von Dezember 2020 bis Oktober 2025 für das Google Fonts-Team, wo er sich auf GPU-Fontrendering und damit verbundene Technologien spezialisierte. Früher war er auch im Fuchsia-Team für Textverarbeitung und Rust tätig. Bis heute ist er noch aktiv in der Rust-Community und beteiligt an Projekten der Xilem-Reihe. Er war auch Betreuer von Ghostscript und seine Doktorarbeit befasste sich mit der Gestaltung interaktiver Kurven. Die Inconsolata-Fonts stammen von ihm. Ein weiterer Aspekt, der direkt mit nibnib zusammenhängt: Er entwickelte ein hochwertiges Halftonalgorithmus für Tintenstrahldrucker namens Even Toned Screening. Halbtönung und Fehlerverbreiterung sind Techniken derselben Familie, und der Koder von nibnib basiert auf der Floyd-Steinberg-Fehlerverbreiterung. Das ist keine plötzliche Umorientierung, sondern ein erfahrener Experte, der zu seinem alten Fach zurückkehrt.

Warum jetzt: Ein Mikrocontroller und ein Budget von 6 Schaltzyklen pro Pixel

Am Anfang des README wird die Herkunft erklärt: nibnib stammt aus einer Experimentierung, bei der man herausfinden wollte, wo die Grenzen der Bildqualität und Leistung liegen, wenn DVI-Videoausgabe auf einem RP2350-Mikrocontroller erfolgt.

Der RP2350 ist ein kostengünstiger Mikrocontroller, der es ermöglicht, DVI-Video信号 direkt auszugeben. Das bedeutet, dass jedem Pixel nur sehr wenige Rechenressourcen zur Verfügung stehen. Die übliche Vorgehensweise bei solchen Geräten ist die Verwendung von Bilden mit niedriger Bitdichte und Tabellen für Farbpaletteabfragen. Levien legt ein klares Budget fest: etwa 6 Schaltzyklen pro Pixel. Was können 6 Zyklen tun? Pixel abzapfen, Farbpaletten abzufragen und in den Zeilenbuffer zu schreiben – nichts mehr. Keine Überschussressourcen.

Diese Einschränkung ausschließt fast alle gängigen Formate. Die Dekodierung von JPEG erfordert Huffman-Dekodierung, inverse Quantisierung, IDCT und Auflösungs-upsampling. Allein die IDCT übersteigt das Budget von 6 Perioden pro Pixel bei weitem. Das verwendete DEFLATE-Verfahren in PNG ist ein serieller Algorithmus auf dem Bitstrom und kann ebenfalls nicht eingesetzt werden. Unter dem Budget von 6 Perioden gibt es nur eine mögliche Dekodierungsmethode: keine Verzweigungen, keine Entropie-Dekodierung, nur Tabellenabfragen und Additionen in einer linearen Codebasis.

nibnib ist die Antwort auf diese Herausforderung. Die Echtzeit-Dekodierung auf dem RP2350 ist in Leviens anderen Repository vic-2350 unter der Bezeichnung „Image Demo“ enthalten. Das Format und das Zielgerät entwickeln sich gemeinsam. Aus der Commit-Historie geht hervor, dass das Projekt hauptsächlich vom 5. bis 14. Dezember 2025 kontinuierlich Committe eingereicht wurden: Initial version, Gaussian palette, Weight RGB error, Floyd-Steinberg, Semi-structured palette, Tune error balance. Danach wurde es etwa zehn Monate lang pausiert. Am 22. Oktober 2026 wurden einige Änderungen vorgenommen, und am 30. Oktober wurde das README fertiggestellt und offiziell veröffentlicht. Ein typisches „zehn Tage Experiment, ein Jahr später Veröffentlichung“.

In den Kommentaren von HN hat ein Benutzer die Anwendungsmöglichkeiten dieses asymmetrischen Designs noch weiter erweitert: In der broadcastartigen Inhaltsverteilung schreibt der zentrale Quellcode einmal, während viele Terminals mehrmals lesen. Der Schreiber kann langsam sein, die Leser müssen schnell sein – solche Szenarien profitieren natürlich von dieser Vorteilhaftigkeit. Das ist nicht nur eine spezielle Fähigkeit für Mikrocontroller, sondern eine allgemeine Entscheidung über den Einsatz von Komplexität.

Wie geht es vor? Delta, Pixelpaar und lineare Multiplikation

Das Kernstück von nibnib sind drei Designentscheidungen, die alle dem Budget von 6 Perioden entsprechen.

Erstens: Die Palette speichert Delta-Werte, nicht absolute Farben. In traditionellen Indexfarbbasierten Bildern (GIF, PNG-Paletten) werden absolute Farben gespeichert, wobei jedes Pixel nur 256 Farben annehmen kann. Glatte Übergänge erfordern eine feste Anzahl von Farben. In nibnib wird der Unterschied zum vorherigen Pixel als Delta gespeichert: Nachdem das linke Pixel dekodiert wurde, ist das rechte Pixel gleich „linkes Pixel + Delta“. So können wenige kleine Änderungen große weiche Bereiche abdecken. Im README heißt es, dass dies die Bildqualität gegenüber herkömmlichen Palettenbildern verbessert, wobei die weichen Bereiche am meisten profitieren.

Zweitens: Ein Byte decodiert zwei Pixel, was 4bpp ergibt. Die Dekodierung geht nach Pixelpaaren voran: Das vorherige 16-Bit-Pixel wird in die obere und untere Hälfte eines 32-Bit-Registers kopiert. Ein Byte wird aus dem Eingabestrom gelesen, eine 32-Bit-Delta aus der Palette abgerufen, addiert und wieder eingespeist. Die untere 16 Bits des Ergebnisses sind das linke Pixel, die oberen 16 Bits das rechte Pixel, beides im RGB565-Format. Der Kern des internen Zyklus ist eine Zeile Code (der Rust-Abschnitt im README):

pix = ((pix >> 16) * 0x10001).wrapping_add(pal[inp as usize]);

Darin wird (pix >> 16) * 0x10001 zur „Pixelkopie“ verwendet, um den 16-Bit-Wert auf die 32-Bit-Hälften zu verteilen; wrapping_add ist eine Überlauffreie Additionsmethode. Die Komplexität jedes Pixelpaares besteht aus einer Byte-Ladung, einem Tabelldatensatz, einem Verschiebung, einer Multiplikation, einer Addition und zwei Speicherungen – ohne Bedingungsausdrücke. Die Decodierung ist sehr zuverlässig: Jede Implementierung erhält dasselbe Ausgabeergebnis für den gleichen Bytefluss (die Anzahl der Anweisungen basiert auf meiner Interpretation des Quellcode, nicht auf offiziellen Statistiken).

Drittens ist die Dateiformatierung so einfach, dass es fast schon nackt wirkt: 2-Byte-breit, 2-Byte-hoch, 256 32-Bit-Farbpaletteneinträge (insgesamt 1028 Bytes Kopf), gefolgt von Daten pro Zeile. Jede Zeile beginnt mit zwei RGB565-Pixeln, die 4 Bytes einnehmen, danach folgen (width - 2) / 2 Indexzeilen, wobei die Zeilengröße zu einem Vielfachen von 4 Bytes gestellt wird. Es gibt keinen Versionnummer, keine Checksumme und keine Metadaten. In dem README heißt es klar: Dieses Format ist nicht für Archivierung konzipiert, sondern eher eng mit dem Decodierer verbunden.

Am Codierungsende ist die Situation etwas anders. Im README steht deutlich: „nibnib wird durch den Decodierungsprozess definiert“ – Die Decodierung ist sicher und einfach, während das Kodieren im Grunde eine Suche ist, bei der man in allen möglichen Kodierungen denjenigen findet, der am ehesten dem Originalbild ähnelt. Die Suche hat zwei Dimensionen.

Erstens die Auswahl der Farbpalette. Die aktuelle Version der Farbpalette hat eine feste Struktur: 133 cube-Einträge plus 123 zufällige Einträge. Der cube-Bereich besteht aus geometrischen Kombinationen von 3×5×3 auf drei Delta-Maßen (1, 2, 4), um sicherzustellen, dass die Werte in der Nähe von 0 und am vollen Spektrum liegen und nicht überschritten werden. Im README wird klar gesagt, dass das Entfernen des cube-Bereichs zu schlechten Verzerrungen führt. Im Repository sind Vergleichsbilder mit rein zufällig generierten Farbpaletten und kombinierten cube+zufälligen Einträgen enthalten. Der zufällige Teil wird mit gewichteten Gaußsampling-Techniken erzeugt, wobei die Maße logarithmisch verteilt sind; die Fehlermessung erfolgt durch 0.3r² + 0.7g² + 0.1b², wobei der Gewichtung des Grüngrunds etwa das Doppelte des Rot-Blaus beträgt, was der Sensitivität des menschlichen Auges gegenüber Grün entspricht (diese Konstanten stammen aus dem Code auf encode.rs). Im README wird auch offen zugegeben, dass dieser zufällige Prozess ad hoc nach vernünftigen Werten erstellt wurde und dass die Farbpalette derzeit nicht adaptiv an das eingegebene Bild angepasst wird. Der Autor weist darauf hin, dass dies der klareste Verbesserungsansatz ist.

Zweitens wählt man einen Codewort, das mit Floyd-Steinberg-Error-Diffusion verwendet wird. Für jedes Pixelpaar versucht der Kompressor alle 256 Farbpalette-Einstellungen aus, um das Codewort zu wählen, das den geringsten Dekodierfehler verursacht. Anschließend wird der Fehler nach den klassischen Gewichtungen von Floyd-Steinberg (7/16, 1/16, 5/16, 3/16) auf die rechts angrenzenden Pixel sowie auf drei Positionen in der nächsten Zeile diffundiert. Das Ziel der anschließenden Pixelanpassung ist nicht der ursprüngliche Wert, sondern der ursprüngliche Wert plus der kumulierten Fehler. Der Unterschied zum klassischen Error-Diffusion-Verfahren besteht darin, dass beim klassischen Verfahren ein Pixel nach dem anderen verarbeitet wird, während bei nibnib zwei Pixel gleichzeitig verarbeitet werden. Deshalb wird das Codewort gewählt, das den gemeinsamen Fehler der beiden Pixel minimiert, wobei die Gewichtung des Summandes der Fehler höher ist als der Differenz. Dabei wird die Tatsache berücksichtigt, dass das menschliche Auge auf niedrige räumliche Frequenzen sensibler reagiert. Auf HN wurde ein Benutzer (zahlman) dagegen gewettert, dass dies eher eine Verlängerung der Definition von „Kompression“ darstellt, nichts anderes als Delta-Filtering mit Farbpalette-Kuantilisierung. Doch er war auch erstaunt über die gute Wirkung, denn intuitiv würde Delta-Stringen den kumulierten Fehler verstärken. Der Grund, warum der Fehler nicht außer Kontrolle gerät, liegt in der Auswahl des Ziels: Jeder Schritt des Kompressors berücksichtigt die kumulierten Fehler als Ziel, wodurch die Abweichungen kontinuierlich abgebaut werden (dies ist meine Schlussfolgerung aus dem Quellcode).

Der Greedy-Algorithmus hat einen bekannten Kostenaufwand. Im README steht, dass der aktuelle Unschärfe am rechten Rand der scharfen Kanten verläuft. Der Autor gibt Verbesserungsmöglichkeiten an: Den Kodierungsablauf von rechts nach links ändern oder sogar in eine Schlangenform umwandeln (jede Zeile wechselt die Richtung), da die Additionsebene in der Praxis reversibel ist. Oder man führt eine tiefere Suche durch: Wenn die Fehlerzusammensum der beiden Optionen für ein Pixel vergleichbar sind, könnte eine davon das nächste Pixel viel leichter dekodieren lassen. Diese Verbesserungen werden den Kompressor langsamer machen, aber die Dekodiergeschwindigkeit bleibt unverändert. Die Worte des README lauten: Alle Verbesserungen können auf dem bestehenden Dekoder durchgeführt werden.

## Messergebnisse und Daten: Im Repository wurden keine Zahlen angegeben, ich habe es einmal ausprobiert

Im nibnib-Repository gibt es keine Benchmarks. Dies wurde direkt in den Kommentaren auf HN angesprochen: Der Benutzer augment_me meinte, dass es unangemessen ist, die extrem hohe Dekodiergeschwindigkeit zu betonen, ohne Zahlen für die Vergleichsmöglichkeit mit JPEG anzugeben. Ein anderer Benutzer, DoctorOetker, antwortete, dass der Sinn gerade darin besteht, Plattformen abzudecken, auf denen JPEG nicht in Echtzeit dekodiert werden kann.

Ich habe die Referenzimplementierung auf meinem eigenen Computer (Apple Silicon Mac, Rust 1.96, Release-Build) kompiliert und das selbst enthaltene Beispielbild flowers7.png (1000×750, RGB 8bit) ausprobiert. Alle folgenden Zahlen sind meine eigenen Messungen, keine offiziellen Statistiken:

- Die Kodierdaten betragen 379.028 Bytes, was genau dem Formatformat 1028 + 750 × 504 entspricht. nibnib ist ein festlängerer Code ohne Entropiekodierung; die Ausgabegröße wird ausschließlich durch die Bildgröße bestimmt.
- Der effektive Bitprozentsatz beträgt 4,043 bpp (die Kosten durch die Farbpalette, die Pixelanzahl pro Zeile und die Zeilenanordnung sind etwas höher als der nominelle 4bpp). Das ist etwa 3,96-mal so viel wie das unverschlüsselte RGB565-Format und etwa 5,94-mal so viel wie das RGB888-Format. Das in der Repository enthaltene PNG-Datensatz hat eine Größe von 792.470 Bytes, aber das PNG ist lösungsfrei – daher ist der Kompressionsverhältnis zwischen den beiden nicht vergleichbar.
- Bildqualität: Die PSNR des dekodierten Outputs im Vergleich zum Originalbild beträgt etwa 36,5 dB. Subjektiv gesehen sind die Verzerrungen in den glatten Bereichen am auffälligsten, und an den scharfen Rändern gibt es eine Verlaufskontur, was mit der Beschreibung im README übereinstimmt.
- Zeit: Die gesamte Kodierung über die Befehlszeile dauert etwa 0,5 Sekunden bei Benutzern, während die Dekodierung und Erstellung des PNG-Datensatzes etwa 0,12 Sekunden benötigt. In diesen Zahlen machen die PNG-IO-Operationen und die CLI-Kosten den größten Teil aus; auch der Desktop-CPU ist nicht die zielgerichtete Plattform, daher dienen diese Zahlen nur als Maßstab.

Zwei strukturelle Beobachtungen sind nützlicher als Zahlen. Erstens bedeutet die festlängere Kodierung in Kombination mit der Zeilenanordnung, dass der Code gleichzeitig dekodiert werden kann, ohne auf das vollständige Eintreffen des Dateisatzes zu warten – dies passt zur Funktion des „on-the-fly Decoders“ in vic-2350. Zweitens können alle Kosten für die Kodierung offline abgewickelt werden: Eine Kodierung auf einem Desktop-Gerät kostet nur die Dekodierkosten auf einem Endgerät. Raphlinus hat selbst in HN auf eine Kommentar geantwortet (der Kommentator wies darauf hin, dass Code, der für RP2350 optimiert ist, fast sicherlich nicht für moderne Desktop-Kerne mit tiefen Pipeline-Architekturen und breitem SIMD-Speicher geeignet ist). Seine Antwort lautete: „Absolutely. Dieser Code ist für hochkapazitätsbeschränkte Geräte optimiert, nicht für moderne Maschinen.“ Optimiert für hochkapazitätsbeschränkte Geräte, nicht für moderne Maschinen.

## Vergleich mit anderen Formaten: JPEG, Amiga HAM und BCn

Der Vergleich mit JPEG zeigt die Designphilosophie von nibnib deutlich. Im README gibt es einen positiven Vergleich: Die DCT-Transformation in JPEG ist mathematisch invertierbar und die Quantisierung ist einfach. Die Kodier- und Dekodiergeschwindigkeit sind bei Basiswerten etwa gleich, und die Suche dient nur dazu, Parameter zu justieren und etwas Bildqualität zu erzielen. In nibnib ist das genau umgekehrt: Die Dekodierung ist sehr einfach, während die Kodierung ein Suchprozess mit mehreren Stufen ist. Beide sind in Wirklichkeit zwei mögliche Lösungen für dasselbe Problem – nämlich wo man die Komplexität platzieren will. JPEG platziert die Komplexität symmetrisch an beiden Enden, was Universalität und eine starke Plattform gewährleistet; nibnib platziert die Komplexität vollständig auf der Kodierseite, was den niedrigsten Dekodierkosten am Endgerät bedeutet. Der Preis ist, dass die Bildqualität bei gleichem Bitprozentsatz niedriger ist als bei JPEG: Es gibt nur 256 Delta-Farbtöne und 565 Farben, und es gibt keine Frequenzbereichsverarbeitung (diese Beurteilung basiert auf den Formatvorgaben, nicht auf tatsächlichen Vergleichen).

In der Kommentarbereich von HN tauchte ein alter Bekannter auf: Zwei Nutzer (wiml, vardump) wiesen darauf hin, dass nibnib dem HAM-Displaymodus ähnelt, der Amiga ähnelt. Nach den in den Kommentaren angegebenen Parametern zeigt HAM auf dem OCS-Chipset mit 6 Eingabebits 12-Bit-Farben mit 4096 Schattierungen an, während der spätere AGA-Chipset 8 Bit verwendet, um 262144 Farben darzustellen. Der Gedanke ist ebenfalls „Übernehmen der Informationen des vorherigen Pixels und nur kleine Änderungen übermitteln“. Die horizontale Streifenartige Unschärfe ähnelt auch. Der Unterschied liegt darin, dass HAM ein Displaymodus ist, der die Anzahl der Farben begrenzt; nibnib hingegen ist ein Speicherformat, das die Decodierungsgeschwindigkeit begrenzt, und der Delta-Wert wirkt gleichzeitig auf die drei RGB-Kanäle, wobei zwei Pixel pro Mal verarbeitet werden. Die Technik aus den 1985er Hausgeräten wurde vierzig Jahre später als Bautechnik für die DVI-Ausgabe von Mikrocontrollern wiederentdeckt – diese Verbindung ist sehr interessant.

Ein weiterer Wert ist die GPU-Texturenkomprimierung der BCn-Serie. augment_me erwähnte in den Kommentaren, dass BCx im Grunde dasselbe mit Codebook/Palette macht und zudem Interpolation zwischen zwei Endpunkten ermöglicht, was mehr und effizientere Farben ermöglicht. nibnib führt keine Interpolation durch; 256 32-Bit-Delta sind alles, was verwendet wird, wodurch die Decodierungsinnerloop keine Interpolation-Logik mehr benötigt. Die Bildqualität geht pro Bit zurück, während die Periode pro Pixel vorherrscht – die Entscheidung ist klar.

Schließlich sollten wir die Philosophie „Das Format wird durch den Decodierungsprozess definiert“ separat betrachten. Dies ist nicht nibnibs Erfindung; die Standards für JPEG und PNG legen ebenfalls fest, dass das Decodieren vorherrscht und dem Kodieren Freiheit bleibt. Doch nibnib hat es bis zum Extrem getrieben: Da der Decoder einfach genug ist, gibt es viel Raum für Verbesserungen im Koder, und alles ist backward kompatibel. Die in dem README vorgesehenen adaptiven Farbpaletten, tiefere Suchvorgänge und Schlangen-Scanning erfordern keine Änderung eines Bytes am bestehenden Decoder. Für ein experimentelles Format, das noch keine eigene Ökologie hat, ist es die richtige Bautechnik, den Decoder festzulegen.

## Wie man es verwendet und wie man es beruhigt

Die Verwendung ist sehr einfach. Das Repository ist ein Standard-Rust-Projekt mit nur 3 Dateien und 351 Zeilen (main.rs, decode.rs, encode.rs). Nach dem Ausführen von cargo build --release erhält man eine Kommandozeile-Software:

```bash
nibnib input.png output.nib -c    # Komprimieren
nibnib output.nib decoded.png -d  # Decodieren zurück in PNG

Eingaben sind nur im PNG-Format möglich; ohne -c oder -d wird erst gekodiert und anschließend dekodiert, was es einfach macht, die Bildqualität direkt zu vergleichen. Für die Ausgabe über RP2350 DVI sollte man den Live-Decoder aus dem image demo im vic-2350-Repository verwenden.

Beruhigung ist wichtiger als die Verwendung; ich werde meine Entscheidungen einzeln erklären:

Erstens ist die Reife eines Projekts ein Experiment. 10 Commits, ein Einzelpersonenprojekt, kein Release, keine C-Implementierung, keine Unterstützung durch Bildbibliotheken. Es eignet sich als Lernbeispiel oder als Material für selbstgemachte Embedded-Projekte. Auf der aktuellen Stufe wird es nicht in irgendeine Produktionsumgebung eingefügt, da seine Ökologie im Vergleich zu PNG und JPEG nicht auf dem gleichen Niveau ist.

Zweitens ist der Anwendungsbereich begrenzt, wie der Autor selbst klar sagt. nibnib dient Situationen, in denen das Decodierungsbudget in Schaltzyklen gemessen wird und die Materialien vorab offline vorbereitet werden können: UI-Ressourcen für eingebettete Geräte, Retro-Spielzeuggrafik, Bildmaterial für Videoausgaben gehören dazu; Fotoarchivierung, Webseitenverteilung und Druckmaterial gehören nicht dazu. Die Originalbeschreibung lautet: Dieses Format wurde nicht für Archivierung entwickelt.

Drittens ist die maximale Bildqualität nicht hoch, und der Kompressor hat sein eigenes Maximum noch nicht erreicht. 4bpp in Kombination mit einer festen, nicht adaptiven Farbpalette bedeutet, dass komplexe Farbbilder zwangsläufig Rauschen und Randverlaufsprobleme aufweisen; die beiden Hauptverbesserungsrichtungen, die der Autor auflistet (adaptive Farbpalette, tiefere Suche), wurden noch nicht umgesetzt. Die Beschreibung des aktuellen Zustands ist auch sehr ehrlich: „What’s presented is a basic, working image compression technique.“ Eine grundlegende, funktionsfähige Version.

Viertens sollte man die Popularität nicht überschätzen. 58 Sterne, 88 Punkte, das sind „interessante Ideen“-Level-Popularitäten, nicht „neue Standards“-Level-Popularitäten. Die Aufmerksamkeit, die es erhält, kommt von einer sauberen Designidee und dem Wissen des Autors im Bereich der Grafik, aber das, ob es morgen genutzt wird oder nicht, ist eine andere Sache.

Meine Schlussfolgerung in einem Satz: Der Wert von nibnib liegt nicht darin, dass es einen zusätzlichen Bildformat gibt, sondern darin, dass es zeigt, wie man ein Format entwirft, bei dem die Decodierungskosten im Vordergrund stehen – indem man zuerst die Decodierungsseite festlegt und die gesamte Komplexität auf die Kodierungseite verlagert, sodass das Format vom Decodierungsprozess definiert wird. Für Ingenieure, die mit eingebetteter Grafik, Retro-Hardware oder Videospielzeug arbeiten, sind diese 351 Zeilen Rust jedenfalls wert, gelesen zu werden; für andere Leser reicht es aus, diese Designphilosophie zu verstehen.

Referenzquellen

• nibnib-Repository und README: https://github.com/raphlinus/nibnib (58 Sterne / 10 Commitments, 02.11.2026)
• Quellcode: src/main.rs, src/decode.rs, src/encode.rs
• HN Diskussion (88 Punkte, 30.10.2026): https://news.ycombinator.com/item?id=50299811
• Autorenseite: http://levien.com/
• vic-2350-Repository: https://github.com/raphlinus/vic-2350

Unterschrift: Yongliang