Adafruit hat mit dem Fruit Jam – Mini RP2350 Computer einen charmanten Winzling vorgestellt, der Retro-Feeling mit moderner Technik kombiniert. Auf einer Platine im Kreditkartenformat (ISO/IEC 7810 ID-1) stecken erstaunlich viele Features: Ein RP2350B-Dual-Core Cortex-M33-Mikrocontroller (150 MHz), 16 MB Flash und 8 MB PSRAM, USB-C, Micro-SD-Slot, HDMI-kompatibler DVI-Ausgang, Stereo- und Mono-Audio, ein 2-Port-USB-Hub für Maus, Tastatur oder Gamepads, einen extra ESP32-C6 für WLAN sowie diverse GPIOs und NeoPixel für optische Spielereien.

Das Kit (39,95 US-Dollar) kommt inklusive Top-Plate, Mini-Speaker und Bumperfüßen. Angeschlossen an Monitor, Tastatur und Maus wird der Fruit Jam unter anderem zu einem kleinen Retro-Computer für CircuitPython, Arduino oder PicoSDK-Projekte – und ja: „It can run Doom“.

Retro-Feeling mit NES-Emulation

Gemeinsam mit der Community hat Adafruit eine Anleitung veröffentlicht, wie sich der Fruit Jam als NES-Konsole nutzen lässt. Möglich macht es der pico-infonesPlus-Emulator von Frank Hoedemakers, ursprünglich aus InfoNES hervorgegangen und für den RP2040 adaptiert. Neben der Bildausgabe via HDMI unterstützt der Emulator Onboard-Sound, DAC-Kopfhörerausgang, einen VU-Meter-Effekt über die verbauten Neopixel und sogar Zwei-Spieler-Modi – per USB-Controller plus Wii-/NES-/SNES-Classic-Controller über I²C. Für Besitzer eines passenden Gamepads ist damit der Aufbau einer handlichen Wohnzimmer-Konsole fast plug-and-play.

Zur Installation genügt es, die vorbereitete .UF2-Firmware auf den Fruit Jam zu flashen und ROMs (Homebrew ist die legale Wahl) auf eine SD-Karte zu kopieren. So lebt das Konsolenfeeling der 80er auf moderner Bastlerhardware neu auf. Der Fruit Jam ist nicht nur ein günstiger, vielseitiger Bastelrechner, sondern mit NES-Emulator auch ein echtes Retro-Gaming-Gadget.

Noch mehr Retro: Atari-Emulator im Make Magazin

Wer nicht nur Nintendo-Klassiker zocken, sondern auch in die Welt der Atari-Homecomputer eintauchen will, findet im aktuellen Make Magazin einen passenden Bauvorschlag. Dort zeigt Ulrich Schmitz, wie man auf Basis eines ESP32 einen Atari-800-Emulator samt Gehäuse und originalgetreuen Joysticks realisiert. Der Artikel erklärt die Emulation des legendären 6502-Prozessors und spezieller Atari-Chips wie ANTIC oder POKEY, gibt Tipps für Controller-Integration – und weckt garantiert Erinnerungen an Homecomputer-Zeiten.

(caw)

Linus Torvalds hat den Support für Bcachefs aus dem Hauptentwicklungszweig seines Kernels entfernt; das in neun oder zehn Wochen erwartete Linux 6.18 wird mit dem Dateisystem formatierte Datenträger daher von Haus aus nicht mehr einbinden können. Der für Linux-Verhältnisse ungewöhnliche Rauswurf erfolgte rund 24 Stunden nach der Freigabe von Linux 6.17 zum Wochenstart. Diese Version hatte bereits keine Bcachefs-Neuerungen mehr gebracht, denn der Linux-Erfinder hatte den Stand dort vor zwei Monaten als „extern gewartet“ gekennzeichnet und damit eingefroren – nach mehrfachem Zank mit Kent Overstreet, dem Erfinder und Hauptentwickler von Bcachefs.

Bcachefs lässt sich jetzt via DKMS einrichten

Der Rauswurf sollte nur wenige Linux-Anwender betreffen, denn der Bcachefs-Code in Linux ist nie dem experimentellen Stadium entwachsen. Da einzelne Distributionen das Dateisystem aber als Option für Tester anboten, hat es durchaus Nutzer. Darunter sind auch einige sehr laute Fürsprecher. Kein Wunder, lockt doch Bcachefs mit einer attraktiven Kombination einiger von anderen Dateisystemen bekannten Features.

Für diese und zukünftige Anwender hat Overstreet einige Umbaumaßnahmen am Code vorgenommen, die er fortan extern entwickelt, wie er es vor der Aufnahme bei Linux 6.7 vor rund eindreiviertel Jahren getan hat. Durch die Umbauten lässt sich Bcachefs jetzt per DKMS (Dynamic Kernel Module Support) bei verschiedensten Kerneln ab Linux 6.16 nachrüsten – und wird bei Kernel-Updates idealerweise auch automatisch passend zum neuen Kernel übersetzt. Das Ganze kennen viele Anwender etwa von Distributionen wie Debian oder Ubuntu, die das ältere, proprietäre Kernel-Modul der Nvidia-Grafiktreiber via DKMS handhaben.

Auch zur Virtualisierung mit VMware oder VirtualBox oder zum Support des Dateisystem OpenZFS setzen viele Distributionen auf das unabhängig vom Kernel gewartete DKMS. Das funktioniert in vielen Fällen recht zuverlässig, fällt gelegentlich aber beim Kompilieren auf die Nase. Das liegt zumeist nicht an DKMS, sondern am eher monolithischen Design von Linux.

Bei dem sind Treiber, Dateisystemcode und nichts Separates, sondern formen zusammen den „Kernel“ – auch dann, wenn man beim Bau des Kernels festlegt, einige Teile als nur bei Bedarf nachgeladenes Modul auszulagern. Bei gängigen Linux-Distributionen passen Kernel-Module daher nur zu dem Kernel-Image, für das sie kompiliert wurden. Diese sind somit eben nicht ab- oder aufwärtskompatibel, wie man es von stabilen Plug-in- oder Add-on-Schnittstellen bei Browsern oder Treibern von Windows kennt.

Gefahr des „sich selbst Aussperrens“ durch instabile Schnittstellen

Das liegt auch an einem anderen Aspekt: Um den Kernel schnell und schlank zu halten, verändern Torvalds und seine Helfer bei Bedarf die Kommunikationswege zwischen den verschiedenen Bestandteilen von Linux; dabei nehmen sie keine Rücksicht auf externe gewarteten Kernel-Code, der sich über diese Wege einklinkt. Entwickler von extern entwickeltem Kernel-Code wie fortan Bcachefs müssen diesen daher hin und wieder an die Belange neuer Linux-Versionen anpassen; das kann alle paar Wochen oder nur alle paar Jahre nötig sein, je nachdem, welche Kernel-Funktionen der externe Code verwendet und wie häufig sich diese Kernel-seitig ändern.

Diese Änderungen am externen Code müssen es dann aber auch zu den Nutzern schaffen, bevor diese auf Kernel-Version mit veränderten Schnittstellen wechseln. Hakt es daran, schlägt beim Anwender das automatische Kompilieren des Moduls via DKMS fehl.

Bei extern gewarteten Modulen für Grafikchips führt das zu Problemen, die zumindest Kenner oft mit einigen Handgriffen lösen können. Bei Modulen für Dateisysteme kann es schwieriger sein, denn wenn dem startenden Kernel ein Modul für das Root-Dateisystem fehlt, kann man das System darüber nicht mehr starten und daher kein passendes neues Modul einrichten. Um sich aus so einer Situation ohne Live-Linux heraus zu manövrieren, belassen einige Distributionen den jeweils letzten als funktionierend bekannten Kernel bei Updates als Boot-Option zurück. Derlei braucht man im dümmsten Fall auch, wenn neuer Modulcode nicht funktioniert und man das alte Modul schon gelöscht hat.

Distributions-spezifische Anpassungen erschweren die Auslieferung

Der DKMS-Weg von Bcachefs hat einen weiteren Nachteil, wie Overstreets Mail zur breiten Verfügbarkeit des DKMS-Ansatzes zeigt: Statt Bcachefs mehr oder weniger frei Haus über den Kernel an Distributionen zu verteilen, sind nun Anpassungen für Eigenarten der verschiedensten Distributionen nötig. Zur möglichst einfachen Handhabung durch die Nutzer braucht es ferner idealerweise auch Distributions-spezifische Pakete, die jemand konstant pflegt und testet.

Beim Support für Arch Linux, Debian und Ubuntu scheint die Lage demnach schon recht gut zu sein. Bei Fedora ist es im Werden, während bei openSUSE noch allerlei Fragezeichen im Raum stehen; dessen Entwickler hatten kürzlich den Bcachefs-Support bei Tumbleweed-Kernel beim Wechsel auf 6.17 deaktivierten und Overstreets Verhalten dabei kritisierten.

DKMS ist der Grund für den schnellen Rauswurf

Die Bcachefs-Unterstützung zur Handhabung via DKMS nennt Torvalds jetzt als Grund für die Entfernung des Dateisystems – die Kenner mittelfristig erwartet hatten, aber letztlich jetzt viel flotter kam, als es bei der Stilllegung von Bcachefs vor zwei Monaten schien. Der waren mehrere Streitereien vorangegangen, vor allem zwischen Overstreet und Torvalds. Gleich zweimal hatte es zwischen den beiden lautstark gekracht, weil der Bcachefs-Erfinder Code mit neuen Features zur Aufnahme während der längeren Stabilisierungsphase an den Linux-Erfinder schickte, anstatt während der kurzen Hauptentwicklungsphase (dem „Merge Window“), die dafür vorgesehen ist. Overstreet war aber auch mehrfach mit anderen Entwicklern zusammen gerasselt. Unter anderem, weil er hinterrücks den von ihnen betreuten Code geändert hatte.

Der streitbare Kalifornier hat Bcachefs seit über zehn Jahren weitgehend im Alleingang entwickelt – auch, weil sich mehrere mit der Zeit dazu gestoßene Mitstreiter über kurz oder lang mit ihm überworfen haben. Bis zu einem gewissen Grad ist das nur menschlich, schließlich passiert derlei auch beim Hasenzüchter- und Sportvereinen; bei Häufigkeit und Tonfall der Streitereien hebt sich die Bcachefs-Entwicklung aber negativ von anderen Software-Projekten und auch dem Linux-Kernel ab.

Dateisystem-Entwicklung ist hart

Derlei Drama und der Zank mit zentralen Kernel-Entwicklern dürften Schwergewichte aus dem Linux-Bereich verschrecken, die jährlich schätzungsweise mehrere Millionen von US-Dollar in Hardware und Mitarbeiter investieren, um die direkt in Linux enthaltenen Dateisysteme zu testen und zu verbessern – etwa Google (Ext4), Meta und Suse (Btrfs) oder Oracle und Red Hat (XFS).

Für Overstreet und seine Unterstützer wird es schwer, da mitzuhalten, denn Dateisysteme sind komplex und Linux-Nutzer machen die kuriosesten Dinge mit ihnen – daher sind meist viele Jahre Feldtest und mühsames Feintuning nötig, bis ein universelles Dateisystem wie Bcachefs wirklich stabil und in vielen der gängigen Einsatzgebiete performant arbeitet.

Hier hat Bcachefs noch viel Arbeit vor sich, auch wenn sein Hauptentwickler den extern gewarteten Dateisystemcode kürzlich als „stabil“ deklariert hat. Zumindest, wenn es ähnlich wie bei der Entwicklung von Btrfs, Ext4, Reiserfs oder XFS läuft: Auch dort war ab einem vergleichbaren Punkt noch jahrelange Arbeit und damit letztlich auch viel Geld nötig, um die Erwartungen der breiten Anwenderschar an Robustheit und Performance zu befriedigen.

(ktn)

Zahlen wirken in Programmen so selbstverständlich, dass viele Entwicklerinnen und Entwickler sie intuitiv wie in der Mathematik behandeln: Addition, Subtraktion, Multiplikation – was soll da schon schiefgehen? In der Praxis lauern hier jedoch zahlreiche Fallstricke. Speicherbegrenzungen, Rundungsfehler, Konvertierungen zwischen Datentypen und die unterschiedliche Behandlung von Ganzzahlen und Gleitkommazahlen führen immer wieder zu katastrophalen Fehlern.

Muster 2: Überlauf, Arithmetik und Präzision: Wenn Zahlen kippen

Ein ikonisches Beispiel dafür ist der Fehlschlag des ersten Ariane-5-Starts im Jahr 1996. Nur 37 Sekunden nach dem Start verließ die Rakete ihre Flugbahn, begann sich unkontrolliert zu drehen und zerstörte sich schließlich selbst. Die Ursache war nicht ein Materialproblem oder ein Defekt an der Rakete, sondern ein Softwarefehler in der Trägheitsnavigationssoftware.

Konkret versuchte das System, einen 64-Bit-Gleitkommawert in einen 16-Bit-Integer zu konvertieren. Der Wert war für die Ariane 5 jedoch zu groß und es kam zu einem Überlauf, der dann eine Ausnahme auslöste. Die Folge: Das gesamte Leitsystem schaltete sich ab. Da die Rakete zwei identische Systeme hatte, die synchron liefen, wiederholte sich der Fehler sofort auf dem Backup – die Redundanz konnte also nicht helfen.

Das wirft die Frage auf: Warum passiert so etwas in einem milliardenschweren Raumfahrtprogramm? Die Antwort ist tatsächlich lehrreich: Die Software der Ariane 5 basierte in Teilen auf dem Vorgängermodell Ariane 4. Dort waren die Wertebereiche kleiner, und ein 16-Bit-Integer war völlig ausreichend. Bei der Ariane 5 lagen die Beschleunigungen jedoch in einem anderen Bereich. Die alten Annahmen passten nicht mehr, aber die Entwickler haben die entsprechenden Codepfade nie überprüft – schließlich hatte die Software ja bereits jahrelang zuverlässig funktioniert.

Dieses Muster findet sich auch heute immer wieder in unzähligen Projekten:

• Entwicklerinnen und Entwickler übernehmen alte Codepfade, ohne ihre Gültigkeit für neue Einsatzbedingungen zu prüfen.
• Implizite Typumwandlungen oder fehlende Bereichsprüfungen führen im Grenzfall zu Überläufen.
• Fehlerbehandlung fehlt oder ist zu global – wie im Fall der Ariane, bei der eine einzelne Ausnahme zum Totalausfall führte.

In der Praxis begegnen Developer diesem Risiko immer wieder – auch in völlig alltäglichen Projekten. Typische Symptome sind:

• Plötzliche Sprünge oder negative Werte in Zählern,
• NaN-Ergebnisse oder Inf-Werte bei Gleitkommarechnungen und
• stille Rundungsfehler, die sich erst bei großen Zahlen oder nach langer Laufzeit bemerkbar machen.

Das Schlimmste daran ist, dass Gegenmaßnahmen durchaus bekannt sind, häufig aber aus Zeit- und Kostengründen vernachlässigt werden:

1. Explizite Bereichsanalysen: Vor allem bei Übernahmen prüfen, ob alle Wertebereiche noch passen.
2. Saturating Arithmetic oder Clamping: Wenn ein Wert den zulässigen Bereich überschreitet, diesen auf das Maximum setzen oder den Vorgang abbrechen, statt unbemerkt überlaufen zu lassen.
3. „Fail fast“ bei kritischen Konvertierungen: Lieber ein gezielter Fehler, der sich früh zeigt, als eine stille Datenkorruption.
4. Telemetrie und Monitoring: Wertebereiche im Betrieb überwachen und auffällige Ausreißer melden.

Interessant dabei ist auch die psychologische Komponente: Viele Teams verlassen sich auf ihre Testabdeckung und übersehen, dass Testdaten oft zu nett sind. Grenzwerte, Extrembereiche und ungewöhnliche Kombinationen fehlen häufig. Erst Property-based Testing, Fuzzing oder gezielte Grenzwerttests decken die kritischen Fälle auf.

Der Ariane-5-Vorfall hat gezeigt, dass selbst in hochkritischen Projekten mit gefühlt unendlichem Budget ein scheinbar banales Zahlenproblem zu einer Milliardenkatastrophe führen kann. Für den Alltag in der Unternehmens-IT heißt das: Jede Zahl ist ein Modell, und Modelle haben Grenzen. Wer diese Grenzen kennt und absichert, verhindert nicht nur Abstürze, sondern spart sich auch stundenlange Fehlersuche bei subtilen Rundungsfehlern.

Aus Softwarefehlern lernen – die Serie

Diese Artikelserie stellt neun typische Fehlerklassen vor, die in der Praxis immer wieder auftauchen – unabhängig von Branche oder Technologie. In jeder Kategorie wird die Serie ein konkretes Beispiel vorstellen, dessen Ursachen analysieren und daraus ableiten, was Softwareentwicklerinnen und Softwareentwickler langfristig lernen können.

Im nächsten Teil lesen Sie: Concurrency und Scheduling: Wenn sich Prozesse gegenseitig blockieren.

(who)