Anmelden
(Bild: PiSugarStudio / Youtube)
Ein tragbarer KI-Sprachassistent, der komplett ohne Cloud oder WLAN funktioniert, hat ein Maker aus Hongkong gebaut. Als Basis dazu dient ein Raspberry Pi 5.
In einer Reihe von Videos [1] erklärt Jdaie Lin detailliert, wie sein vollständig offline nutzbarer KI-Sprachassistent aufgebaut ist, und teilt mit, wie jeder Interessierte ihn nachbauen kann. Hardwareseitig kommt die Whisplay-HAT-Erweiterung zum Einsatz, die ein kompaktes 1,69-Zoll-Farbdisplay bereitstellt. Für die Stromversorgung sorgt der Akku Pi Sugar 3 mit 5000 mAh, sodass das Gerät auch längere Zeit ohne externe Stromquelle betrieben werden kann.
Um die für KI-Anwendungen erforderliche hohe Rechenleistung bereitzustellen, hat Lin die KI-Beschleunigerkarte LLM-8850 [2] integriert. Die Karte im M.2-Format stammt vom chinesischen Hersteller M5Stack und ist speziell für lokale KI-Aufgaben – darunter große Sprachmodelle (LLMs), Vision- und Audioanwendungen – auf kleinen Single-Board-Computern wie dem Raspberry Pi 5 konzipiert. Laut Lin eignet sich die LLM-8850 besonders gut für Offline-KI-Anwendungen, für die die 24 Billionen Rechenoperationen pro Sekunde (TOPS) genügen. Allerdings hat diese Leistung ihren Preis: Mit 139 US-Dollar kostet die Karte deutlich mehr als ein Raspberry Pi 5 – und sie erzeugt dabei erheblich Abwärme. Alternativen gibt es vom Raspi-Hersteller selbst (ab 112 €) [3].
(Bild: youtube.com/@PiSugarStudio)
Um die Karte ausreichend zu kühlen und einen guten Luftstrom zu gewährleisten, experimentierte Lin mit verschiedenen Aufbauvarianten. Letztlich entschied er sich dafür, die LLM-8850 auf einem Waveshare Dual M.2 HAT [4] zu montieren. Dieser Aufbau ermöglicht nicht nur eine effektive Kühlung, sondern bietet auch die Option, später eine SSD unter dem Whisplay HAT nachzurüsten.
Im Dezember 2025 stellte Lin zudem ein Upgrade des Geräts vor: Der KI-Sprachassistent erhielt eine Kamera (Raspberry Pi-Kamera v3 (ab 25,50 €) [5]) und ein schickes Gehäuse, um ihn alltagstauglich zu machen. Mit der Kamera ist nun auch Bilderkennung möglich.
Für die lokale Verarbeitung von Sprache und Antworten kommen verschiedene KI-Komponenten zum Einsatz: Von Ollama kommt ein lokales Sprachmodell, Whisper übernimmt die Sprache-zu-Text-Funktion, und Piper wandelt den Text wieder in gesprochene Sprache um (Text-to-Speech).
KI-Sprachassistenten auf Basis des Raspberry Pi sind nicht neu – ein vergleichbares Projekt [6] wurde bereits in der Make 7/23 vorgestellt, allerdings noch mit Cloud-Anbindung. Ein entscheidender Vorteil von Lins aktueller Version ist die Datensicherheit: Alle Berechnungen und Datenverarbeitungen erfolgen lokal, sodass kein Byte das Gerät verlässt, sofern der Nutzer dies nicht wünscht. So entsteht ein vollständig autarker, offline-fähiger Sprachassistent, der Datenschutz und Leistung vereint.
URL dieses Artikels:
https://www.heise.de/-11150389
Links in diesem Artikel:
[1] https://www.youtube.com/watch?v=IuTD5OMaVVU
[2] https://shop.m5stack.com/products/ai-8850-llm-accleration-m-2-module-ax8850
[3] https://preisvergleich.heise.de/raspberry-pi-ai-hat-a3593420.html?cs_id=1206858352&ccpid=hocid-hardware_hacks
[4] https://www.waveshare.com/wiki/PCIe_TO_M.2_HAT%2B
[5] https://preisvergleich.heise.de/raspberry-pi-kameramodul-v3-a2913854.html?cs_id=1206858352&ccpid=hocid-hardware_hacks
[6] https://www.heise.de/ratgeber/Raspberry-Pi-Projekt-KI-Sprachassistent-mit-eigenem-sprechenden-Avatar-bauen-9591453.html
[7] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[8] mailto:mch@make-magazin.de
Copyright © 2026 Heise Medien
(Bild: espressif)
Mit dem ESP32-E22 stellt Espressif einen Funk-Co-Prozessor vor, der WLAN und Bluetooth komplett übernimmt und Host-CPUs entlastet.
Espressif hat mit dem ESP32-E22 [1] einen eigenen Wi-Fi-6E-Baustein vorgestellt. Der Chip markiert den Start einer neuen Produktlinie und richtet sich weniger an klassische Mikrocontroller-Anwendungen, sondern an Systeme, bei denen die Funkkommunikation besonders leistungsfähig, stabil und ausgelagert sein soll. Technisch handelt es sich um einen sogenannten Radio Co-Processor (RCP), der WLAN und Bluetooth vollständig eigenständig abwickelt und einen Host-Prozessor, der die komplette Netzwerkarbeit abnimmt.
Das unterscheidet sich deutlich vom bekannten „ESP32 macht alles selbst“-Ansatz. Der ESP32-E22 läuft nicht als Hauptcontroller, sondern hängt an einem bestehenden System. Das kann zum Beispiel ein anderer Mikrocontroller oder sogar ein Embedded-Linux-Board sein. Die Anbindung erfolgt über schnelle Schnittstellen wie PCIe 2.1 oder SDIO 3.0. Das bedeutet: Wer bisher WLAN-Stacks, TLS, Roaming oder Bluetooth-Handling selbst integrieren musste, kann diese Aufgaben komplett an den Funkchip auslagern und sich auf Applikationslogik konzentrieren.
Herzstück des Chips ist ein von Espressif selbst entwickelter Dual-Core-RISC-V-Prozessor mit 500 MHz. Darauf läuft der komplette Wi-Fi-6E- und Bluetooth-Stack inklusive Security, Authentifizierung, Scanning und Bluetooth-Host-Funktionalität. Wi-Fi 6E unterstützt dabei erstmals auch das 6-GHz-Band zusätzlich zu 2,4 und 5 GHz. Technisch kommen 160-MHz-Kanäle, 2 × 2 MU-MIMO, Beamforming und moderne Scheduling-Mechanismen zum Einsatz. In der Praxis soll das für höhere Datenraten, geringere Latenzen und vor allem stabilere Verbindungen in stark belegten Funkumgebungen sorgen.
Auf der Bluetooth-Seite integriert der ESP32-E22 sowohl Classic Bluetooth (BR/EDR) als auch Bluetooth Low Energy 5.4. Beides kann parallel betrieben werden, wobei Koexistenz-Algorithmen Funkkollisionen vermeiden sollen.
Interessant ist auch der Blick auf die Performance: Dank 1024-QAM (Quadrature Amplitude Modulation. Modulationsverfahren zur Datenübertragung; höherer Wert = höhere Datenrate) erreicht der Chip theoretische Datenraten von bis zu 2,4 Gbit/s. Für Maker eröffnet das Anwendungsfälle wie drahtlose Videoübertragung, schnelle Backbones zwischen Geräten oder latenzarme Steuerverbindungen, etwa für Robotik oder AR-/VR-Zubehör.
Der ESP32-E22 ersetzt keinen Mikrocontroller, sondern ergänzt ihn (wobei das Maker ja noch nie aufgehalten hat). Entwicklungsmuster sind bereits verfügbar. Wann und in welcher Form der Chip im Maker-Handel auftaucht, bleibt abzuwarten.
Wer mehr über das ESP-Ökosystem erfahren will, findet dazu alles in unserem ESP32-Kompass [2].
URL dieses Artikels:
https://www.heise.de/-11147975
Links in diesem Artikel:
[1] https://www.espressif.com/en/news/ESP32_E22_Announcement
[2] https://www.heise.de/ratgeber/ESP32-Hardware-Kompass-Welches-Modell-Sie-fuer-Ihr-naechstes-Projekt-benoetigen-10321040.html
[3] https://www.heise.de/make
[4] mailto:das@heise.de
Copyright © 2026 Heise Medien
(Bild: NanoBanana/Google)
Adafruit und SparkFun beharken sich seit einiger Zeit, nun ist die Situation mit der Beendigung der Geschäftsbeziehungen seitens SparkFun eskaliert.
Zwei der bekanntesten Maker-Hardware-Hersteller haben ihre langjährige Geschäftsbeziehung beendet. SparkFun wirft Adafruit Verstöße gegen den Code of Conduct vor, Adafruit kontert mit Vorwürfen von Belästigung und unbezahlten Lizenzgebühren. Im Zentrum der Auseinandersetzung: Teensy-Entwicklungsboards. Hat dies Auswirkungen für die Maker-Community?
Am 8. Dezember 2025 kündigte SparkFun Electronics CEO Glenn Samala in einer offiziellen Stellungnahme an, dass das Unternehmen ab dem 15. Januar 2026 keine Geschäfte mehr mit Adafruit Industries tätigen werde. Betroffen sind vor allem Teensy-Entwicklungsboards, die Adafruit über SparkFun bezog und weiterverkaufte.
SparkFuns Begründung in [1]der Stellungnahme: Verstöße gegen den Code of Conduct durch Adafruit-Mitarbeiter. Das soll konkret sein: Versenden „offensiver, antagonistischer und herabwürdigender E-Mails und Materialien“ an SparkFun-Mitarbeiter, ehemalige Mitarbeiter und Kunden. Sowie „Unangemessenes Einbeziehen eines SparkFun-Kunden in eine private Angelegenheit“.
Adafruits Gegendarstellung: Phillip Torrone, Managing Director von Adafruit (verheiratet mit Adafruit-Gründerin Limor „Ladyada“ Fried), erklärte in einem Hacker News-Forum-Post [2], dass er SparkFun-Gründer Nate Seidle wegen „mehrfacher belästigender Handlungen“ gemeldet habe, die sich gegen Fried richteten. Statt das Problem anzugehen, habe SparkFun „den Boten getötet“ und Adafruit von Teensy-Lieferungen abgeschnitten.
Laut Torrone reichen die Konflikte weit zurück. In einem ausführlichen Post im PJRC-Forum (dem Hersteller der Teensy-Boards) [3] schildert er mehrere Vorfälle, die von „Hass-Websites“ über Photoshop manipulierte Bilder, Website Scraping von Adafruits Servern, Quellcode ohne Herkunftsquellen, Verwendung von Markennamen bis zur Belästigung von Adafruit-Mitarbeitern und den Geschäftsführern reichen. Nachdem diese Vorwürfe erneut aufgetaucht waren, sei die Geschäftsbeziehung seitens SparkFun beendet worden.
Torrone erwähnt auch, dass Nate Seidels Ehefrau Alicia die Open-Source-Hardware-Association (OSHWA) leitet. Als er diesen möglichen Interessenkonflikt meldete (die Beziehung wurde nicht offengelegt), habe Seidle mit weiteren Aktionen reagiert.
Teensy-Boards, entwickelt von Paul Stoffregen und produziert von PJRC, sind in der Maker-Community recht beliebt. Die leistungsstarken ARM-Mikrocontroller-Boards mit Arduino-Kompatibilität werden für Audio-Projekte, Synthesizer, MIDI-Controller und anspruchsvolle Embedded-Anwendungen eingesetzt.
Seit dem 15. Januar 2026 kann Adafruit keine Teensy-Boards mehr über SparkFun beziehen und im Shop anbieten.
Dennoch sollte die Versorgung für den Maker weiter sichergestellt sein, wenn man nicht nur bei Adafruit kaufen will. Adafruit plant nun anscheinend eine eigene Alternative zum Teensy, möglicherweise unter dem Namen „Freensy“. Im PJRC-Forum startete Torrone einen Thread [4] mit der Frage: „Open-source teensy-compatible – what features do you want?“. Damit bietet sich auch die Chance für Maker bei den Features mitzubestimmen.
In einer überraschenden Reaktion antwortete Paul Stoffregen, der Schöpfer von Teensy, selbst im Thread – allerdings ohne sich zur SparkFun-Adafruit-Kontroverse zu äußern. Stattdessen ging er sachlich auf technische Fragen ein und erklärte Details zur Teensy-Architektur.
So unschön dieser Streit ist, kurzfristig drohen keine Versorgungsengpässe. Teensy bleibt über PJRC, SparkFun und andere Distributoren verfügbar. Für die PJRC könnte der Streit aber bedeuten, dass die interessante und gut dokumentierte Board-Familie an Bedeutung verliert, weil Maker auf andere Boards umsteigen.
Mittelfristig und wenn Adafruit tatsächlich ein „Freensy“-Board entwickelt, könnte dies den Markt beleben und Innovation fördern. Weiterhin könnte eine vollständige Open-Source-Alternative die Maker-Community stärken – sofern sie technisch mit Teensy mithalten kann.
Teensy bleibt vorerst die erste Wahl für Audio- und Klangsynthese-Anwendungen dank der Audio-Library von Paul Stoffregen. Der ESP32 mit I²S gewinnt allerdings auch langsam Popularität. Spezielle Audio-Boards wie etwa die Daisy Boards [5]werden schon in vielen Studios als Effektgeräte [6] oder Eurorack-Module [7] eingesetzt und sind dank Open-Source auch für Maker interessant.
Für Maker, die sich nicht zwischen den Fronten entscheiden möchten oder Teensy-Alternativen suchen:
URL dieses Artikels:
https://www.heise.de/-11147330
Links in diesem Artikel:
[1] https://www.sparkfun.com/official-response
[2] https://news.ycombinator.com/item?id=46616775
[3] https://forum.pjrc.com/index.php?threads/open-source-teensy-compatible-what-features-do-you-want.77584/page-2#post-364465
[4] https://forum.pjrc.com/index.php?threads/open-source-teensy-compatible-what-features-do-you-want.77584/
[5] https://daisy.audio/hardware/PatchSM/
[6] https://daisy.audio/product/Daisy-Field/
[7] https://daisy.audio/product/Daisy-Patch-Init/
[8] https://www.heise.de/make
[9] mailto:caw@make-magazin.de
Copyright © 2026 Heise Medien
(Bild: Bolt Industries)
Dieses Kickstarter-Projekt zeigt elektronische Bauteile nicht auf Papier, sondern als funktionierende Schaltungen zum Ausprobieren.
Mit „Reference Circuits, Volume 0 [1]“ von Bolt Industries kann auf Kickstarter eine ungewöhnliche Lernhilfe für Elektronik unterstützt werden. Diese wird nicht gelesen, sondern eingeschaltet. Statt Papier besteht das 12-seitige „Buch“ vollständig aus Leiterplatten und auf jeder Seite sind reale Schaltungen aufgetragen. Schließt man das Buch an eine Stromversorgung an, zeigen LEDs und Taster ganz genau, wie eine bestimmte Schaltung funktioniert. Ziel ist es, elektronische Bauteile nicht nur theoretisch zu erklären, sondern sie direkt im Betrieb erlebbar zu machen. Anfassen ausdrücklich erlaubt!
Das Projekt ist ein Einstieg in die Grundlagen der Elektronik. Behandelt werden Bauteile wie Widerstände, Kondensatoren, Dioden, Transistoren, aber auch Sicherungen, Induktivitäten, Relais, Optokoppler und DC/DC-Wandler. Jede Seite widmet sich einem Themenblock und kombiniert kurze Erklärungen mit einer fest integrierten Demonstrationsschaltung. Strom anlegen, Knopf drücken, LED beobachten. Wer wissen will, wie eine LED sich in einer Schaltung verhält, bekommt hier ein direktes visuelles Feedback.
Für Maker und jene, die es werden wollen, ist das deshalb interessant, weil viele der gezeigten Effekte exakt das widerspiegeln, was später auf dem Breadboard oder der eigenen Platine passiert. Auf der Widerstandsseite lassen sich Farbcode und SMD-Beschriftung vergleichen, bei den Dioden wird der Zener-Effekt per Potentiometer sichtbar, und bei Transistoren sieht man buchstäblich, wann sie in die Sättigung gehen.
(Bild: Bolt Industries [2])
„Volume 0“ ist dabei bewusst als Einstieg gedacht. Die Macher hatten bereits mit den vorherigen Bänden 1 und 2 Erfolg, die laut Projektbeschreibung über 1.000 Mal verkauft wurden und inzwischen in Hobbykellern, Schulen und Werkstätten liegen. Der neue Band soll die Lücke schließen für alle, die entweder ganz neu einsteigen oder ihre Grundlagen noch einmal auffrischen wollen.
Als Referenz auf dem Labortisch, als Anschauungsobjekt oder als Reminder, warum Elektronik manchmal tut, was sie tut, erfüllt das PCB-Buch einen klaren Zweck.
Die Kickstarter-Kampagne hat ihr Ziel von 5000 US-Dollar bereits erreicht (und mit aktuell 8851 US-Dollar überschritten). Noch kann man das Buch für umgerechnet 37 Euro unterstützen und bekommt dann im Mai diesen Jahres seine Maker-Hilfe.
Wer mehr über die Maker-Wissensvermittlung erfahren will, findet bei uns einen Einblick, wie Maker-Skills in der Schule gefördert werden [3].
URL dieses Artikels:
https://www.heise.de/-11140727
Links in diesem Artikel:
[1] https://www.kickstarter.com/projects/boltind/reference-circuits-volume-0-electronic-components/description
[2] https://www.kickstarter.com/projects/boltind/reference-circuits-volume-0-electronic-components/description
[3] https://www.heise.de/ratgeber/Wie-Maker-Skills-in-der-Schule-gefoerdert-werden-ein-Erfahrungsbericht-10299421.html
[4] https://www.heise.de/make
[5] mailto:das@heise.de
Copyright © 2026 Heise Medien
Creality präsentierte auf der CES 2026 neue KI-gestützte Fertigungslösungen für den 3D-Druck.
(Bild: Creality)
Die CES 2026 in Las Vegas brachte viel Neues zum 3D-Druck. So zeigte Creality KI-gestützte Multi-Color-Drucker und MetalPrinting präsentierte Metall-Extruder.
Auch wenn die CES im Bereich 3D-Druck-Innovationen nicht mehr der Taktgeber ist, haben doch viele namhafte Unternehmen der Branche die Veranstaltung genutzt, dort zum Jahresauftakt neue Gerätegenerationen und Drucktechniken vorzustellen.
Creality enthüllt den SPARKX i7 [1], einen Desktop-3D-Drucker [2] mit integrierter KI-Unterstützung für eine einfachere Bedienung. Der Drucker schneidet das Filament automatisch, reduziert Abfall durch das CFS-Vier-Farben-System und optimiert Drucke mit Pressure Advance für höhere Präzision. Nutzer steuern dabei den Druckprozess per Mobil-App und können 3D-Modelle KI-gestützt mit wenig Aufwand generieren oder anpassen. Creality nimmt inzwischen Vorbestellungen für Nordamerika entgegen. Geplant ist auch der Verkauf nach Europa.
MetalPrinting Inc. aus Korea präsentiert mit dem Gauss MT90 [3] einen kompakten Metall-3D-Drucker mit PME-Technologie. Die PME-Technologie (Paste-based Metal Extrusion) ist eine Methode im 3D-Druck, bei der metallhaltige Paste extrudiert wird, um Metallteile herzustellen. Der Gauss MT90 verarbeitet Materialien wie Aluminium, Kupfer und Titan, bietet einen Bauraum von 420 x 420 x 500 mm und integriert einen HEPA-Filter für sichere Nutzung in Büros. Dabei kontrollieren KI-Kameras die Extrusion. Das neue Gerät wurde auch auf möglichst geringen Energieverbrauch minimiert.
Im Vergleich zu konventionellen Metall-3D-Druckern wie laserbasierten Systemen reduziert der MT90 den Energieverbrauch und die CO2-Emissionen erheblich, was ihn für nachhaltige Produktion geeignet macht. Typischerweise verbrauchen PME-Drucker weniger als die Hälfte der Energie von laserbasierten Alternativen bei vergleichbarer Druckqualität. Das beeindruckte offenbar die Experten. Eine unabhängige Jury aus Branchenexperten – darunter Medienvertreter, Designer und Ingenieure – zeichnete den Gauss MT90 mit dem CES 2026 Robotics Honoree Award aus.
Sweet Robo präsentierte auf der CES den ChocoPrint [4], einen 3D-Drucker für Schokolade, der Schokoladenfiguren und essbare Logos und Formen auf Abruf herstellt. Das Gerät erweitert das bestehende Roboter-Vending-System von Sweet Robo. Ein Roboter-Vending-System ist ein automatisiertes Verkaufssystem, das Robotertechnologie integriert, um Produkte interaktiv herzustellen und auszugeben. Im Gegensatz zu herkömmlichen Automaten, die nur vorgefertigte Waren lagern, nutzen diese Systeme Roboterarme oder -mechanismen, um frische Produkte vor Ort zu erzeugen.
Im Vergleich zu herkömmlichen Schokoladenherstellungsmaschinen ist der ChocoPrint kompakt und für den Einsatz in Geschäften, auf Events oder auf Märkten konzipiert. Sweet Robo sieht darin eine Erweiterung ihres Portfolios, das bereits Popcorn-, Zuckerwatte- und andere Süßigkeiten-Automaten in über 20 Ländern umfasst. Das Unternehmen plant, das Modell bald kommerziell anzubieten.
URL dieses Artikels:
https://www.heise.de/-11138045
Links in diesem Artikel:
[1] https://www.creality.com/products/sparkx-i7
[2] https://www.heise.de/thema/3D_Drucker
[3] https://enmetalprintinginc.com/Technology
[4] https://sweetrobo.com/chocoprint-chocolate-vending-machine-page/
[5] https://www.heise.de/make
[6] mailto:usz@heise.de
Copyright © 2026 Heise Medien
3D-gedruckte Touch-ID-Hülle: Nach viel Arbeit funktioniert sie gut.
(Bild: @Calvin_5743 / Printables)
Wer ein mechanisches Keyboard nutzen möchte, muss auf Apples Touch ID am Mac verzichten. Doch der Sensor lässt sich auch entnehmen.
Apples hauseigene Tastaturen sind zwar beliebt, doch haben sie allerlei Einschränkungen bei Bauweise und Tastenhub. Das Problem: Wer weg möchte vom Magic Keyboard, um etwa künftig mechanisch zu tippen [1], verliert Zugriff auf ein zentrales Komfortelement: den Fingerabdrucksensor Touch ID. Diesen bietet Apple nämlich nur eingebaut in MacBook Pro und MacBook Air sowie eben in besagtem Magic Keyboard an. Einzeln lässt sich dieser nicht erwerben, und so müssen Tastaturwechsler künftig bei Anmeldung oder Freigabe bestimmter macOS-Aktionen wieder zur Eingabe des Passworts greifen. Doch es gibt eine Lösung für das Problem: Wer bereit ist, ein Magic Keyboard als Spendeeinheit auszuschlachten, kann den Touch-ID-Knopf per Hardware-Hack auch ausbauen und in ein Gehäuse packen. Das ist zwar technisch aufwendig, wurde aber zuletzt gleich von mehreren YouTubern durchexerziert.
So zeigte der bekannte Maker, NAS- und Raspberry-Pi-Bastler Jeff Geerling den Vorgang im Detail [2]. Klar wird dabei allerdings schnell: Für Einsteiger ist die Umsetzung eher nichts. Auch Grobmotoriker dürften schnell daran verzweifeln: Zunächst an der verklebten Unterseite des Magic Keyboard, dann an den zahllosen (unterschiedlichen) Schrauben und schließlich am Einbau in eines der mehreren 3D-gedruckten Touch-ID-Gehäusen, die etwa bei Printables [3] bereitstehen. Denn: Die Toleranzen sind sehr niedrig, zudem schlägt man sich mit empfindlichen Flachbandkabeln herum.
Wer sich den Aus- und Einbau zutraut (was die Entnahme der korrekten Platinenbestandteile involviert), kann sich danach aber durchaus freuen: Der mit Lightning-nach-USB-C angeschlossene Button (alternativ: USB-C nach USB-C mit neueren Tastaturen) funktioniert wie gewohnt. Doch weder finanziell noch vom Arbeitsaufwand her lohnt sich die Aktion: „Warum stellt Apple also keine kleine Touch-ID-Box her? Sie könnten 50-US-Dollar dafür verlangen, und ich würde es bezahlen, wenn auch widerwillig“, sagt Geerling. So habe er eine 150-Dollar-Tastatur und ein paar Stunden Zeit geopfert, um eine „intelligente“ Taste zu erhalten.
Immerhin offeriert Apple selbst eine Alternative zu der Touch-ID-Problematik: Es ist seit einigen Jahren auch möglich, den Mac mittels Apple Watch zu entsperren [4]. Dazu muss man die Computeruhr aber zuerst einmal besitzen.
Sie wird dann mit dem Mac gekoppelt und dient als Entsperrinstrument – auch für Passwortabfragen, für die sonst nur Touch ID verwendet werden kann. Die Uhr muss zuvor entsperrt werden, damit nur der Besitzer sie auch nutzen kann.
URL dieses Artikels:
https://www.heise.de/-11133551
Links in diesem Artikel:
[1] https://www.heise.de/tests/Tipp-Top-Tastaturen-17-Keyboards-fuer-den-Mac-im-Test-9989999.html
[2] https://www.youtube.com/watch?v=tzB6m2VTxAg
[3] https://www.printables.com/model/355924-clickable-touch-id-box-tkl-board-wired#instructions
[4] https://support.apple.com/de-de/102442
[5] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[6] https://www.heise.de/mac-and-i
[7] mailto:bsc@heise.de
Copyright © 2026 Heise Medien
(Bild: Martin Jansson)
Mit Know-how können Maker defekte Akkus wieder zum Leben erwecken. Übereifrige BMS setzen Software-Sperren und verwandeln Akkus zu Elektroschrott.
Moderne Akkuwerkzeug-Akkus enthalten ausgeklügelte Battery-Management-Systeme (BMS), die Zellspannung, Temperatur, Ladezustand und Überlast überwachen. Diese Schutzmechanismen sind grundsätzlich sinnvoll – sie verhindern Schäden an Geräten und Nutzern. Doch was passiert, wenn diese Systeme Fehlalarme auslösen oder temporäre Probleme als permanente Defekte interpretieren?
Die Realität zeigt: Viele Akkus werden durch Software-Lockouts unbrauchbar gemacht, obwohl die Zellen und die Hardware vollkommen intakt sind. Ein kurzzeitiger Spannungsabfall, ein leichtes Zellungleichgewicht nach längerer Lagerung oder ein Firmware-Bug – und der teure Akku wird zum Briefbeschwerer. Die Hersteller bieten meist keine Lösung außer dem Neukauf und selbst in der Garantiezeit kann der Akkutausch umständlich sein.
Zwei bemerkenswerte Open-Source-Projekte nehmen sich nun dieser Problematik an und geben Makern die Werkzeuge in an Hand, ihre Akkus selbst zu reparieren.
Der schwedische Entwickler Martin Jansson begann das Projekt [1] vor etwa drei Jahren, nachdem mehrere seiner Makita-Akkus ohne ersichtlichen Grund den Dienst verweigerten. Die klassischen Symptome: Der Akku lässt sich nicht mehr laden, das BMS meldet einen Fehler, aber die Zellen selbst sind in Ordnung.
Janssons ursprüngliche Reverse-Engineering-Versuche mit einem F0513-Mikrocontroller von NEC (Renesas) waren mühsam. Der Durchbruch kam, als er von einem User Romain kontaktiert wurde, der mehrere neuere BMS-Platinen spendete – darunter eine mit einem STM32-Mikrocontroller, bei dem der Read-Protection-Schutz nicht aktiviert war. Innerhalb von fünf Minuten nach Erhalt der Platine konnte Jansson mit Ghidra die Firmware rückentwickeln (Reverse Engineering).
Makita LXT-Akkus nutzen ein auf Maxims OneWire-Protokoll [3] basierendes Kommunikationssystem über den gelben Steckverbinder. Die Timing-Parameter weichen vom Standard ab – vermutlich eine bewusste Verschleierung. Das BMS unterstützt Standard-OneWire-Funktionen wie Reset, Skip-ROM und Read-ROM. Besonders interessant: Es gibt einen versteckten Backdoor-Befehl, der das Protokoll auf Single-Wire-UART umschaltet. Über diesen Zugang lässt sich die komplette Firmware auslesen und sogar der Speicher beschreiben.
Da das OneWire-Protokoll präzises Timing erfordert, funktionieren Standard-Programmer nicht zuverlässig. Jansson entwickelte deshalb den ArduinoOBI – einen Arduino-basierten Programmer, der die zeitkritische Kommunikation übernimmt. Die Hardware beschränkt sich auf einen Arduino mit USB, ein Adapterkabel und ein paar Widerstände.
Diagnostik:
Reparatur:
Die modulare Architektur von OBI ermöglicht es Entwicklern, Unterstützung für weitere Hersteller hinzuzufügen. Jedes Modul muss lediglich eine get_display_name()-Funktion und eine ModuleApplication-Klasse implementieren. Leider scheint es hier noch keine weiteren Module zu geben.
Für Anfänger: Die vorkompilierte Windows-EXE aus den GitHub-Releases herunterladen [4] – keine Python-Installation nötig. Allerdings ist das .zip von Chrome als potenziell gefährliche Software deklariert, auch Virustotal warnt. Also besser den Python-Code benutzen:
Die Maker-Community hat OBI begeistert aufgenommen. Ein deutscher Nutzer berichtete im Forum „Fingers elektrische Welt“ [5], dass er nach Kontakt mit dem Entwickler eine spezielle Firmware für ältere Akkus erhielt, die mit dem Python-Tool zunächst nicht funktionierten. Ein Konsolenprogramm auf dem Arduino Nano konnte den Akku dann erfolgreich zurücksetzen.
Das Projekt wird aktiv weiterentwickelt und die Dokumentation auf DeepWiki [6] bietet umfassende Einblicke in die Systemarchitektur.
Badar Kayani wurde zum Ryobi-Akku-Hacker, nachdem drei seiner neuen Akkus unerwartet ausgefallen waren. Seine Neugierde führte ihn tief in die Materie: Er kaufte Dutzende defekte Akkus auf eBay, rückentwickelte die Platine und dokumentierte akribisch alle Fehlermodi und Reparaturschritte.
Das Video ist nicht nur für Besitzer von Ryobi-Tools interessant, sondern insgesamt informativ, wie die Herangehensweise an Hardware-Hacking aussehen kann.
Kayani hat einen vollständigen Schaltplan des PBP005-Modells erstellt [8], der etwa zu 95 Prozent komplett ist. Die Architektur ist typisch für BMS-Schaltungen, mit einigen interessanten Details:
Zentrale Komponenten:
Debug-Schnittstelle: Das Board verfügt über einen SWD-Tag-Connect-Header, über den sich die Firmware auslesen und modifizieren lässt.
Kayani analysierte Dutzende defekte Akkus und katalogisierte folgende Fehlermodi mit ihrer Prävalenz:
Mit 65 Prozent Prävalenz ist der permanente Firmware-Lockout das häufigste Problem. Die Symptomatik: Beim ersten Drücken der Status-Taste blinkt eine LED, bei weiteren Klicks blinken vier LEDs. Der Akku lässt sich weder laden noch entladen.
Kayanis Theorie: Akkus, die längere Zeit gelagert werden, geraten in einen Software-Zustand, in dem das Digitalteil kontinuierlich Strom zieht. Bei einem bestimmten Spannungsniveau während der Entladung setzt die Firmware einen permanenten Lockout. Die meisten betroffenen Akkus waren relativ entladen. Ein weiterer Trigger: Wenn eine Zellbank etwa 0,15 Volt weniger als die anderen hat und die Gesamtspannung in einem bestimmten Bereich liegt, löst das Auflegen auf das Ladegerät einen Lockout aus.
Kayani entdeckte, dass ein einzelnes Byte an Speicheradresse 0x7E90 über den Lockout-Status entscheidet. Ist dieses Byte ungleich null, ist der Akku permanent gesperrt. Wird es auf null gesetzt, lässt sich der Akku wieder normal nutzen.
Benötigte Hardware:
Verkabelung: Kayani musste den Batterie-Adapter von Amazon öffnen und modifizieren, um die SWD-Pins zugänglich zu machen. Detaillierte Diagramme in seinem Artikel zeigen die korrekte Verbindung zwischen Tag-Connect-Kabel und J-Link.
Software-Workflow:
Erfolgsrate: Kayani konnte fünf fast neue Akkus (alle um 3 V/Zelle) allein durch das Löschen des Lockout-Bits wiederbeleben. Nach dem Flashen ließen sie sich direkt auf einem Standard-Ryobi-Ladegerät laden, ohne weitere Eingriffe.
Für weniger schwerwiegende Lockouts gibt es einen einfacheren Weg ohne weitere Hardware, nur der Akku muss geöffnet werden, einen Versuch ist es wert!
J1-Reset-Prozedur:
Dieser Reset funktioniert bei Soft-Lockouts und manchen Zellimbalanzen. Kayani betont, dass viele Reddit-Threads über diesen Trick berichten, aber oft nicht zwischen verschiedenen Lockout-Typen unterscheiden.
Einige Batterien zeigten Ladefehler, bei denen das Ladegerät sie nicht erkannte. Kayani identifizierte die T1-Schaltung als Problemquelle, konnte aber trotz Kurzschluss-Tests zur Fehlereingrenzung keine dauerhafte Lösung finden. Das Fehlen von Teilenummern für einige Transistoren und die Gefahr, V_BATT an falsche Stellen zu leiten, erschwerten die Reparatur.
Kayani wirft eine wichtige Frage auf: Ist dieser Ansatz mit übermäßigen Firmware-Checks und -Lockouts wirklich besser für Sicherheit und Langlebigkeit? Einerseits will man Katastrophen vermeiden, andererseits haben diese Systeme eine hohe Fehlalarm-Rate, die funktionierende Akkus zu Elektroschrott macht.
Der Zyniker würde vermuten, dass Ryobi bewusst Obsoleszenz einbaut. Kayani glaubt das nicht – Ryobi gewährt drei Jahre Garantie, und seine eigenen Akkus waren jünger als ein Jahr, als sie ausfielen. Sie wurden problemlos ersetzt (wobei ein Ersatz-Akku ebenfalls bald darauf ausfiel).
Seine These: Ryobi hatte gute Absichten beim Design der Sicherheitssysteme, testete aber nicht gründlich genug, um Fehlalarme zu verhindern. Ein permanenter Lockout ohne Self-Reset-Option war möglicherweise ein Designfehler, kein Feature.
Disclaimer: Beide Projekte betonen, dass Arbeiten mit Lithium-Akkus gefährlich sein können. Nutzer sind für ihre eigene Sicherheit verantwortlich und sollten Best Practices befolgen.
Garantie: Öffnen und Modifizieren von Akkus erlischt in der Regel die Garantie. Bei Akkus, die noch in der Garantiezeit sind, sollte man zunächst den Hersteller-Service kontaktieren.
Gewährleistung: Die Entwickler übernehmen keine Haftung für Schäden, die durch die Nutzung ihrer Tools entstehen. Beide Projekte sind rein zu Bildungs- und Reparaturzwecken gedacht.
Right to Repair: Diese Projekte sind Paradebeispiele für die Right-to-Repair-Bewegung. Sie ermöglichen Nutzern, teure Hardware zu reparieren, statt sie zu entsorgen – ein wichtiger Beitrag zur Nachhaltigkeit.
Die Projekte von Martin Jansson und Badar Kayani zeigen eindrucksvoll, was mit Reverse-Engineering, Durchhaltevermögen und Open-Source-Philosophie möglich ist. Sie verwandeln Elektroschrott in funktionierende Werkzeuge und geben Makern die Kontrolle über ihre Hardware zurück.
Für wen sind diese Projekte geeignet?
Beide Projekte sind aktiv und offen für Beiträge. Für Leser etwa mit einem defekten Akkuschrauber-Akku könnte es sich lohnen, diese Projekte auszuprobieren – und vielleicht tragen Leser mit ihren Erkenntnissen zur weiteren Entwicklung bei.
Die Botschaft ist klar: Nur weil ein Hersteller sagt „nicht reparierbar", heißt das nicht, dass es stimmt. Mit den richtigen Tools und Community-Wissen können Maker ihre Geräte länger nutzen und gleichzeitig Elektroschrott reduzieren
Siehe auch:
URL dieses Artikels:
https://www.heise.de/-11133115
Links in diesem Artikel:
[1] https://github.com/mnh-jansson/open-battery-information
[2] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[3] https://github.com/rosvall/makita-lxt-protocol
[4] https://github.com/mnh-jansson/open-battery-information
[5] https://www.fingers-welt.de/phpBB/viewtopic.php?t=24670
[6] https://deepwiki.com/mnh-jansson/open-battery-information/1-overview
[7] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[8] https://badar.tech/2025/08/24/ryobi-battery-repair-guide/
[9] https://www.tag-connect.com/
[10] https://github.com/bjkayani/ryobi-battery-repair
[11] https://www.heise.de/download/product/open-battery-information?wt_mc=intern.red.download.tickermeldung.ho.link.link
[12] https://www.heise.de/make
[13] mailto:caw@make-magazin.de
Copyright © 2026 Heise Medien
This is a major release, just in time for the holidays 🎄
Selected new features ✨:
FreshRSS userdate:PT1H for the past hourImproved performance 🏎️:
Selected bug fixes 🐛:
Breaking changes 💥:
This release has been made by @Alkarex, @Frenzie, @Inverle, @aledeg, @andris155, @horvi28, @math-GH, @minna-xD and newcomers @Darkentia, @FollowTheWizard, @GreyChame1eon, @McFev, @jocmp, @larsks, @martinhartmann, @matthew-neavling, @pudymody, @raspo, @scharmach, @scollovati, @stag-enterprises, @vandys, @xtmd, @yzx9.
Full changelog:
userdate:PT1H for the past hour #8093\b and \B for regex search using PostgreSQL #8141~ subsequent-sibling #8154
Retry-After rules for proxies #8029, #8218data: to CSP in subscription controller #8253Retry-After #8195f.kind to ease migrations from FreshRSS versions older than 1.20.0 #8148config.custom.php during install #8033window.bcrypt object #8166chart.js v4 update #8298WordPress.com HTTP duplicates with WebSub Automattic/pushpress#16cli/health.php compatibility with OpenID Connect #8040cli/access-permissions.sh to detect the correct permission Web group such as www-data, apache, or httpexec() function for git update #8228DOMDocument::saveHTML() scrambling charset encoding in some versions of libxml2 #8296php-intl #8334<select> #8190Promise to async/await: #8182move #8214lib_rss.php with potential breaking changes for some extensions #8193,#[Deprecated] #8325--no-progress #8315This is a security-fix and bug-fix release for FreshRSS 1.27.x.
A few highlights ✨:
healthcheckframe-ancestorsThis release has been made by @Alkarex, @Frenzie, @Inverle, @aledeg, @math-GH and newcomers @beerisgood, @nykula, @horvi28, @nhirokinet, @rnkln, @scmaybee.
Full changelog:
Retry-After #7875no-cache.txt #7907.yml and SERVER_DNS example #7858overflow-wrap instead of word-wrap #7898make target to generate the translation progress #7905entry_before_update and entry_before_add hooks for extensions #7977A few highlights ✨:
429 Too Many Requests and 503 Service Unavailable, obey Retry-Afterc: for categories like c:23,34 or !c:45,56Content-Security-Policy: frame-ancestorsThis release has been made by @Alkarex, @Inverle, @the7thNightmare and newcomers @Deioces120, @Fraetor, @Tarow, @dotsam, @hilariousperson, @pR0Ps, @triatic, @tryallthethings
Full changelog:
429 Too Many Requests and 503 Service Unavailable, obey Retry-After #7760c: for categories like c:23,34 or !c:45,56 #7696s parameter of streamId #7695Content-Security-Policy: frame-ancestors #7677referrerpolicy, ping #7770clean_hash() #7813, FreshRSS/simplepie#48:newest updated to PHP 8.5-alpha and Apache 2.4.65 #7773FRESHRSS_INSTALL and FRESHRSS_USER variables #7725onbeforeunload #7554<video poster="..."> and <image> #7636<code> inside of <pre> #7797data-auto-leave-validation #7785chart.js to 4.5.0 #7752, #7816This is a bug-fix release for FreshRSS 1.26.x
A few highlights ✨:
This release has been made by @Alkarex, @Inverle and newcomers @CarelessCaution, @the7thNightmare
Full changelog:
bgcolor, text, background, link, alink, vlink #7606This is a security-focussed release for FreshRSS 1.26.x, addressing several CVEs (thanks @Inverle) 🛡
A few highlights ✨:
Notes ℹ:
This release has been made by @Alkarex, @Frenzie, @hkcomori, @loviuz, @math-GH
and newcomers @dezponia, @glyn, @Inverle, @Machou, @mikropsoft
Full changelog:
<iframe srcdoc=""> #7494, CVE-2025-32015<button formaction=""> #7506Content-Security-Policy HTTP headers to favicons #7471, CVE-2025-31136Referrer-Policy: same-origin #6303, #7478ext.php #7479, CVE-2025-31134mod_filter to ensure that AddOutputFilterByType works #7419
(Bild: Pincasso/Shutterstock.com)
Eine neue Methode erlaubt die Multiplikation großer Zahlen.
Die Klassen für Ganzzahltypen Int32, UInt32, Int64 und UInt64 bieten jeweils eine neue Methode BigMul() für die Multiplikation, die die Ergebnisse als Int64 und UInt64 bzw. Int128 und UInt128 zurückliefert (ohne Überlauf).
public void BigMul()
{
CUI.Demo();
long Value1 = long.MaxValue;
ulong Value2 = ulong.MaxValue;
Console.WriteLine("Value1: " + Value1.ToString("#,0"));
Console.WriteLine("Value2: " + Value2.ToString("#,0"));
CUI.H1("Normale Multiplikation");
Int128 e1 = Value1 * 2; // Überlauf! -2
UInt128 e2 = Value2 * 2; // Überlauf! 18446744073709551614
Console.WriteLine(e1.ToString("#,0")); // Überlauf! -2
Console.WriteLine(e2.ToString("#,0")); // Überlauf! 18446744073709551614
CUI.H1("Multiplikation mit BigMul()");
Int128 e3 = Int64.BigMul(Value1, 2); // 18.446.744.073.709.551.614
UInt128 e4 = UInt64.BigMul(Value2, 2); // 36.893.488.147.419.103.230
Console.WriteLine(e3.ToString("#,0")); // 18.446.744.073.709.551.614
Console.WriteLine(e4.ToString("#,0")); // 36.893.488.147.419.103.230
}
URL dieses Artikels:
https://www.heise.de/-10331981
Links in diesem Artikel:
[1] mailto:rme@ix.de
Copyright © 2025 Heise Medien
(Bild: Pincasso/Shutterstock.com)
In .NET 9.0 kann man neuerdings einen Globally Unique Identifier in der Version 7 mit Zeitstempel erzeugen.
Die .NET-Klasse System.Guid bietet seit .NET 9.0 neben der statischen Methode NewGuid(), die einen Globally Unique Identifier (GUID), alias UUID (Universally Unique Identifier), gemäß RFC 9562 [1] mit reinen Zufallszahlen (Version 4) erzeugt, nun auch eine weitere statische Methode CreateVersion7() mit einem Timestamp und einer Zufallszahl.
Folgender Code zeigt sowohl den Einsatz von NewGuid() als auch den von CreateVersion7():
public void Run()
{
CUI.Demo(nameof(FCL9_Guid));
for (int i = 0; i < 10; i++)
{
Guid guid = Guid.NewGuid();
Console.WriteLine($"Guid v4:\t{guid}");
}
for (int i = 0; i < 10; i++)
{
Guid guid7 = Guid.CreateVersion7();
Console.WriteLine($"Guid v7:\t{guid7}");
}
CUI.Yellow("Warte 1 Sekunde...");
Thread.Sleep(1000);
for (int i = 0; i < 10; i++)
{
Guid guid7 = Guid.CreateVersion7();
Console.WriteLine($"Guid v7:\t{guid7}");
}
}
(Bild: Screenshot (Holger Schwichtenberg))
Der Timestamp ist in UTC-Zeit in den ersten 64 Bits der GUID enthalten.
Zum Extrahieren des Zeitpunkts gibt es keine eingebaute Methode, man kann ihn aber folgendermaßen extrahieren:
public DateTimeOffset GetDateTimeOffset(Guid guid)
{
byte[] bytes = new byte[8];
guid.ToByteArray(true)[0..6].CopyTo(bytes, 2);
if (BitConverter.IsLittleEndian)
{
Array.Reverse(bytes);
}
long ms = BitConverter.ToInt64(bytes);
return DateTimeOffset.FromUnixTimeMilliseconds(ms);
}
URL dieses Artikels:
https://www.heise.de/-10316051
Links in diesem Artikel:
[1] https://www.rfc-editor.org/rfc/rfc9562.html
[2] mailto:rme@ix.de
Copyright © 2025 Heise Medien
(Bild: Pincasso/Shutterstock)
In C# 13.0 hat Microsoft den Einsatzbereich von ref struct unter anderem zum Implementieren von Schnittstellen erweitert.
Seit C# 7.2 gibt es Strukturen, die immer auf dem Stack leben und niemals auf den Heap wandern können: ref struct. In C# 13.0 hat Microsoft den Einsatz von ref struct erweitert.
Solche Typen können nun:
where T : allows ref struct verwenden.yield verwendet werden. Allerdings darf die Struktur nicht länger leben als der aktuelle Durchlauf des Iterator.Task oder Task<T> liefern, genutzt werden.Weiterhin gilt aber: Wenn man einen Typ als ref struct deklariert, ist ein Boxing nicht mehr möglich. Der Einsatz von ref struct ist daher begrenzt. So kann man beispielsweise kein Array und keine List<T> daraus erzeugen.
Folgender Code zeigt einen eigenen Typ mit ref struct, der eine Schnittstelle implementiert:
internal interface IPerson
{
int ID { get; set; }
int Name { get; set; }
}
// NEU seit C# 13.0: ref struct kann Schnittstelle implementieren
ref struct Person : IPerson
{
public int ID { get; set; }
public int Name { get; set; }
// ToString()
public override string ToString()
{
return "Person #" + ID + " " + Name;
}
}
}
class Client
{
public void Run()
{
Person p = new Person();
p.ID = 1;
p.Name = 2;
Console.WriteLine(p.ID);
Console.WriteLine(p.Name);
// Das ist alles nicht erlaubt!
// IPerson i = p; // Casting auf Schnittstelle
// List<Person> PersonList = new(); // List<T>
// PersonList[] PersonArray = new Person[10]; // Array
}
}
URL dieses Artikels:
https://www.heise.de/-10307583
Links in diesem Artikel:
[1] mailto:rme@ix.de
Copyright © 2025 Heise Medien
(Bild: Vova Shevchuk / Shutterstock.com)
Psychologische Tricks werden scheinbar erfolgreich gegen ein LLM eingesetzt – aber ist das wirklich relevant?
Einem Psychologen ist es gelungen, Sicherheitsrichtlinien diverser Large Language Models (LLMs) mit Tricks auszuhebeln, die eigentlich zur Manipulation von Menschen dienen. Mit Gaslighting hat Luke Bölling LLMs [1] dazu gebracht, einen Text zu erzeugen, der scheinbar erklärt, wie man einen Molotowcocktail [2]herstellt (Siehe dazu auch der heise-Artikel [3] von Niklas Jan Engelking).
Gaslighting [4] ist ein psychologisches Konzept: Es ist "eine Form von psychischer Manipulation …, mit der Opfer gezielt desorientiert, verunsichert und in ihrem Realitäts- und Selbstbewusstsein allmählich beeinträchtigt werden". LLMs generieren jedoch lediglich Texte. Sie nehmen keine Realität wahr und haben kein Selbstbewusstsein. Der Artikel argumentiert, dass dieser Angriff trotzdem funktioniert, weil das Trainingsmaterial von Menschen geschrieben wurde und daher auch Konzepte wie Gaslighting darin vorkommen. Dennoch dürfen wir nie vergessen, dass LLMs nichts weiter als Textgeneratoren sind. Sie haben keine Emotionen, wie die zitierte Arbeit auch feststellt. Daher werde ich im weiteren Text den Begriff "Textgenerator" verwenden, da er besser beschreibt, was LLMs tatsächlich tun.
Textgeneratoren können offensichtlich einen Text erzeugen, der wie eine plausible Anleitung zur Herstellung eines Molotowcocktails erscheint – genau, wie sie scheinbar plausible Verweise auf Gerichtsentscheidungen [5] für einen Anwalt generieren können. Und obwohl diese Verweise für den Anwalt überzeugend klingen, sind sie in Wirklichkeit erfunden. Das ist eines der Probleme mit Textgeneratoren: Sie sind darauf optimiert, überzeugend zu klingen, und versuchen so, das kritische Hinterfragen ihrer Ergebnisse zu vermeiden.
Die eigentliche Frage lautet also: Würde die angebliche Anleitung zur Herstellung eines Molotowcocktails tatsächlich funktionieren? Ich habe mit Lucas Dohmen einen Stream über Textgeneratoren [6] gemacht, und eine der zentralen Erkenntnisse war: Man muss die Ergebnisse von Textgeneratoren überprüfen, um sicherzustellen, dass sie korrekt und nicht erfunden sind. Der zitierte Artikel scheint dies nicht zu tun – das heißt, die gesamte Information über Molotowcocktails könnte schlicht "halluziniert" sein. Das Problem der Generierung von Fake-Informationen durch Textgeneratoren ist nämlich so bekannt, dass es einen eigenen Begriff (Halluzination) gibt. Tatsächlich ist "halluziniert" der falsche Begriff, denn "unter Halluzination [7]versteht man eine Wahrnehmung, für die keine nachweisbare externe Reizgrundlage vorliegt". Textgeneratoren haben jedoch keine Wahrnehmungen. Daher sollten wir dieses Phänomen korrekt als "Generierung von Fake-Informationen" benennen.
Wir können die Information über den Molotowcocktail nicht überprüfen, da sie im Originalartikel unkenntlich gemacht wurde – was natürlich absolut sinnvoll ist. Ich würde mich aber nicht auf diese Informationen verlassen, um tatsächlich einen improvisierten Brandsatz zu bauen.
Der Artikel behauptet, dieses Problem sei ein Sicherheitsrisiko bei Textgeneratoren. Falls das wirklich der Fall wäre, bestünde die Lösung darin, sensible Informationen aus dem Trainingsmaterial auszuschließen. Das Anpassen der Trainingsdaten wäre ohnehin sinnvoll, beispielsweise aufgrund von Urheberrechtsproblemen. Aus irgendeinem Grund scheint Urheberrecht für Textgeneratoren nicht zu gelten, während es für Menschen schwere Folgen [8]haben kann. Warum sollte es nicht möglich sein, Anleitungen zur Herstellung von improvisierten Brand- oder Sprengsätzen aus dem Trainingsmaterial zu entfernen? Wenn das zu viel Aufwand ist, dann ist das Problem vielleicht gar nicht so groß.
Dieses "Sicherheitsproblem" wäre auch nur dann ein echtes Problem, wenn der Textgenerator keine Fake-Informationen generiert hätte – dazu sagt der Artikel jedoch nichts. Falls es Fake-Informationen sind, könnte man es vielleicht als eine Art Honeypot [9] betrachten, um Menschen von echten Informationen fernzuhalten?
Doch die eigentliche Frage ist: Wäre dies wirklich der einfachste Weg, um an solche Informationen zu gelangen? Angenommen, ich plane, einen Molotowcocktail zu bauen – würde ich komplizierte "psychologische Angriffe" auf einen Textgenerator durchführen, um eine möglicherweise falsche Antwort zu erhalten? Gibt es einfachere und präzisere Möglichkeiten? Also habe ich den naheliegenden Weg ausprobiert: eine Suche mit einer Suchmaschine. Zwei Klicks später fand ich ein Dokument, das detailliert erklärt, wie man anspruchsvolle improvisierte Sprengsätze herstellt – und ich habe guten Grund zu glauben, dass diese Anleitungen tatsächlich funktionieren. Zugegeben, dieses spezielle Dokument beschreibt nicht, wie man einen Molotowcocktail baut, aber es erklärt eine Vielzahl anderer Vorrichtungen. Diese Recherche selbst nachzuvollziehen, ist sicher spannend.
LLMs sind Textgeneratoren, die potenziell erfundene Informationen produzieren – das ist bekannt. Es mag ausgeklügelte Methoden geben, um sie dazu zu bringen, Texte zu generieren, die sensible Informationen zu enthalten scheinen – doch diese könnten schlicht Falschinformationen sein. Häufig gibt es einfachere Wege, um an sensible Informationen zu gelangen, insbesondere wenn es um improvisierte Brand- oder Sprengsätze geht. Daher sehe ich keinen Grund, "psychologische" Tricks auf Textgeneratoren anzuwenden – denn genau das sind LLMs letztlich.
URL dieses Artikels:
https://www.heise.de/-10334947
Links in diesem Artikel:
[1] https://humandataexperience.substack.com/p/librarian-bully-attack-gaslighting
[2] https://de.wikipedia.org/wiki/Molotowcocktail
[3] https://www.heise.de/news/Neuer-LLM-Jailbreak-Psychologe-nutzt-Gaslighting-gegen-KI-Filter-10332571.html
[4] https://de.wikipedia.org/wiki/Gaslighting
[5] https://news.bloomberglaw.com/litigation/lawyer-sanctioned-over-ai-hallucinated-case-cites-quotations
[6] https://www.heise.de/news/software-architektur-tv-KI-und-LLMs-kritisch-betrachtet-10287426.html
[7] https://de.wikipedia.org/wiki/Halluzination
[8] https://en.wikipedia.org/wiki/Aaron_Swartz#United_States_v._Aaron_Swartz
[9] https://de.wikipedia.org/wiki/Honeypot
[10] mailto:map@ix.de
Copyright © 2025 Heise Medien
(Bild: erzeugt mit KI durch iX)
Automatisiertes Refactoring klingt verlockend – doch lässt sich Codequalität wirklich auf Knopfdruck verbessern, oder braucht es am Ende doch den Menschen?
Heute habe ich eine große Ankündigung für Sie – eine, die für viele Entwicklerinnen und Entwickler wohl einem echten Traumszenario gleichkommt. Ein Gedanke, der so bestechend einfach klingt, dass man sich fragen könnte, warum es so etwas nicht schon längst gibt. Sicher kennen auch Sie Gespräche im Team, in denen dieser Wunsch immer wieder auftaucht – meist mit ironischem Unterton, aber manchmal durchaus mit einem Funken Hoffnung.
Stellen Sie sich vor, Sie könnten Ihren kompletten Codestand einfach in eine ZIP-Datei packen, per HTTP an einen Service hochladen – und wenige Minuten später erhalten Sie ihn vollständig refactored zurück: besser strukturiert, mit klaren Abhängigkeiten, sinnvoll modularisiert, mit sprechenden Namen, nachvollziehbarer Architektur und aussagekräftigen Tests. Inklusive aktualisierter Dokumentation, vollständig durchgelintet und formatiert. Einmal hochladen, und der Code sieht anschließend aus, als hätte ein erfahrenes Senior-Architekturteam drei Wochen intensiv daran gearbeitet. Genau das haben wir jetzt Realität werden lassen und nennen es: "Refactoring as a Service".
Die Idee ist so einfach wie genial: Haben Sie ein Repository, dessen Zustand nicht mehr ganz optimal ist? Kein Problem: Sie laden den Code einfach über unsere API hoch oder verweisen auf ein Git-Repository mit einem gültigen Token – der Rest passiert automatisch im Hintergrund. Unser Service analysiert den Code mit statischen und dynamischen Verfahren, führt eine kombinierte AST- und Graphanalyse durch, identifiziert strukturelle Schwächen, erkennt Anti-Patterns, bewertet essenzielle Metriken wie zyklomatische Komplexität, Kohäsion, Kopplung, Testabdeckung und Architekturkonformität – und erstellt daraus ein kontextsensitives, semantisch fundiertes Refactoring-Konzept, das automatisiert umgesetzt wird. Die resultierende Codebasis ist nicht nur schöner und verständlicher, sondern auch modularer, wartbarer und besser getestet. Selbstverständlich integriert sich das Ganze nahtlos in CI/CD-Prozesse und ist über eine OpenAPI-Schnittstelle vollständig automatisierbar.
Weil uns das noch nicht genug war, wird zusätzlich eine KI-gestützte Kommentierung vorgenommen, die basierend auf Codeverständnis sowie Projektkontext passgenaue Kommentare und Erläuterungen hinzufügt – sowohl auf Code- als auch auf Modul- und Architekturebene. Die Testabdeckung wird nicht nur erhöht, sondern zielgerichtet erweitert, mit besonderem Augenmerk auf Pfadabdeckung, Grenzfälle, Randbedingungen und semantisch relevante Kombinationen. All dies orchestriert ein auf Kubernetes skalierendes Service-Backend, das selbst größere Projekte in kurzer Zeit bewältigt. Für besonders kritische Projekte bieten wir zudem eine Audit-Funktion: Jede Änderung bleibt einzeln nachvollziehbar, jeder Commit wird semantisch kommentiert, jeder Refactoring-Schritt dokumentiert. Kurz gesagt: Der perfekte Begleiter für Softwareteams, die Qualität ernst nehmen, dabei aber ihren Fokus auf die eigentliche Entwicklung legen wollen.
Die eigentliche Magie entsteht durch die Kombination verschiedener Technologien und Ansätze: Statische Analyse alleine hilft wenig, wenn sie den fachlichen Kontext nicht berücksichtigt. LLMs alleine schreiben zwar Code, wissen aber nicht, ob dieser wirklich zu Ihrem Projekt passt. Clean-Code-Prinzipien sind essenziell, lösen aber nicht das grundlegende Problem der strukturellen Überarbeitung. Erst die systematische Verbindung dieser Ansätze schafft etwas, das sich wirklich als Refactoring im engeren Sinne bezeichnen lässt. Genau das macht "Refactoring as a Service" nicht nur zu einem interessanten Tool, sondern zu einem echten Gamechanger.
Natürlich – und das war uns von Anfang an bewusst – ersetzt "Refactoring as a Service" nicht den Menschen. Unser Ziel war es nie, die Expertise erfahrener Entwicklerinnen und Entwickler überflüssig zu machen. Ganz im Gegenteil: Wir wollten diese Expertise entkoppeln, also ermöglichen, dass sie unabhängig von individueller Verfügbarkeit, Projektkontext oder Zeitdruck eingesetzt werden kann. Deshalb haben wir all unser Wissen, unsere Erfahrungen und Prinzipien in diesen Service einfließen lassen – damit andere Teams davon profitieren können, ohne dass wir immer persönlich involviert sein müssen.
Das ist nicht nur für Entwicklerinnen und Entwickler spannend, sondern gleichermaßen interessant für Softwarearchitektinnen und -architekten, Teamleads und CTOs sowie alle, die sich intensiv mit Softwarequalität und Wartbarkeit auseinandersetzen. Denn Refactoring ist nicht nur ein technisches Hilfsmittel, sondern ein strategisches Instrument. Es entscheidet maßgeblich über Lebensdauer, Änderbarkeit und Erweiterbarkeit – und damit letztlich über den wirtschaftlichen Erfolg eines Projekts. Genau deshalb möchten wir mit "Refactoring as a Service" dazu beitragen, dass mehr Teams die Möglichkeit erhalten, ihre Codebasis auf ein solides und wartbares Fundament zu stellen.
An dieser Stelle fragen Sie sich vermutlich bereits: Klingt vielversprechend – doch wie viel kostet das Ganze? Wann und wie kann ich es ausprobieren? Die Antwort auf diese Fragen lautet leider: gar nicht. Denn heute ist der 1. April, und "Refactoring as a Service" existiert nicht.
Doch bevor Sie enttäuscht sind: Die Idee hinter "Refactoring as a Service" – also der Wunsch nach automatisiertem, reproduzierbarem und skalierbarem Refactoring – ist real und absolut verständlich. Wer von uns kennt nicht den Frust, sich durch Altlasten zu kämpfen, zu fragen, was sich jemand bei einem Stück Code gedacht haben könnte, und den Wunsch, einfach einen Knopf drücken zu können: "Jetzt Refactor" – klick, fertig. Leider ist es nicht ganz so einfach, und dafür gibt es gute Gründe.
Refactoring ist eben nicht nur eine technische Tätigkeit, sondern eine bewusste Entscheidung: eine Entscheidung darüber, wie Code strukturiert werden soll. Welche Konzepte getrennt, welche zusammengeführt werden müssen. Welche Benennungen welche Bedeutung tragen. Welche Architekturprinzipien zum Einsatz kommen, wann bestimmte Patterns sinnvoll sind und wann man bewusst darauf verzichten sollte. All das hängt unmittelbar mit einem fundierten fachlichen Verständnis zusammen: Sie können keine gute Struktur aufbauen, wenn Sie nicht wissen, was diese Struktur abbilden soll. Sie können keine Struktur sinnvoll bewerten, wenn Sie nicht verstehen, welche Anforderungen diese erfüllen muss. Genau deshalb ist Refactoring auch nichts, was sich rein nach Schema F automatisieren ließe. Es handelt sich eben nicht um einen rein technischen Akt, sondern um einen analytischen und diskursiven Prozess.
Natürlich gibt es Tools, Plug-ins und LLMs. Doch keines dieser Hilfsmittel kann Ihnen beantworten, ob eine Methode in einen Service oder in einen Controller gehört. Keines erkennt zuverlässig, ob eine bestimmte Implementierung noch zur aktuellen Realität passt oder lediglich ein Relikt früherer Feature-Iterationen darstellt. Keines entscheidet für Sie, ob ein Name tatsächlich treffend oder nur historisch gewachsen ist. Kein Tool abstrahiert Fachlichkeit umfassend, ersetzt Kommunikation oder übernimmt Verantwortung. All diese Dinge erfordern Erfahrung, Kontextverständnis, Empathie – also letztlich Menschen.
Deshalb ist gutes Refactoring stets gute Teamarbeit. Es bedeutet, innezuhalten, Code bewusst erneut zu lesen, zu verstehen, was er ausdrücken möchte, und anschließend in kleinen, wohlüberlegten Schritten etwas Besseres daraus zu machen. Etwas Klareres und Stabileres, das den Alltag erleichtert und nicht erschwert. Genau darin liegt auch die Verantwortung beim Refactoring. Wer refactored, entscheidet sich für langfristige Qualität – und gegen kurzfristige Bequemlichkeit. Das ist nicht immer einfach.
In vielen Teams fehlt dafür oft Zeit, Mut oder Rückendeckung. Features werden entwickelt, Stories geliefert und der Durchsatz optimiert – doch der Boden, auf dem alles steht, wird selten stabilisiert. Je länger das andauert, desto brüchiger wird das Fundament. Irgendwann wächst Refactoring dann zu einem Mammutprojekt heran, das niemand mehr anfassen möchte – obwohl anfangs nur wenige kleine Schritte nötig gewesen wären. Genau das darf nicht passieren.
Was also ist der bessere Weg? Sehen Sie Refactoring nicht als einmalige, große Aufgabe, sondern als kontinuierlichen Prozess. Machen Sie Refactoring zum festen Bestandteil Ihres Alltags, jeder Story, jedes Features, jedes Sprints. Refactoring ist nicht etwas, das man macht, wenn gerade Zeit übrig bleibt – sondern etwas, das man stets tun sollte, um sich die Zukunft deutlich einfacher zu gestalten. Das bedeutet konkret: kleine Schritte, regelmäßige Reviews, klare Verantwortlichkeiten, Mut zur Veränderung und ein gemeinsames Verständnis im Team, dass gute Software niemals Zufall ist, sondern das Ergebnis von Haltung, Prinzipien und kontinuierlicher Pflege.
URL dieses Artikels:
https://www.heise.de/-10333543
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] mailto:mai@heise.de
Copyright © 2025 Heise Medien
