Nachdem die Gematik das Bundesgesundheitsministerium und ihre Gesellschafter aufgrund des schleppenden Austauschs von elektronischen Heilberufsausweisen (eHBA) und Praxis- sowie Institutionsausweisen (SMC-Bs) gewarnt hatte, läuft die Produktion bei einem der Vertrauensdiensteanbieter Medisign nun auf Hochtouren. Andernfalls könnten tausende Ärzte und Apotheker zum Jahreswechsel nur noch eingeschränkt die Telematikinfrastruktur (TI) nutzen und beispielsweise keine E-Rezepte mehr signieren oder die elektronische Patientenakte befüllen.

Bis zum 31. Dezember 2025 müssen alle eHBA und SMC-Bs Generation 2.0 durch Karten der Generation 2.1 ersetzt werden. Grund dafür ist die Umstellung der bisherigen Verschlüsselung mit RSA 2048 auf das ECC 256 (Elliptic Curve Cryptography). Damit kommen die Beteiligten den Vorgaben des Bundesamts für Sicherheit in der Informationstechnik nach. ECC 256 bietet bei gleicher Sicherheitsstufe deutlich kürzere Schlüssellängen und damit schnellere Verarbeitungszeiten.

Für Apotheken ist die Lage ebenfalls brenzlig, wie die Pharmazeutische Zeitung in ihrem Beitrag verdeutlicht hatte. Versicherte können in betroffenen Apotheken dann keine E-Rezepte mehr einlösen. Speziell für Apotheken führen Ausfälle und TI-Störungen zu Verlusten, weshalb Apotheker kürzlich erneut mehr Zuverlässigkeit beim E-Rezept gefordert hatten.

Laut Angaben der Gematik müssen auch noch 13.000 Konnektoren getauscht werden, die nur RSA-fähig sind. Im Mai hatte die Kassenärztliche Bundesvereinigung (KBV) bereits vor Engpässen gewarnt und gefordert, die Frist zu verlängern, wie es auch in anderen Ländern beschlossen wurde.

Produktion läuft auf Hochdruck

Eine Sprecherin von Medisign räumt gegenüber heise online ein: „Durch die Umstellung auf ein komplett neues Antrags- und Produktionssystem ist es leider zu einem Zeitverzug in der Kartenproduktion von etwa vier Wochen gekommen. Die Daten vom Altsystem mussten ins neue System migriert werden, was sich als sehr komplex und aufwändig erwiesen hat. Mit Hochdruck arbeiten wir aktuell daran, verschiedene Prozesse und Funktionalitäten bei der Kartenbeantragung zu optimieren.“

Mit einer neuen Produktionsstraße wolle man pro 6-Tage-Woche bis zu 15.600 Karten ausstellen. So will der Vertrauensdienstanbieter den Sondertausch planmäßig bis Jahresende abschließen. Bereits in den ersten drei Tagen nach der Umstellung, am 27. September, seien 2.511 SMC-B und eHBA produziert worden. Medisign habe den Produktionsrückstand wieder aufgeholt.

Zudem sollen alle betroffenen Praxen und Apotheken rechtzeitig per E-Mail informiert werden. Kunden will Medisign außerdem ein „vereinfachtes, mit der Gematik abgestimmtes Verfahren anbieten: Dabei wird ausschließlich die Karte selbst getauscht – eine erneute Identifizierung ist nicht erforderlich, wenn sich die Ausweisdaten nicht geändert haben“, so die Sprecherin.

Sicherheitsforscherin Bianca Kastl sagt zum Tausch der Karten: „Traditionell ist das Problem kryptographischen Materials in der Telematikinfrastruktur, dass die Identifizierung oder die korrekte Zustellung von Karten schwach überprüft wird. Sofern neue Karten nicht wieder einfach so an die Käsetheke geliefert werden können und stattdessen sicher mit Identifikation zugestellt werden, mag das für einen Tausch der Karten reichen. Andernfalls ergeben sich hier neue Angriffsszenarien“.

Die Probleme bei Medisign reihen sich ein in eine Serie von Schwierigkeiten bei der Digitalisierung des Gesundheitswesens. Erst im August gab es Kompatibilitätsprobleme zwischen CGM-Praxissoftware und Rise-Konnektoren, die wochenlang den Zugriff auf die elektronische Patientenakte verhinderten. Für die Weiterentwicklung der TI setzt die Gematik künftig auf ein Zero-Trust-Sicherheitskonzept, das ab Mitte 2026 schrittweise eingeführt werden soll. Erst kürzlich hatte Bundesgesundheitsministerin Nina Warken ein Update der Digitalisierungsstrategie angekündigt – dies soll auch der Betriebsstabilität der TI zugute kommen.

(mack)

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)