Anmelden
Pride-Wallpaper für das Jahr 2026 von Apple.
(Bild: Apple)
Apple hat seine diesjährige LGBTQ+-Sammlung vorgestellt. Wer auf ein Solo-Loop-Armband gehofft hatte, wird leider enttäuscht.
Jedes Jahr feiert Apple verschiedene soziale Bewegungen mit passendem Zubehör: Neben der Black-Unity-Kollektion [1], die zum Gedenkmonat Black History Month in den USA erscheint, ist dies regelmäßig auch eine neue Pride-Kollektion für die LGBTQ+-Gemeinschaft. Die Angebote sind dabei jeweils limitiert und nur solange erhältlich, bis die nächste Sammlung verfügbar ist oder sie ausverkauft wurde. Nun steht zum Pride-Month auch eine neue Apple-Pride-Collection bereit. Sie setzt sich aus drei Teilen zusammen, wobei nur eine davon echte „Hardware“ ist.
In diesem Jahr hat Apple ein neues Sportarmband gestaltet. Es handelt sich dabei um ein sogenanntes Sport Loop [2] aus einem Kunststofffasermaterial, das man dank Klettverschluss frei verstellen kann. Fans der Sonderedition hatten, wie schon beim Black-Unity-Armband [3], das im Januar verfügbar gemacht wurde, eigentlich auf ein sogenanntes Solo-Loop-Band gehofft, in das man nur hineinschlüpfen muss. Dieses hat allerdings den Nachteil, dass man vorab die richtige Größe zu ermitteln hat und es auf Dauer auch ausleiern kann.
Das Pride-Edition-Sportarmband für 2026 hat als Grundfarbe Weiß mit bunten, an die LGBTQ+-Flagge erinnernden Regenbogenfarben, die ebenfalls recht hell ausfallen. Es wird in den Größen 40, 42 und 46 mm angeboten, eignet sich also auch für die Apple Watch Ultra. Verbaut wird laut Apple 80 Prozent recyceltes Nylon (also 20 Prozent Neumaterial) plus 100 Prozent recyceltes Polyester und 100 Prozent recyceltes Elastan. Der Preis liegt stets bei 49 Euro, egal welche Größe erworben wird. Apple betonte, dass man Organisationen, die sich für LGBTQ+-Gemeinschaften einsetzen, finanziell unterstütze – es wurde aber keine Angabe dazu gemacht, ob ein direkter Beitrag des Armbandverkaufs an solche Gruppen geht.
Neben dem Armband gibt es auch kostenloses Pride-Merchandising: Mit iOS 26.5 [4], iPadOS 26.5 und watchOS 26.5, die in den kommenden Tagen erwartet werden, liefert Apple zum Look des Armbands passende Hintergrundbilder (Wallpaper) sowie auf der Watch auch ein eigenes Zifferblatt („Pride Luminance”) aus, ohne dass das etwas kosten würde.
Auch das hat schon jahrelange Tradition. „Mit der Kollektion können Nutzer:innen das Zifferblatt mit noch mehr Farboptionen individuell gestalten, um einen einzigartigen Ausdruck ihrer selbst und ihrer Communitys zu schaffen“, schreibt der Konzern.
URL dieses Artikels:
https://www.heise.de/-11281219
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Der neue chinesische Kampfpanzer ZTZ-100, ausgestattet mit fortschrittlicher Technologie, wurde nun offiziell in Dienst gestellt.
(Bild: Chinese MoD/Weibo)
Der unbemannte Turm und AR-Helme machen ihn zum modernsten Kampfpanzer Chinas – jetzt ist er offiziell im Einsatz.
Die chinesische Volksbefreiungsarmee hat kürzlich Trainingsaufnahmen ihres neuen Kampfpanzers vom Typ 100 veröffentlicht und damit bestätigt, dass er jetzt im Dienst ist, wie Army [1]Recognition [2] berichtet.
Erstmals hatte China den ZTZ-100 Anfang September 2025 [3] bei der Victory-Day-Parade zum 80. Jahrestag des Sieges über Japan in Peking der Öffentlichkeit präsentiert. Nur etwa acht Monate später rollen die ersten Exemplare in operativen Einheiten – wenn auch vorerst in einer Kleinserie von etwa vier Fahrzeugen.
Der vom 201. Forschungsinstitut entwickelte und im Panzerwerk Baotou gefertigte Panzer markiert einen konzeptionellen Bruch mit bisherigen chinesischen Kampfpanzern.
Wo der bisherige Standardpanzer Typ 99A noch auf einen bemannten Turm, reine Dieselmotorisierung und konventionelle Optik setzt, verlagert der ZTZ-100 die dreiköpfige Besatzung komplett in ein gepanzertes Abteil im vorderen Rumpf.
Der Turm arbeitet vollständig unbemannt und wird ferngesteuert – ein Konzept, das dem russischen T-14 Armata und dem US-amerikanischen AbramsX ähnelt.
China klassifiziert den ZTZ-100 als Kampfpanzer der vierten Generation, wobei diese Einstufung keiner internationalen Standardisierung folgt.
Das Antriebssystem stellt eine der auffälligsten Neuerungen dar. Ein hybrides Diesel-Elektro-System erzeugt rund 1500 PS und treibt den 35 bis 45 Tonnen schweren Panzer auf Straßengeschwindigkeiten von etwa 80 km/h. Im Gelände erreicht er noch 50 km/h.
Bei einem Leistungsgewicht von geschätzten 33 bis 40 PS pro Tonne ist der ZTZ-100 damit deutlich agiler als sein 52 Tonnen schwerer Vorgänger Typ 99A, der maximal 65 km/h schafft.
Die Besonderheit des Systems liegt im reinen Elektrobetrieb: In diesem Modus bewegt sich der Panzer geräuschlos und mit reduzierter Infrarot-Signatur, was Einsatzmodi wie „Silent Watch“ und „Silent Approach“ für Aufklärungs- oder Hinterhaltsszenarien ermöglicht.
Die Reichweite im Dieselbetrieb beträgt laut Interesting Engineering [4] bis zu 600 Kilometer, während der reine Elektromodus auf kürzere Strecken beschränkt bleibt.
Statt herkömmlicher Periskope und optischer Visiere nutzt die Besatzung Augmented-Reality-Helmsysteme.
Diese fusionieren Daten aus externen Kameras, vier Phased-Array-Radarpanels an den Turmecken sowie Infrarot- und UV-Sensoren zu einer zusammengesetzten 360-Grad-Sichtumgebung. Zielinformationen, Navigationsüberlagerungen und Fahrzeugstatus werden direkt ins Sichtfeld projiziert.
Eine Head-Tracking-Funktion richtet Turm oder Waffenstation an der Blickrichtung des Bedieners aus, was die Reaktionszeit laut chinesischen Angaben um 20 bis 40 Prozent gegenüber älteren optischen Systemen verkürzen soll.
Die vier Radarpanels arbeiten im Millimeterwellenbereich und liefern eine kontinuierliche Rundum-Erfassung einschließlich hochgelegener Bedrohungen.
Das System erkennt Panzerabwehrlenkflugkörper in mehreren Kilometern Entfernung und Drohnen in 1 bis 5 km Distanz – Fähigkeiten, die den Vorgängermodellen Typ 96 und Typ 99 fehlten.
Die Verteidigungsphilosophie des ZTZ-100 setzt weniger auf massive Panzerungsdicke als auf aktive Abwehr. Zwei GL-6-Schutzsysteme am Turm verfügen über jeweils vier Abschussrohre mit insgesamt acht einsatzbereiten Abfangraketen.
Diese sollen Panzerabwehrlenkflugkörper, Panzerfäuste, Top-Attack-Munition und Loitering-Munition in Entfernungen zwischen 10 und 30 Metern abfangen – automatisiert gesteuert durch die Millimeterwellen-Radare und Laserwarnempfänger.
Gerade die Abwehr von Drohnen-Munition und Top-Attack-Waffen berücksichtigt Lehren aus aktuellen Konflikten, in denen konventionelle Panzer durch kostengünstige Aufschlagmunition von oben verwundbar wurden.
Die modulare Verbundpanzerung ergänzt das aktive System als passive Schutzschicht.
Die Hauptbewaffnung besteht aus einer 105-mm-Glattrohrkanone mit automatischem Lader und einer Feuerrate von 8 bis 12 Schuss pro Minute. Das Kaliber liegt damit unter den 120 mm der NATO-Panzer und den 125 mm russischer Modelle.
China kompensiert dies nach eigenen Angaben durch panzerbrechende, flügelstabilisierte Sabotgeschosse (APFSDS) mit einer Mündungsgeschwindigkeit von 1706 m/s – ein Wert, der durch verbessertes Treibmittel eine vergleichbare Durchschlagsleistung erzielen soll.
Die Munitionsladung umfasst 30 bis 40 Schuss, die Direktfeuer-Reichweite liegt bei 2 bis 4 km, durch vernetzte Zielerfassung sollen Ziele jenseits von 5 km bekämpfbar sein.
Der ZTZ-100 ist als Knoten in einem vernetzten Gefechtsfeld-Ökosystem konzipiert. Datenlinks verbinden ihn mit Aufklärungsdrohnen, Artillerie, Mehrfachraketenwerfern und elektronischen Kampfsystemen.
Bei kombinierten Waffenübungen im vergangenen Jahr sollen Panzerkommandanten bereits Ziele außerhalb der direkten Sichtlinie bekämpft haben, indem sie externe Sensordaten nutzten.
Ergänzt wird der Kampfpanzer durch ein Feuerunterstützungsfahrzeug auf gleicher Plattform, das eine 30- bis 35-mm-Kanone, am Heck montierte Aufklärungsdrohnen und Platz für drei bis vier Infanteristen mitführt.
Die geschätzten Stückkosten von 4,5 bis 7,5 Millionen US-Dollar bei Kleinserienfertigung positionieren den ZTZ-100 zwischen dem russischen T-90M (3 bis 4,5 Millionen) und dem US-amerikanischen M1A2 SEPv3 (über 10 Millionen).
Bei höheren Produktionsraten könnten die Kosten auf 3,5 bis 6 Millionen US-Dollar sinken. Die geringe bisherige Stückzahl deutet allerdings darauf hin, dass China den ZTZ-100 vorerst in einer erweiterten Testphase betreibt, bevor eine Massenproduktion folgt .
Defence Blog [5] bestätigt anhand der Xinhua-Aufnahmen erste Feldübungen mit operativen Einheiten.
URL dieses Artikels:
https://www.heise.de/-11284587
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Pathanlassa)
KI braucht immer mehr Strom – ein Startup hat dafür eine Lösung gefunden, die so ungewöhnlich ist wie effektiv.
Der Energiehunger von KI-Rechenzentren treibt Investoren zu immer ungewöhnlicheren Lösungen. Das Startup Panthalassa aus Portland, Oregon, hat jetzt in einer Serie-B-Finanzierungsrunde 140 Millionen US-Dollar eingesammelt, um schwimmende Rechenknoten zu bauen, die ihren Strom aus Meereswellen gewinnen.
Wie Ars Technica berichtet [1], führt Palantir-Mitgründer Peter Thiel die Investorenrunde an. Insgesamt hat das Silicon Valley bereits 210 Millionen Dollar in die Vision gesteckt.
Zu den weiteren Geldgebern gehören unter anderem John Doerr, Marc Benioffs TIME Ventures, Max Levchins SciFi VC sowie der Server- und IT-Infrastrukturhersteller Super Micro Computer.
Wie aus der Pressemitteilung vom 4. Mai [2] hervorgeht, soll das Geld eine Pilotproduktionsanlage nahe Portland fertigstellen und den Einsatz der sogenannten Ocean-3-Knoten beschleunigen.
Die Besonderheit des Systems liegt in seiner Funktionsweise: Jeder Knoten besteht aus einer schwimmfähigen Stahlkugel mit rund 50 Metern Durchmesser, die über ein 60 bis 85 Meter langes vertikales Rohr mit einem Unterwasserrahmen verbunden ist.
Wenn Ozeanwellen den Knoten auf und ab bewegen, entsteht eine Relativbewegung zwischen der Struktur und der umgebenden Wassersäule. Diese treibt Meerwasser durch das Rohr nach oben in ein Druckreservoir innerhalb der Kugel, wo ein Hochdruckstrahl interne Turbinen antreibt.
Das Wasser fließt anschließend zurück ins Rohr – ein geschlossener Hydraulikkreislauf, der kontinuierlich Energie aus welleninduzierten Bewegungen gewinnt. Da der Ozean niemals stillsteht, erzeugt das System nach Unternehmensangaben rund um die Uhr Strom mit einem Kapazitätsfaktor von bis zu 90 Prozent.
Die KI-Chips an Bord werden direkt versorgt, Ergebnisse der Inferenz-Berechnungen per Satellitenverbindung an Kunden übertragen. Welche Chiparchitektur oder konkreten Rechenkapazitäten pro Knoten erreicht werden, hat Panthalassa bislang nicht veröffentlicht.
Ein weiterer Vorteil gegenüber landgestützten Rechenzentren: Das umgebende Meerwasser kühlt die Chips direkt.
"Rechenleistung auf dem Meer könnte einen enormen Kühlvorteil bieten, da die Umgebungstemperatur so niedrig ist", erklärte Benjamin Lee, Computerarchitekt an der University of Pennsylvania, gegenüber Ars Technica .
Landgestützte Rechenzentren verbrauchten dagegen viel Strom und Süßwasser für die Kühlung.
Lee beschrieb den Ansatz als Verwandlung eines Energieübertragungsproblems in ein Datenübertragungsproblem.
Allerdings bedeute die Satellitenanbindung auch erhebliche Einschränkungen: Hunderte Megabit pro Sekunde pro Terminal seien für Echtzeit-Antworten auf Nutzeranfragen machbar, doch die Koordination mehrerer Knoten und der Transfer größerer Datenmengen bleibe eine Herausforderung. Physischer Transport von Speichermedien per Schiff wäre wohl in regelmäßigen Abständen nötig.
Panthalassa hat bereits mehrere Vorgänger-Prototypen erprobt: den Ocean-1 im Jahr 2021 und den Ocean-2 in einem dreiwöchigen Seetest vor der Küste des US-Bundesstaats Washington im Februar 2024.
Konkrete Ausfallraten der Prototypen sind nicht bekannt. Als Referenz dient Microsofts Project Natick [3], das von 2015 bis 2020 versiegelte Unterwasser-Rechenzentren testete und dabei niedrigere Ausfallraten als an Land erzielte. Microsoft entschied sich dennoch gegen eine Kommerzialisierung.
Der Ocean-3-Prototyp erreicht eine Länge von etwa 85 Metern – vergleichbar mit dem Londoner Big Ben – und soll noch 2026 im nördlichen Pazifik getestet werden.
CEO und Mitgründer Garth Sheldon-Coulson erklärte gegenüber [4] CBS, er hoffe auf den Einsatz tausender solcher Knoten. Panthalassa will die Systeme für mehr als ein Jahrzehnt wartungsfrei unter härtesten Meeresbedingungen betreiben.
Der Hintergrund: US-Tech-Unternehmen planen 2026 insgesamt rund 725 Milliarden Dollar für den Bau von KI-Rechenzentren auszugeben.
Der Strombedarf amerikanischer Rechenzentren könnte durch diese Entwicklung von derzeit 40 Gigawatt auf 106 Gigawatt bis 2035 ansteigen. Und vor Ort schürt der Bau von Rechenzentren zunehmend Widerstand: Lokale Gemeinden wehren sich gegen Neubauten, Stromnetze stoßen an ihre Grenzen.
Panthalassas Ansatz reiht sich in eine wachsende Liste unkonventioneller Lösungen ein.
Meta etwa will seine Rechenzentren künftig mit Solarstrom aus dem All versorgen [5] – das Start-up Overview Energy soll dafür Satelliten im geostationären Orbit positionieren, die Nahinfrarot-Licht zur Erde strahlen. Meta hat bereits 1 Gigawatt Kapazität reserviert [6].
Andere Unternehmen setzen auf Geothermie als Energiequelle für Rechenzentren [7] – neue Bohrtechniken aus dem Fracking erschließen Erdwärme auch abseits vulkanischer Gebiete.
Chinesische Firmen wiederum bauen Unterwasser-Rechenzentren vor Hainan und Shanghai, während das Unternehmen Keppel ein schwimmendes Rechenzentrum für Singapur errichtet.
"Die Zukunft erfordert mehr Rechenleistung, als wir uns vorstellen können", wird Thiel [8] von dem Portal Tom‘s Hardware zitiert . "Außerirdische Lösungen sind keine Science-Fiction mehr. Panthalassa hat die Grenze des Ozeans erschlossen."
Ob die schwimmenden Knoten tatsächlich eine relevante Ergänzung zur Recheninfrastruktur werden, muss der Ocean-3-Test zeigen.
URL dieses Artikels:
https://www.heise.de/-11284198
Links in diesem Artikel:
Copyright © 2026 Heise Medien
US-Ölkonzerne kehren nach Venezuela zurück, während die Regierung nicht mehr souverän agieren kann
(Bild: Hamara/Shutterstock.com)
Krieg, hohe Preise, neuer Kurs: US-Ölkonzerne wagen die Rückkehr nach Venezuela – doch alles unter US-Aufsicht. Ein Poker um Öl, Macht und Risiko.
Ende April 2026 reisten [1] Vertreter der US-amerikanischen Ölindustrie, Ingenieure und Anwälte in die Lobby des stark bewachten J.W. Marriott Hotel der venezolanischen Hauptstadt Caracas. Ihr Ziel: Die Präsentation von Plänen zur Wiederbelebung der heruntergekommenen Ölfelder des Landes.
Dabei hatten große US-Ölkonzerne wie ExxonMobil und ConocoPhilipps noch Anfang Januar Venezuela als zu riskant für Geschäfte und "nicht investierbar" ohne erhebliche Änderungen an den Rahmenbedingungen angesehen [2].
Auslöser für die unvermittelte Rückkehr sind mehrere Faktoren: Zum einen treiben die stark gestiegenen Ölpreise im Zuge des Krieges gegen den Iran und die faktische Schließung der Straße von Hormus [3] die Nachfrage nach alternativen Quellen an. Zum anderen kommen rechtliche Änderungen seitens der US-Regierung sowie der venezolanischen Regierung unter Interimspräsidentin Delcy Rodríguez hinzu, die ausländische Investitionen begünstigen.
Rodríguez übernahm nach der völkerrechtswidrigen Entführung und Festnahme [4] des ehemaligen Präsidenten Nicolás Maduro durch US-Streitkräfte am 3. Januar 2026 die Regierungsführung in dem Karibikstaat. Sie kooperiert mit den USA und steht unter immensem Druck, die riesigen Ölvorkommen des Landes zu erschließen. Beim Sturz Maduros lag das Ziel der US-Regierung klar auf der Kontrolle über die immensen Ölreserven des Landes.
Seitdem transportieren Tanker weitaus mehr venezolanisches Rohöl an die Golfküste der Vereinigten Staaten. Im März 2026 importierten [5] die USA laut dem Marktinformationsunternehmen Kpler täglich 457.000 Barrel venezolanisches Rohöl – der höchste Stand seit Januar 2019, als US-Präsident Donald Trump während seiner ersten Amtszeit Sanktionen gegen den staatlichen Ölkonzern Petróleos de Venezuela (PdVSA) verhängte.
Das neue Regelwerk: US-Recht für venezolanisches Öl Mitte März führte die US-Administration zusätzliche strenge neue Regeln ein, die in der OFAC General License 52 (GL 52) festgehalten [6] sind. Demnach müssen die Einnahmen aus venezolanischem Öl zur Tilgung der Staatsschulden beitragen und dürfen nicht sanktionierten Personen zugutekommen.
Jeder Vertrag mit dem staatlichen Ölkonzern PdVSA unterliegt ferner US-Recht und etwaige Streitigkeiten müssen in den USA beigelegt werden. Die meisten Zahlungen müssen auf ein vom US-Finanzministerium kontrolliertes Konto erfolgen und dürfen nicht direkt an die venezolanische Regierung geleistet werden.
Zudem sind Transaktionen, an denen Personen oder Unternehmen aus Russland, Iran, Nordkorea oder Kuba beteiligt sind, strengstens verboten. Das gilt für Export, Transport, Lagerung und Erkundung von Öl venezolanischen Ursprungs sowie für die Lieferung von Technologie, Software oder das Erbringen von Dienstleistungen für die Erdölförderung in dem Land.
Ebenfalls verboten sind Transaktionen mit US-amerikanischen oder venezolanischen Unternehmen, die sich im Besitz einer Person mit Sitz in China befinden oder von einer solchen Person kontrolliert werden.
Der Rechtsakt versinnbildlicht Neokolonialismus in Reinform, wobei sich die venezolanische Regierung zur US-Marionette gemacht hat und die Reichtümer des Landes an US-Großkonzerne verschleudert.
Am aktivsten ist derzeit das US-Unternehmen Chevron: Der Konzern, seit fast zwei Jahrzehnten vor Ort, betreibt vier Joint Ventures, die für fast 25 Prozent der venezolanischen Gesamtproduktion verantwortlich sind. Zwei weitere Felder stehen [7] kurz vor der Vergabe.
Neulinge wie Hunt Oil und Crossover Energy haben bereits Verträge unterzeichnet [8], während Größen wie ExxonMobil und ConocoPhillips, deren Vermögenswerte unter einer früheren Regierung beschlagnahmt worden waren, zögern. Mit Blick auf die Enteignungen unter Präsident Hugo Chavéz im Jahr 2007 forderte [9] Exxon-CEO Darren Woods erhebliche Änderungen am Rechtssystem und beim Investitionsschutz.
Nach Jahren der Unterinvestition sind Venezuelas Ölanlagen zudem baufällig. Analysten schätzen, dass Unternehmen etwa 80 US-Dollar pro Barrel benötigen, um die Gewinnschwelle zu erreichen. Bei Preisen wie noch Anfang 2026 unter 60 US-Dollar wäre es ein Verlustgeschäft. Eine damals von der Trump-Regierung angekündigte Investition von 100 Milliarden US-Dollar stieß in der Branche auf Skepsis, weil, so Branchenkenner, die Rechnung nicht aufgehe.
Mit Blick auf den wahrscheinlich längerfristig hohen Ölpreis haben nun ExxonMobil und ConocoPhillips erstmals seit Jahren wieder technische Teams nach Venezuela entsandt [10], um ihre ehemaligen Felder zu inspizieren. Doch bislang wurden keine neuen Investitionen zugesagt. Die Unternehmen befinden sich noch in der Bewertungsphase.
Für die US-Regierung geht es dabei nicht nur um das Öl, sondern ebenso darum, geopolitische Rivalen systematisch aus dem beanspruchten und traditionellen Einflussbereich zu verdrängen.
So setzen die USA ihr Rechts- und Finanzsystem als legitimen Rahmen für venezolanisches Öl durch und zielen darauf ab, Gegensysteme zu zerschlagen, die Russland und China zur Umgehung westlicher Sanktionen aufgebaut haben.
In Venezuela sind mehrere russische Projekte von den Entwicklungen seit Anfang Januar betroffen. Das Petromonagas-Joint-Venture, das früher gemeinsam von der PdVSA und der russischen Roszarubezhneft betrieben wurde, wird nun ausschließlich von der PdVSA geführt. Für die Boquerón- und Perijá-Ölfelder wurden zwar im November 2025 Verlängerungen über 15 Jahre bis 2041 genehmigt [11], doch Transaktionen mit Russland sind rechtlich verboten.
Insgesamt sind russische Gesamtinvestitionen in Höhe von rund 17 Milliarden US-Dollar in Venezuela gefährdet. Russlands Außenminister Sergej Lawrow bezeichnete die US-Beschränkungen als "eklatante Diskriminierung", obwohl Russland, China und der Iran Investitionen im venezolanischen Öl- und Energiesektor getätigt hätten. Russische Unternehmen würden im Zuge der Ereignisse in Venezuela ganz offen aus dem Land gedrängt [12].
China ist in den letzten Jahren zu einem wichtigen Abnehmer und Investor im venezolanischen Ölsektor geworden. Laut einem Bericht [13] von Reuters, der auf Daten des Analyseunternehmens Vortexa basiert, beliefen sich die chinesischen Importe von venezolanischem Öl im Jahr 2025 auf etwa 470.000 Barrel pro Tag. Dies entspricht rund 4,5 Prozent der gesamten chinesischen Rohölimporte auf dem Seeweg und nimmt einene Großteil des von Venezuela exportieren Öls ein. Auch Peking dürfte die Entwicklung derzeit mit Sorge betrachten.
URL dieses Artikels:
https://www.heise.de/-11284012
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Die Buchstaben AI umfliegen Haken und Warndreiecke.
(Bild: tadamichi/Shutterstock.com)
Die Free Software Foundation Europe warnt vor dem Umstellen der NHS-Code-Repositories auf Privat aus Angst vor KI-Schwachstellensuche.
Berichten zufolge plant der englische National Health Service (NHS England), die meisten seiner öffentlichen Quelltext-Repositories auf „Privat“ umzustellen, warnt die Free Software Foundation Europe (FSFE [1]) aktuell. Das scheint als Reaktion auf die Sorge zu erfolgen, dass öffentliche Quelltext-Repositorys mittels Künstlicher Intelligenz [2] auf Schwachstellen untersucht werden könnten.
Die FSFE gibt in einer Meldung [3] dazu an, dass eine interne Richtlinie mit dem Titel „SDLC-8“ erfordere, öffentlich zugängliche Repositories auf „Privat“ umzustellen, außer in Fällen, in denen eine explizite Ausnahme genehmigt wird. Die FSFE sieht darin einen Schritt in die falsche Richtung. Bereits veröffentlichte Repositories offline zu nehmen schützt nicht davor, dass Angreifer bereits aufgesetzte Systeme, Abhängigkeiten, Schnittstellen und Binärdateien analysieren.
Das Depublizieren der Quellcodes mache diesen nicht ungesehen – ebenso wenig entfernt das bereits existierende Kopien. Zudem handele es sich um keine effektive Sicherheitsmaßnahme. Stattdessen entferne der Schritt eine fundamentale Säule der Sicherheit, nämlich die Möglichkeit von unabhängigen IT-Experten, IT-Forschern und anderen öffentlichen Institutionen, den Code zu inspizieren, weiterzuverwenden und zu verbessern sowie Sicherheitslücken darin zu melden, erörtert die FSFE.
Johannes Näder, Senior Policy Project Manager bei der FSFE, äußerte sich auch dazu: „Das Zurückziehen von öffentlich zugänglichem Code ist keine Sicherheitsstrategie. ‚Security by Obscurity’ gilt schon seit Langem nicht mehr als wirksame Sicherheitsmaßnahme. Die Umstellung von Repositorys auf den privaten Modus schützt die NHS-Systeme nicht. Sie schränkt lediglich ein, wer bei der Suche nach und Behebung von Problemen helfen kann.“
Gegenüber The Register [4] sagte ein NHS-England-Sprecher, dass es sich lediglich um eine temporäre Maßnahme handele, um die Cybersicherheit zu stärken und abzuwägen, welche Auswirkungen die rasanten Entwicklungen der KI-Modelle haben. Man werde weiterhin Quellcode veröffentlichen, wenn es einen klaren Bedarf gebe.
Eine der Kernforderungen der FSFE ist, dass aus öffentlichen Mitteln finanzierte Software als freie Software veröffentlicht werden soll. Die bisherigen NHS-Richtlinien sähen das bislang ebenso vor. Neuer Source-Code für öffentliche Dienste sollte offen und wiederbenutzbar sein, da öffentliche Dienste auf öffentlichen Geldern fußen. Die Vorgaben für UK-Behörden sehen das ebenso vor, mit nur eng begrenzten Ausnahmen. Die FSFE fordert daher den NHS England auf, alle Richtlinien zu standardmäßig als privat behandelten Quellcode zurückzuziehen und sich dazu zu bekennen, dass freie Software der Standard für öffentlich finanzierte Software bleibe.
Die FSFE hatte im März dieses Jahres Probleme [5] mit einem Zahlungsdienstleister zur Spendenabwicklung gemeldet. Dafür wurde eine Lösung gefunden.
URL dieses Artikels:
https://www.heise.de/-11283406
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: GaudiLab/Shutterstock.com)
Die Event-sourced Domain Modeling Language beschreibt Event-getriebene Domänen als YAML neben dem Code und macht das Modell mit derselben Werkzeugkette prüfbar.
Domain-driven Design (DDD) und Event Sourcing leben von einem präzisen Vokabular. Aggregates, Bounded Contexts, Process Managers, Read Models, Context Mappings: Wer in diesen Begriffen denkt, hat ein gemeinsames Werkzeug, um über fachliche Systeme zu sprechen. Solange das Gespräch während eines Workshops live stattfindet, funktioniert das verlässlich. Das Modell ist konsistent, weil alle Beteiligten es gleichzeitig im Kopf tragen.
Sobald der Workshop jedoch endet, beginnt das Problem. Das Modell verlässt den Raum nicht als gemeinsames Artefakt, sondern als Sammlung von Bruchstücken: ein paar Folien aus dem letzten Review, ein Whiteboard-Foto, eine README.md, verstreute Code-Kommentare, vielleicht ein Diagramm im Wiki. Jede dieser Quellen ist plausibel, aber keine ist autoritativ. In diesem Beitrag stelle ich die von meiner Firma the native web entwickelte Sprache ESDM (Event-Sourced Domain Modeling) [1] vor und beschreibe, warum sie aus meiner Sicht die richtige Antwort auf dieses Problem ist.
Das eigentliche Drama spielt sich in den Wochen nach dem Workshop ab. Ein Entwickler reicht eine Refactoring-Änderung ein, die einen Aggregatnamen umbenennt. Das Code Review winkt sie durch. Niemand denkt an die Folien, niemand öffnet das Wiki, niemand sucht das Whiteboard-Foto wieder heraus. Das Modell auf der Platte verändert sich, das Modell im Kopf der anderen bleibt unverändert, und der Drift beginnt.
Sechs Monate später kommt eine neue Kollegin ins Projekt. Sie liest die Folien aus dem Onboarding, weil das die einzige zusammenhängende Beschreibung ist, die sie findet. Was sie liest, stimmt nicht mehr mit der Realität überein. Ein Bounded Context heißt anders, ein Event existiert nicht mehr, ein ehemals Aggregat ist in zwei zerlegt worden. Die Folien sind kein Modell, sie sind ein Foto eines Modells aus einem bestimmten Monat.
In dieser Lage gibt es eigentlich nur drei mögliche Quellen der Wahrheit, und keine davon ist eine gute: Die Folien sind veraltet, das Wiki ist veraltet, und der Code beschreibt das Modell nicht, sondern führt es aus. Wer die fachliche Wahrheit wissen will, muss aus dem Code rückwärts rekonstruieren, was die ursprüngliche Idee einmal war. Das ist anstrengend, fehleranfällig und nicht skalierbar.
Der Kern des Problems ist, dass das Modell kein erstklassiges Artefakt ist. Es hat keinen festen Ort, kein verbindliches Format, keine prüfbaren Eigenschaften. Es ist nirgendwo zu Hause, also lebt es überall ein bisschen, und überall ein bisschen heißt im Zweifel nirgendwo richtig.
Aus diesem Befund ergibt sich eine ziemlich genaue Anforderungsliste an eine Lösung. Das Modell muss versionierbar sein, also als Text vorliegen, den eine Versionsverwaltung sinnvoll diffen kann. Es muss neben dem Code im Repository leben, damit derselbe Pull-Request, der den Code ändert, auch das Modell einbezieht.
Es muss prüfbar sein, in dem Sinne, dass eine Maschine bestimmte strukturelle Aussagen über das Modell automatisch validieren kann. Ob jedes Aggregat seine Events benennt, ob jedes Event einen Erzeuger hat, ob jeder Context-Mapping-Verweis auf einen tatsächlich existierenden Bounded Context zeigt: Solche Fragen darf nicht der Lesende beantworten müssen, sondern die Werkzeugkette.
Es muss von Werkzeugen lesbar sein, also einer eindeutigen Grammatik folgen. Sobald das Format steht, lassen sich Validatoren, Generatoren, IDE-Integrationen und KI-gestützte Modellierungswerkzeuge dagegen bauen. Dieser Punkt klingt wie ein Nebensatz, ist aber der Hebel, der eine Sprache von einer Konvention unterscheidet.
Und es muss frei von Dialekten sein. Ein Format, das sich pro Team konfigurieren lässt, beschreibt am Ende keine gemeinsame Sprache, sondern eine Familie verwandter Privatsprachen. Der Wert eines geteilten Modells kollabiert, sobald jedes Projekt seine eigenen Regeln zuschneidet. Wer sich auf die Sprache verlassen können will, braucht eine Sprache, die nicht jede Stelle einzeln aushandelbar ist.
ESDM, kurz für Event-Sourced Domain Modeling, ist genau die Sprache, die diesen Anforderungen entspricht. Die YAML-basierte Sprache mit eingebauter Werkzeugkette ist auch für den kommerziellen Einsatz kostenfrei. Modelle bestehen aus Dateien mit der Endung .esdm.yaml, jede Datei enthält ein oder mehrere Dokumente, jedes Dokument deklariert eine apiVersion und einen kind-Eintrag und beschreibt damit genau ein Element der Domäne.
Die Werkzeugkette ist ein einziges Binary, das auf macOS, Linux und Windows läuft. Das Schema, gegen das die Werkzeuge validieren, ist im Binary eingebettet, nicht aus dem Netz nachgeladen. Das macht ESDM vollständig offline-fähig: Es funktioniert in abgeschotteten Build-Umgebungen, in CI-Runnern ohne ausgehende Netzverbindung und auf dem Laptop im Zug.
Der Effekt dieses Aufbaus ist greifbar. Das Modell liegt nicht mehr in einem entfernten System, sondern direkt im Repository, in einem Verzeichnis neben dem Code. Wer den Code bearbeitet, sieht das Modell. Wer das Modell bearbeitet, sieht es im Diff des Pull Request. Niemand muss sich daran erinnern, dass es das Modell gibt; es liegt sichtbar im Verzeichnisbaum.
Genauso wichtig ist, was sich dadurch im Review-Verhalten verändert. Sobald das Modell Teil des Repositorys ist, wird es Teil des Code-Reviews. Eine Refactoring-Änderung, die einen Aggregatnamen umbenennt, muss die entsprechende .esdm.yaml-Datei in derselben Änderung mitbewegen, sonst meldet der Linter den Bruch. Der Drift wird nicht durch Disziplin verhindert, sondern durch die Werkzeugkette.
Inhaltlich deckt ESDM das Vokabular ab, mit dem Domain-driven Design und Event Sourcing operieren. Domains und Subdomains beschreiben den fachlichen Rahmen. Bounded Contexts grenzen Vokabularien voneinander ab. Aggregates, Dynamic Consistency Boundaries (DCBs) und Process Manager tragen die Konsistenzregeln. Events und Commands tragen die Fakten und die Absichten. Read Models und Queries beschreiben die Leseseite. Context Mappings beschreiben, wie Bounded Contexts sich aufeinander beziehen. Actors, Domain Services, Event Handler, Policies und External Systems schließen die Lücken, die in realen Systemen sonst implizit bleiben.
Damit deckt der Kern den Schreib- und Leseweg eines Event-getriebenen Systems ab, von der Absicht über das Faktum bis zur projizierten Sicht. Das Modell ist nicht ausführbar; es beschreibt das Was, nicht das Wie. Diese Trennung ist die Voraussetzung dafür, dass dasselbe Modell für unterschiedliche Implementierungen tragen kann, ohne sich an eine Laufzeit zu binden.
Über den Kern hinaus gibt es Erweiterungen, die Artefakte rund um das eigentliche Modellieren beschreiben. Die Domain-Storytelling-Erweiterung [2] hält Entdeckungsgeschichten als eigene Dokumentenart fest, mit Akteurinnen und Akteuren, Arbeitsobjekten und den Aktivitäten, die sie verbinden. Die Given-When-Then-Erweiterung [3] erfasst Verhaltensbeispiele, also vorausgehende Events, eine auslösende Handlung und die erwarteten Ausgänge.
Beide Erweiterungen folgen denselben Konventionen wie der Kern und werden von derselben Werkzeugkette validiert. Sie injizieren aber keine neuen Bausteine in den Kern, und ein Kerndokument validiert nie gegen ein Erweiterungsschema. Diese Asymmetrie ist bewusst: Sie hält den Kern schmal und erlaubt es trotzdem, die Oberfläche der Sprache mit der Zeit wachsen zu lassen, ohne den Bestand zu gefährden.
Die Versionierung des Schemas folgt derselben Disziplin, die Sie aus Kubernetes-API-Gruppen kennen. Jedes Dokument deklariert eine apiVersion, und diese Version bindet das Dokument an eine konkrete Schema-Generation. Non-breaking Changes erhöhen die Schema-Revision, ohne die apiVersion anzufassen; Breaking Changes wandern in eine neue Hauptversion, und alte Dokumente validieren weiter gegen das alte Schema. Stabilität ist die Voreinstellung, Wechsel sind eine bewusste Entscheidung.
Im Zentrum der Werkzeugkette steht der Linter. Er liest die .esdm.yaml-Dateien unter einem Verzeichnis, parst sie gegen das eingebettete Schema, prüft eine feste Liste struktureller und modellierender Regeln und meldet jede Verletzung als Diagnose mit Datei, Zeile und Spalte. Eine saubere Modellierung erzeugt keine Ausgabe und verlässt das Werkzeug mit Statuscode 0.
Der feste Regelkatalog ist eine bewusste Entscheidung. Es gibt keine Projektkonfigurationsdatei, keine Severity-Schalter, kein Abschalten einzelner Regeln. Eine Regel gilt oder sie gilt nicht; diese Entscheidung trifft die Werkzeugkette, nicht das Repository. Der Preis dafür ist, dass eine Regel gelegentlich strenger wirkt, als die konkrete Situation zu verlangen scheint. Der Gewinn ist, dass jedes ESDM-Modell, egal von welchem Team, dieselben Eigenschaften garantiert. Eine Sprache mit Schaltern beschreibt am Ende viele Sprachen mit demselben Namen, und der Wert des gemeinsamen Modells geht verloren.
Diagnosen sind Orte, keine Stack Traces. Jede Meldung verweist auf eine Datei, eine Zeile und eine Spalte und beschreibt das Problem in einem kurzen Satz, der das Vokabular der Modellierenden spricht, nicht das der Werkzeugkette. Es gibt keine Fehlernummern, die in einer Tabelle nachgeschlagen werden müssten, und keine internen Aufrufketten, die nach außen sichtbar wären.
Die volle Wirkung entfaltet der Linter, sobald er in der Continuous-Integration-Pipeline läuft. Ein Pull Request, der ein Aggregat umbenennt, ohne das Modell mitzuziehen, scheitert am CI-Schritt und wird nicht gemergt. Ein neues Event ohne Erzeuger oder ohne Konsumenten scheitert genauso. Der Drift, der vorher durch Disziplin verhindert werden musste, wird durch eine kurze, präzise Diagnose verhindert.
Konkret zahlt sich diese Architektur in mehreren Szenarien aus. Im Event-Storming-Workshop oder in der Domain-Storytelling-Sitzung gibt ESDM den Entdeckungen einen Ort, an dem sie überleben. Statt nach dem Workshop Fotos zu archivieren, schreibt man die Events, Commands, Akteurinnen und Akteure und Bounded Contexts in .esdm.yaml-Dateien und bekommt sofort Rückmeldung, ob das Modell intern konsistent ist. Ein Aggregat, das keine Events besitzt, ein Command, das niemand publiziert, ein Process Manager ohne Auslöser: Solche Lücken zeigt der Linter, bevor sie sich als unausgesprochene Annahmen verfestigen.
Bei einem bestehenden System, dessen Modell nur in den Köpfen der Beteiligten existiert, lässt sich ESDM als nachträgliches Beschreibungswerkzeug einsetzen. Beginnen Sie mit den Konsistenzeinheiten: jedes Aggregat, jeden Process Manager, jede Dynamic Consistency Boundary (DCB), jedes Read Model. Listen Sie die Events auf, die jeweils publiziert werden, und die Commands, die akzeptiert werden. Die Übung selbst legt Lücken frei, und am Ende steht ein Modell, das mit dem Code mitwachsen kann, statt ihm hinterherzulaufen.
Sobald das Modell vorliegt, wird es zum natürlichen Gesprächsformat mit fachlichen Stakeholderinnen und Stakeholdern. Der view-Befehl rendert das Modell als hierarchische Übersicht, von der Domäne über die Subdomains und Bounded Contexts bis hinunter zu den Konsistenzeinheiten und ihren Events und Commands. Diese Übersicht ist auf Knopfdruck verfügbar und entspricht garantiert dem Quellzustand. Domänenexpertinnen und Domänenexperten lesen darin dieselben Begriffe, die sie selbst verwenden, und können ohne Umweg über Implementierungsdetails Rückmeldung geben.
In Systemen mit mehreren Teams und gemeinsamen Bounded Contexts macht ESDM die Verträge zwischen den Teams explizit. Ein Context Mapping beschreibt die Beziehung zwischen zwei Bounded Contexts, ein teamübergreifender Event-Verweis ist eine geprüfte Tatsache und keine Vermutung. Was zwischen zwei Teams einmal vereinbart und im Modell festgehalten ist, prüft die Werkzeugkette danach automatisch. Die fachliche Annahme ist nicht mehr nur eine geteilte Erinnerung, sondern eine prüfbare Aussage.
Schließlich passt ESDM erstaunlich gut zu Workflows mit KI-Unterstützung. Das YAML ist schlicht genug, dass große Sprachmodelle es direkt lesen und schreiben, und das fixierte Schema und das benannte Vokabular geben dem Modell genau die Leitplanken, die es braucht, um etwas Kohärentes zu produzieren. Ein Modell aus einem Domänengespräch zu skizzieren oder aus einem Code-Bestand Kandidaten für Aggregates und Events zu extrahieren, sind Aufgaben, die sich mit dem ESDM-Vokabular zuverlässiger und überprüfbarer lösen lassen, als wenn das Modell in Prosa beschrieben wird.
Genauso wichtig wie die Beschreibung dessen, was ESDM ist, ist auch die Abgrenzung zu dem, was es nicht ist. ESDM ist kein Eventstore. Es speichert und liest keine Ereignisse, es legt nichts in eine Datenbank ab. ESDM beschreibt lediglich, welche Events es überhaupt geben soll.
ESDM ist auch kein Framework. Es schreibt keinen Programmierstil vor, keine Klassenhierarchie, keine Annotationen, keinen bestimmten Aufbau eines Service. Welche Sprache, welches Framework, welche Bibliothek Sie für die tatsächliche Implementierung verwenden, bleibt vollständig Ihnen überlassen. ESDM mischt sich in diese Entscheidungen nicht ein.
ESDM ist kein Codegenerator und keine Laufzeitumgebung. Es erzeugt aus dem Modell keine Klassen, keine Migrationen, keine API-Endpunkte. Es führt nichts aus. Diese Entscheidung ist keine Lücke, sondern Programm: Eine Modellierungssprache, die zugleich generieren oder ausführen will, zwingt mich zu Laufzeitentscheidungen, und eine Laufzeit, die zugleich modelliert, vergräbt das Modell unter Implementierungsdetails.
ESDM hält die beiden Seiten getrennt. Es ist eine deskriptive Schicht, die neben dem Code lebt und das Modell ehrlich hält, und es ist genau das, nichts darüber hinaus. Diese Sparsamkeit ist die Voraussetzung dafür, dass ESDM sich frei mit dem kombinieren lässt, was Sie tatsächlich in Produktion betreiben.
URL dieses Artikels:
https://www.heise.de/-11279687
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Die beiden Honor-Smartphones sehen ähnlich aus, liegen allerdings leistungsmäßig ein ganzes Stück auseinander – und auch preislich.
Smartphones der oberen Mittelklasse [1] [1] sollen in puncto Leistung und Ausstattung wie die teuren Luxusmodelle wirken, müssen aber preislich deutlich drunter bleiben – ein echter Spagat für die Hersteller. Mit dem Honor 600 und dem 600 Pro reizt der Hersteller die Spanne innerhalb dieser Preisklasse weit aus.
Die unverbindliche Preisempfehlung des Honor 600 liegt bei knapp 650 Euro, das 600 Pro sortiert sich mit 1000 Euro eine Etage höher ein. Diese Preise dürften allerdings kaum je verlangt werden: Zum Start gewährt Honor einen Monat lang 100 beziehungsweise 200 Euro Preisnachlass und legt noch etwas Zubehör mit ins Paket. Schwer vorstellbar, dass man für die Smartphones nach der Einführungsphase wirklich den vollen UVP zahlen muss.
Beim Design gehen die beiden Geschwister Hand in Hand, sie sehen sich sehr ähnlich. Ein Rahmen aus Metall verbindet Glasflächen vorne und hinten. Die Rückseite ist weitestgehend matt gehalten; nur der obere Bereich, in dem die Kamera sitzt, ist glänzend ausgeführt – und sammelt schnell feinen Schmutz und Fingerabdrücke ein, sehr zum Missfallen unseres Redaktionsfotografen. Im Rahmen steckt außer den üblichen Tasten zum Einschalten und für die Lautstärke ein weiterer Knopf, der die Kamera auslöst oder KI-Funktionen aktiviert. Die Verarbeitung der Smartphones, die nach IP68/IP69K gegen Untertauchen, Strahlwasser und Staub geschützt [8] [8] sind, ist dem Hersteller gut gelungen.
URL dieses Artikels:
https://www.heise.de/-11209888
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Google Android-Bugdroid vor Schloss-Symbol.
(Bild: Primakov/Shutterstock.com)
Schadcode kann durch ein fehlerhaftes Debugging-Modul auf Androidgeräte schlüpfen. Nun hat Google die kritische Schwachstelle geschlossen.
Um Attacken auf Smartphones und Tablets mit Android 14, 15, 16 und 16qpr2 vorzubeugen, sollten Besitzer von noch im Support befindlichen Geräten das aktuelle Sicherheitsupdate installieren. Neben Googles Pixel-Serie steht es auch für ausgewählte Geräte von unter anderem Samsung zur Verfügung (siehe Kasten).
Im März dieses Jahres ist der Support für Android 13 ausgelaufen, und diese Version bekommt seitdem keine Sicherheitspatches mehr. Davon sind Millionen Geräte betroffen [1].
Nutzen Angreifer eine „kritische“ Sicherheitslücke (CVE-2026-0073) im Debugging-Modul adbd aus, können sie aus der Ferne Schadcode ausführen, erläutern die Entwickler in einer Warnmeldung [2]. In der Regel gelten Systeme im Anschluss als vollständig kompromittiert. Wie ein solcher Angriff ablaufen könnte, ist zurzeit unklar. Bislang gibt es seitens Google keine Hinweise, dass Angreifer die Schwachstelle bereits ausnutzen. Die Entwickler führen aus, das Sicherheitsproblem im Patch Level 2026-05-01 gelöst zu haben.
Im Juli 2025 hat Google sich dafür entschieden [3], am monatlichen Android-Patchday nur noch seiner Einschätzung nach besonders gefährliche Sicherheitslücken zu schließen. Weitere Patches folgen seitdem quartalsweise.
URL dieses Artikels:
https://www.heise.de/-11281884
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: KI / heise medien)
Mit über einer Milliarde Exemplaren ist NE555 immer noch der meistproduzierte Chip. Er ist wohl in jedem Haushalt mit elektronischen Geräten irgendwo verbaut.
Heute, am 5. Mai 2026, wird der wohl berühmteste integrierte Schaltkreis der Welt 55 Jahre alt: der NE555 Timer-Chip. Ein Anlass, den auch der bekannte YouTuber Big Clive auf besonders kreative Weise feiert – mit einem 5 Minuten und 55 Sekunden langen Video, das exakt um 5:55 Uhr morgens am 5. Tag des 5. Monats veröffentlicht wird. Zusätzlich gibt es um 17:55 Uhr (UK-Zeit) einen 55-minütigen Livestream.
Der NE555 wurde 1971 von Hans Camenzind für Signetics [1] entworfen und gehört zu den ersten integrierten Schaltkreisen, die auch heute – 55 Jahre später – noch in massenhafter Verwendung sind. Camenzind schuf damit einen außergewöhnlich vielseitigen Baustein, der sich am besten als Sammlung elektronischer Lego-Bausteine beschreiben lässt: Er kann als Timer, Oszillator, Schwellwertdetektor und für viele weitere Anwendungen eingesetzt werden.
Zu den großen Stärken des Chips gehören sein weiter Versorgungsspannungsbereich von 4,5 V bis 16 V sowie die Fähigkeit, direkt Lasten von bis zu 200 mA am Ausgang zu treiben – Eigenschaften, die ihn auch heute noch konkurrenzfähig machen. Wer es ganz genau wissen will und dem Chip aufs Silizium schauen möchte, ist bei Ken Shirriff genau richtig [2].
(Bild: ZeptoBars)
Übrigens: Die landläufige Meinung, der Name „555“ leite sich von den drei 5-kΩ-Widerständen im internen Spannungsteiler ab, wurde von Camenzind selbst zurückgewiesen. Den eingängigen Namen verdanken wir laut ihm einem Marketing-Mitarbeiter mit dem fast schon zu schön klingenden Namen Art Fury. Ob Fury sich nicht doch von den drei Widerständen inspirieren ließ, bleibt allerdings sein Geheimnis.
Hans Camenzind (gest. 2012) [3] selbst soll einmal gesagt haben, er würde den Chip heute anders entwerfen – aber im Nachhinein ist man bekanntlich immer schlauer. 1971 betrat er Neuland und landete mit dem 555 einen Volltreffer, der die Elektronikwelt bis heute prägt.
Das Video (5min 55s) zum NE555 von Big Clive bietet einen unterhaltsamen und praktischen Einblick in die Funktionsweise dieses außergewöhnlichen Chips.
Praktisch jeder hat irgendwo einen 555 in seinen elektronischen Geräten – oft, ohne es zu wissen. Hier eine kleine Auswahl:
Klassische Anwendungen:
Weniger bekannte Einsätze:
Big Clive (siehe Video oben) würdigt im Video auch andere langlebige Klassiker, die ähnlich allgegenwärtig sind: den LM358 Dual-Op-Amp, den LM324 Quad-Op-Amp, den LM393 Komparator sowie zahlreiche TTL- und CMOS-Logikbausteine. Selbst in der Welt der Mikrocontroller gibt es solche Urgesteine: Die 8051-Architektur von 1980 findet sich noch immer in vielen generischen Chips aus chinesischer Produktion – und ist damit über 45 Jahre alt.
Happy Birthday [7], kleiner Chip – auf die nächsten 55 Jahre!
URL dieses Artikels:
https://www.heise.de/-11282093
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Tux by Larry Ewing / GIMP)
Die Entdecker haben die root-Lücke im Linux-Kernel „Copy Fail“ getauft. Alle größeren Distributionen seit 2017 sind betroffen.
Im Linux-Kernel haben IT-Forscher eine Schwachstelle entdeckt, die Angreifer zum Erlangen von root-Rechten missbrauchen können. Die Entdecker haben die Schwachstelle „Copy Fail“ getauft. Ihnen zufolge sind alle Linux-Distributionen, die seit 2017 verfügbar sind, davon betroffen.
Das schreiben die IT-Forscher in einem Blog-Beitrag [1], der Bericht ist ihnen jedoch sogar eine eigene Domain wert [2]. Die Lücke haben sie offenbar mit dem KI-Werkzeug Xint Code aufgespürt. Es handelt sich um einen Logikfehler, der lokalen Nutzern im System ermöglicht, einen deterministischen, kontrollierten 4-Byte-Schreibzugriff auf den Page-Cache jedes lesbaren Dateisystems eines Rechners auszuführen. Mit einem Python-Skript von 732 Byte Größe gelingt es den Forschern, eine Binärdatei mit setuid-Flag zu manipulieren und dadurch root-Rechte zu erlangen (CVE-2026-31431 [3], CVSS 7.8, Risiko „hoch“).
Die IT-Sicherheitsforscher führen weiter aus, dass der Kernel die manipulierte Page nicht als „Dirty“ zum Rückschreiben aufs Laufwerk markiert, sodass die Datei unverändert bleibt und einfache Checksummen-Prüfungen von der Manipulation nichts mitbekommen. Beim tatsächlichen Dateizugriff erfolgt jedoch der Rückgriff auf den Page-Cache. Damit lassen sich zudem Container-Grenzen sprengen, da der Page-Cache auf dem Host geteilt wird. Konkret kündigen die IT-Forscher an, weitere Details zu veröffentlichen, die den Ausbruch aus Kubernetes-Containern erörtern.
Der Fund sei zwar KI-unterstützt gewesen, basierte aber auf Untersuchungen der Interaktion des Linux-Krypto-Subsystems mit Page-Cache-Daten. Interessierte finden sehr tiefgehende Details im Blog-Beitrag. Dort stellen die Programmierer auch einen Proof-of-Concept-Exploit vor. Das Python-Skript ist 732 Byte groß und verschafft lokalen Angreifern root-Rechte etwa unter Ubuntu 24.04 LTS mit Kernel 6.17.0-1007-aws, Amazon Linux 2023 mit Kernel 6.18.8-9.213.amzn2023, RHEL 10.1 und Kernel 6.12.0-124.45.1.el10_1 sowie SUSE 16 mit Kernel 6.12.0-160000.9-default. Zumindest haben die Entdecker der Schwachstelle diese Kombinationen erfolgreich getestet.
Einen Fix für den Kernel-Quellcode stellen die IT-Forscher ebenfalls bereit. Aktualisierte Kernel sollten inzwischen die größeren Distributionen bereitstellen. Als temporäre Gegenmaßnahme soll demnach aber helfen, AF_ALG-Socket-Erstellung über seccomp zu blockieren oder aber als algif_aead-Modul in die Blacklist aufzunehmen, sodass der Kernel es nicht lädt: echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf && rmmod algif_aead 2>/dev/null im Terminal erledigt das und entfernt gegebenenfalls das geladene Modul aus dem Speicher.
Es ist erst wenige Tage her, da hat die Telekom mittels KI die Schwachstelle „Pack2TheRoot“ in Linux [4] aufgespürt. Auch hierbei handelt es sich um eine Rechteausweitungslücke, die sich in mehreren Linux-Distributionen in den Standardkonfigurationen ausnutzen ließ.
Im letzten Satz korrigiert, dass die Lücke „Pack2TheRoot“ in Linux, nicht im Kernel war.
URL dieses Artikels:
https://www.heise.de/-11277590
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Espressif
Statt starrer Firmware setzt ESP-Claw auf Chat-Steuerung und KI für flexible IoT-Projekte.
Mit ESP-Claw hat Espressif ein neues Framework für ESP32-Boards veröffentlicht. Statt Geräte direkt zu programmieren, setzt das Projekt auf einen Agentenansatz direkt auf den Chips. Die Idee dahinter: Sensoren liefern Daten, ein lokaler Agent trifft Entscheidungen und das Gerät reagiert selbstständig.
Technisch basiert ESP-Claw auf einem Runtime-System, das auf ESP32-Boards wie dem S3 läuft. Der Ansatz nennt sich „Chat Coding“: Das Verhalten eines Geräts kann über Konversationen definiert werden, statt klassische Firmware zu schreiben. Im Hintergrund werden diese Eingaben in Aktionen übersetzt, die der Mikrocontroller ausführt. Ergänzt wird das Ganze durch eine ereignisgesteuerte Architektur, bei der Sensorwerte, Nachrichten oder andere Trigger direkt eine Verarbeitungskette starten können. Reaktionen sind laut Projekt im Millisekundenbereich möglich.
Für Maker interessant ist vor allem die flexible Erweiterbarkeit. ESP-Claw bringt eine strukturierte Speicherverwaltung mit, um Zustände und Kontext direkt auf dem Gerät abzulegen und nachhaltig zu speichern. Gleichzeitig lassen sich externe Dienste über standardisierte Schnittstellen anbinden, etwa über das Model Context Protocol (MCP). Auch die Integration von Messaging-Diensten wie Telegram ist vorgesehen, dadurch kann man Geräte in bestehende Kommunikationswege einbinden.
Ein weiterer praktischer Punkt ist die vergleichsweise niedrige Einstiegshürde. Unterstützte Boards lassen sich direkt im Browser konfigurieren und flashen, ohne lokale Toolchain. Wer tiefer einsteigen will, kann das System aber auch klassisch selbst bauen und anpassen. Durch den modularen Aufbau lassen sich einzelne Komponenten austauschen oder erweitern, etwa um zusätzliche Sensorik, Aktoren oder eigene Logik einzubinden.
Spannend wird das Ganze in Maker-Händen. Beispiele für Projekte sind etwa smarte Kameraknoten, die Ereignisse selbst interpretieren, Sprachinterfaces für Smart-Home-Steuerung oder Geräte, die auf Basis von Sensordaten eigenständig Entscheidungen treffen, etwa in der Heimautomation.
Auf der offiziellen GitHub-Seite [1] sind in Videos einige Beispielprojekte festgehalten. So wird ein LED-Streifen an einen ESP angeschlossen und dem Agenten via Chat mitgeteilt, wie dieser Streifen angeschlossen ist und dass mit dem LED-Streifen ein Regenbogenlicht realisiert werden soll. Nach kurzer „Überlegung“ des Agenten beginnt der Streifen entsprechend zu leuchten.
Für Maker bedeutet das vor allem weniger Code und mehr Fokus auf das Verhalten eines Projekts. Statt Zustände und Abläufe komplett selbst zu modellieren, kann man mit einem Agenten arbeiten, der sich dynamisch anpassen lässt. Gleichzeitig bleibt die Kontrolle über Daten erhalten, weil viele Funktionen lokal laufen. Noch ist das Projekt in Entwicklung, aber es zeigt recht deutlich, wohin sich IoT im Hobbybereich bewegen könnte: weg von starren Skripten, hin zu kleinen, eigenständig agierenden Systemen.
Wer direkt mit KI loslegen möchte, kann mit unserem selbst gebauten KI-Telefon [2] Ideen austauschen.
URL dieses Artikels:
https://www.heise.de/-11276353
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Halbleiterbauelemente sitzen auf Trägern, die als Brücke zur Platine dienen. Die Rohstoffe für diese Bauteile sind derzeit knapp.
(Bild: heise medien)
Der wichtigste Lieferant von Polyphenylenether hat nach einem Angriff offenbar die Auslieferungen eingestellt. Das betrifft alle elektronischen Geräte.
Es bahnt sich ein weiterer Mangel durch den Iran-Krieg an: Polyphenylenether (PPE) für die Herstellung von Platinen und teilweise Chipträgern könnte in den kommenden Monaten knapp werden. Die Saudi Basic Industries Corporation (SABIC) soll nach einem Raketenangriff durch Iran Anfang April die Auslieferungen eingestellt haben.
Darüber berichtet die Nachrichtenagentur Reuters [1] anhand geschäftsnaher Quellen. SABIC selbst schreibt [2] in seinem jüngsten Quartalsbericht vom 29. April lediglich über „sich verschärfende Lieferstörungen aufgrund des Konflikts im Nahen Osten“, die mehrere Kunststoffe betreffen.
Einen Lieferstopp bestätigt SABIC nicht, dementiert ihn aber auch nicht. Videos von Angriffen auf die saudische Region Al-Dschubail und ihre petrochemische Industrie wurden über soziale Medien geteilt.
Lieferzahlen zu PPE sind rar. Laut Reuters macht SABIC jedoch rund 70 Prozent der weltweiten Lieferungen aus. Gemäß einer Goldman-Sachs-Analyse sind die Preise für das Harz im April bereits um 40 Prozent gestiegen.
PPE ist unter anderem bis mehr als 100 Grad Celsius hitzebeständig, isoliert elektrisch und nimmt kaum Feuchtigkeit auf. Dadurch eignet sich das Harz für die Isolierschichten vor allem in Platinen (Printed Circuit Boards, PCBs). Alle elektronischen Geräte brauchen heutzutage PCBs, sodass ein Rohstoffmangel potenziell die Preise erhöht.
Schon das Glasgewebe von Nittobo und der Ajinomoto Build-up-Film (ABF) für Chipträger zeigten [3], dass essenzielle Bestandteile in der Halbleiterproduktion an einzelnen Unternehmen hängen. Häufig lohnt es sich für andere Firmen aufgrund normalerweise geringer Margen nicht, in den Markt einzusteigen.
Die Börse reagiert derweil schon auf die aktuelle Entwicklung: Die Aktie des südkoreanischen PPE-Zulieferers Kolon Industries ist allein im April um 30 Prozent gestiegen, seit Jahresbeginn um über 130 Prozent.
Der deutsche Verband der Elektro- und Digitalindustrie ZVEI schreibt in einer Stellungnahme an heise online, dass ihm zu Engpässen bei Kunststoffen wie PPE zumindest derzeit noch keine Meldungen vorliegen. Das könnte schlicht an der Auslagerung der Produktion nach Asien liegen – in Deutschland ist die Herstellung von PCBs längst nicht mehr rentabel. Bis sich ein Rohstoffmangel zu Beginn der Lieferkette hierzulande auswirkt, dürften Monate vergehen.
URL dieses Artikels:
https://www.heise.de/-11276801
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: ChatGPT)
Kampferprobte 3D-Drucke, mechanischer Flipper, 80 Stimmen Polyphonie mit ESP32, Fotos-Texturen mit FDM-Druck, macOS auf Wii, CardPuter mit Linux.
Bei Recherchen für Artikel oder eigene Projekte bleibt fast immer etwas an Nebenfunden hängen: ein Video, ein Tool, ein Board, eine absurde Portierung oder ein Bastelprojekt, das man eigentlich nur kurz anklicken wollte – und bei dem man dann doch hängen bleibt. Genau dieses digitale Treibgut sammle ich, weil daraus oft schneller neue Ideen entstehen als aus der eigentlichen Suche.
Hier also wieder ein kleiner Fang der letzten Tage. Vielleicht ist ja auch für euch etwas dabei – und wenn ihr selbst über spannende Tools, Hardware oder Videos gestolpert seid, dann gern in die Kommentare damit.
Wer funktionale Teile druckt, landet früher oder später bei der immer gleichen Frage: Wie bekommt man aus normalem PLA(+) noch ein bisschen mehr Belastbarkeit heraus? Im aktuellen Video von Maker’s Muse geht es im Kontext von Roboter-Kämpfen genau darum. Gezeigt werden nicht etwa exotische Materialien oder Spezialhardware, sondern erstaunlich bodenständige Einstellungen in Orca Slicer 2.3.2 (siehe auch diesen Newsbeitrag [1]). 100 Prozent konzentrisches Infill, versetzte zusätzliche Wände, unterschiedliche Linienbreiten für Außen- und Innenbereiche und die Möglichkeit, den Materialfluss gezielt im Inneren zu erhöhen.
Spannend finde ich daran vor allem, dass hier keine Wunderlösung verkauft wird. Stattdessen zeigt sich wieder einmal, wie viel Mechanik und Materialverhalten schon im Slicer entschieden werden. Gerade bei Haltern, Werkzeugen oder Robotik-Teilen lohnt sich der Blick auf solche Profile oft mehr als der reflexhafte Griff zum nächsten „Engineering Filament“.
Nicht jedes spannende Maker-Thema muss ein neues Dev-Board oder eine Library sein. Manchmal reicht auch ein Video, das einen alten Klassiker einmal anders denkt. Schon der Titel „Pinball like you’ve never seen before.“ reicht aus, um bei mir den Spieltrieb anzuschalten. Hier wird ein Flipper, also eigentlich ein komplettes Baukastensystem, entworfen und gebaut. Am Ende steht aktuell ein Flipper für zwei oder vier Personen, die gegeneinander spielen.
Ich mag solche Projekte: Selbst wenn man nichts 1:1 nachbaut, bleibt fast immer irgendeine Idee hängen – sei es für Antriebe, 3D-Druck, Konstruktion oder einfach für die Frage, wie man aus einem bekannten Prinzip mit etwas Kreativität wieder etwas Neues machen kann. Für Maker ist das oft viel interessanter als das hundertste „hier ist ein neues Board mit noch mehr GPIOs“.
Mit dem ESP32Synth-Projekt zeigt Danilo Gabriel auf Hackaday [4], wie weit man heutige Mikrocontroller auch im Hinblick auf Audio treiben kann. Die Library basiert auf ESP-IDF, läuft bare-metal-nah, ist auf hohe Polyphonie ausgelegt und schafft laut Projekt standardmäßig 80 Stimmen, im Grenzbereich sogar deutlich mehr. Audio läuft über I²S, dazu kommen klassische Wellenformen, Wavetables, SD-Streaming für WAV-Dateien und sogar eigene DSP-Hooks für Effekte oder spezielle Oszillatoren.
Besonders sympathisch ist daran, dass das Projekt (gitHub) nicht nur als Synth-Spielerei daherkommt [5], sondern als echter Bausatz für eigene Instrumente, Soundgeneratoren oder Installationen. Wenn man schon einen ESP32 herumliegen hat, ist das genau die Art von Software, aus der schnell ein Wochenendprojekt wird – und im besten Fall ein sehr lautes.
Ebenfalls schön bunt ist das Video „I Built a Tool to Paint 3D Models with Photos“. Dahinter steckt Primed3D von 3D Revolution [7]: ein freies Open-Source-Werkzeug, das STL- oder 3MF-Modelle im Browser bemalen kann – inklusive Farbverläufen, Flächenfüllung und eben auch Foto-Projektion. Anschließend lässt sich daraus wieder ein 3MF exportieren, wahlweise für „normale“ (unbezahlbare) Mehrfarb-Drucker oder als geditherte Mehrmaterial-Version für FDM-Drucker mit Filamentwechsler.
Gerade für Cosplay, Deko, Figuren oder experimentelle Drucke finde ich das spannend. Denn statt nur einzelne Filamentfarben zuzuweisen, rückt damit die eigentliche Oberflächengestaltung stärker in den Mittelpunkt. Schön ist außerdem, dass das Tool komplett clientseitig laufen soll – die Dateien bleiben also im Browser und wandern nicht erst auf irgendeinen Server.
Es gibt diese Projekte, bei denen man schon beim Titel weiß, dass sie völlig unnötig sind – und genau deshalb großartig. „Booting Mac OSX on a Nintendo Wii“ gehört eindeutig in diese Kategorie. Bryan Keller hat Mac OS X 10.0 Cheetah nativ auf die Nintendo Wii portiert [9]und den Weg dorthin in seinem Blog dokumentiert. Weil die Wii auf einem PowerPC 750CL basiert, also auf einem Verwandten der G3-Prozessoren früher Apple-Rechner, war die Idee technisch nicht komplett abwegig – nur eben trotzdem ziemlich wild. Der YouTuber Action retro musste es natürlich ausprobieren.
Richtig schön wird das Projekt aber erst im Detail: eigener Bootloader, Kernel-Patches, Treiberarbeit, SD-Karten-Boot und als Bonus noch die Korrektur des zunächst magentafarbenen Bildes per Dual-Framebuffer-Konstruktion, weil die Wii intern YUV erwartet, Mac OS X aber RGB haben will. Spätestens an diesem Punkt ist man dann wieder bei der beruhigenden Erkenntnis, dass „läuft irgendwie“ in der Maker-Welt oft schon die halbe Miete ist. Und der Classic Mode … uhhh. Das kenne ich nur von meinem Shapeshifter-Mac-Emulator auf dem Amiga.
Die Cardputer auf ESP32-Basis waren nicht uninteressant, aber man musste viel selbst programmieren, wenn man produktiv werden wollte. M5Stack positioniert den CardputerZero mit Linux [11] als „Pocket Raspberry Pi Computer for Hackers“ und zielt damit klar auf alle, denen ein normaler Mikrocontroller-Handheld nicht mehr reicht. Laut Hersteller soll das Gerät als tragbares Linux-Labor für SSH, Python, Git, Vim, Edge-AI-Anwendungen und Hardware-Basteleien dienen. Erwähnt werden außerdem eine eingebaute App- beziehungsweise Firmware-Verteilung, Erweiterbarkeit über Grove, M5Units sowie Schnittstellen wie SPI, I²C, UART, USB und GPIO. Und ja, die Hardware basiert auf einem auch beim Raspi Zero verbauten Chip.
(Bild: m5stack)
Interessant ist daran hauptsächlich die Richtung: Weg vom reinen Gadget, hin zu einem wirklich mobilen „Arbeitsgerät“ für Leute, die gern direkt am Gerät tippen, testen und schrauben. Wenn M5Stack die Versprechen halbwegs einlöst, könnte das ein ziemlich cooles Werkzeug für Feldtests, Mini-Terminals, Off-Grid-Kommunikation oder einfach für unterwegs „Rumnerden“ werden. Laut M5Stack befindet sich das Projekt derzeit noch in der Vorstartphase; der Kickstarter ist für Mitte bis Ende Mai 2026 angekündigt, mit Early-Bird-Preisen von 59 US-Dollar für die Lite-Version und 89 US-Dollar für die reguläre Variante.
URL dieses Artikels:
https://www.heise.de/-11275610
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: hyper3d.ai)
Mit einem einzigen Handyfoto zur fertigen Figur aus dem 3D-Drucker: Mehrere neue KI-Tools machen aufwändiges 3D-Modellieren für viele Projekte überflüssig.
Jeder Maker, der einen 3D-Drucker besitzt, kennt das Problem. Die Hardware ist längst bezahlbar, aber um eigene Objekte zu drucken, muss man bisher 3D-Modellierung beherrschen. Programme wie Blender, Fusion 360 oder FreeCAD haben steile Lernkurven, verlangen räumliches Denken in Polygonen und Vertices, und selbst nach wochenlanger Einarbeitung gelingen Anfängern selten druckbare Ergebnisse. Deshalb drucken viele Maker nur heruntergeladene Modelle von Thingiverse oder Printables, statt eigene Ideen umzusetzen. Diese Hürde fällt gerade weg. Mehrere KI-Werkzeuge erzeugen inzwischen aus einem einzelnen Foto oder eine, kurzen Prompt dreidimensionale Meshes, die sich direkt als STL oder OBJ exportieren und auf den Drucker schicken lassen.
Konkret sieht das so aus: Man nimmt ein beliebiges Foto, etwa von der eigenen Hauskatze, lädt das Bild in Tripo oder Hunyuan3D Studio hoch und bekommt Sekunden später ein texturiertes 3D-Modell mit Rückseite, Unterseite und allem, was die Kamera nie gesehen hat. Die KI ergänzt die fehlenden Perspektiven plausibel.
Der erste nutzbare Durchbruch in diesem Bereich kam im März 2024, als TripoSR präsentiert wurde [1]. Ein Jahr später, im März 2025, haben wir das Tool Rodin von Hyper3D getestet [2] (hyper3d.ai). Seitdem hat sich das Feld in rasantem Tempo weiterentwickelt. Die Qualität, Geschwindigkeit und Zugänglichkeit dieser Werkzeuge haben sich drastisch verbessert. Inzwischen gibt es ein ganzes Ökosystem an Diensten, die um Nutzer konkurrieren.
Einer der sichtbarsten Player ist Tripo [3], entwickelt vom chinesischen KI-Startup VAST. Auf der GDC (Game Developers Conference) im März 2026 in San Francisco wurde ein Modell vorgestellt, das 3D-Objekte in rund zwei Sekunden erzeugt und ein Ergebnis mit weniger Artefakten liefert. Tripo bedient über 6,5 Millionen Nutzer und bietet ein Freemium-Modell mit begrenztem Kontingent.
Daneben drängen weitere Dienste in den Markt. Meshy, [4] mittlerweile Version 6, richtet sich gezielt an den 3D-Druck, PrintPal [5] hat in seinem ersten Jahr 200.000 Nutzer gewonnen, Hyper3D [6] bietet mit Rodin Gen-2 die Möglichkeit, generierte Modelle gezielt per Textbefehl nachzubearbeiten, und Hitem3D [7] punktet mit einem eigenen Portrait-Modus für personalisierte Büsten und Figuren.
Auf der Open-Source-Seite sticht Tencents Hunyuan3D [8] heraus. Es ist das derzeit leistungsfähigste frei verfügbare Modell und läuft lokal auf dem eigenen Rechner ab einer Grafikkarte mit 12 GB Speicher. Allerdings setzt die Nutzung eine Python-Installation voraus, und Tencents Online-Studio ist nur auf Chinesisch und mit chinesischem Login zugänglich.
Außer PrintPal und Meshy sind alle hier erwähnten Dienstleister chinesische Unternehmen.
Für Maker bleiben allerdings wichtige Einschränkungen. Die generierten Meshes bestehen aus Hunderttausenden Dreiecken ohne saubere Topologie. Für dekorative Figuren, Spielzeug und einfache Ersatzteile funktioniert der Weg vom Foto zum Drucker deshalb schon erstaunlich gut. Aber die Modelle entstehen als Oberflächennetze ohne parametrische Konstruktionslogik — eine Wand ist nicht „2 mm dick“, sondern besteht aus Dreiecken, die nur ungefähr 2 mm Abstand haben.
Zwar lassen sich in Tools wie Meshy reale Maße setzen und die Druckbarkeit direkt prüfen, und bei Hitem3D ist die Optimierung für den Druck von Anfang an eingebaut, aber für wirklich funktionale Bauteile, die exakt auf bestehende Teile passen oder mechanische Belastungen aushalten müssen, bleibt klassische Konstruktionssoftware unverzichtbar.
Für einfachere Bauteile gibt es einen anderen Weg über PrintMakerAI [9]. Hier werden aus einem Prompt keine Meshes, sondern echte parametrische CAD-Körper mit exakten Maßen und garantiert wasserdichter Geometrie erzeugt — allerdings beschränkt auf einfache funktionale Teile wie Halterungen, Gehäuse oder Aufbewahrungsboxen.
(Bild: Printmaker.ai)
URL dieses Artikels:
https://www.heise.de/-11273636
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Framework)
Interessierte können den Framework Laptop 13 Pro vorbestellen. Die Intel-Versionen sind deutlich attraktiver als die AMD-Varianten.
Framework nimmt wie versprochen Vorbestellungen für den Laptop 13 Pro entgegen. Damit stehen jetzt auch alle Konfigurationen und Preise fest. Der offizielle Store hält eine Überraschung bereit: Die Versionen mit Intel-Prozessor sind günstiger und voraussichtlich flotter als die AMD-Typen. Aktuelle Bestellungen will Framework ab Juli ausliefern.
Die sogenannte DIY-Edition ohne Speicher und Betriebssystem ist mit Intels Achtkerner Core Ultra 5 325 [1] ab 1349 Euro erhältlich [2]. Die günstigste AMD-Version mit dem ebenfalls achtkernigen Ryzen AI 7 350 gibt es ab 1579 Euro. Bei einer mittleren Konfigurationliegt die Differenz bei 60 Euro: Für die Variante mit dem 16-Kerner Core Ultra X7 358H ruft der Hersteller 1799 Euro auf, für jene mit dem 12-Kerner Ryzen AI 9 HX 370 sind es 1859 Euro.
Vom Topmodell mit Core Ultra X9 388H ist aus Preis-Leistungs-Sicht abzuraten: Die CPU-Kerne takten etwas höher, dafür kostet die Konfiguration 230 Euro mehr. Aktuell ist sie auch nicht verfügbar.
Die Preise sind nicht der einzige Unterschied zwischen den AMD- und Intel-Notebooks. Framework setzt ausschließlich beim Intel-Mainboard auf ein stromsparendes und schnelles Low Power Compression Attached Memory Module 2 (LPCAMM2) für LPDDR5X-7467-RAM. AMD-Nutzer müssen mit langsamerem DDR5-5600-RAM in SO-DIMM-Bauform vorliebnehmen. Ein LPCAMM2 mit 32 GByte RAM kostet 490 Euro. 32 GByte DDR5 kosten wahlweise 524 Euro auf zwei SO-DIMMs verteilt oder 452 Euro als einzelnes SO-DIMM.
Wie üblich verkauft Framework auch komplette Notebooks mit RAM, SSD und Betriebssystem. Aktuell bietet der Hersteller eine Intel-Konfiguration mit Core Ultra X7 358H, 32 GByte RAM und einer 1 TByte großen PCIe-4.0-SSD an.
Erstmals installiert Framework auf Wunsch ein Linux-Betriebssystem in Form von Ubuntu 24.04 LTS. Damit kostet die Komplett-Konfiguration 2369 Euro. Wer auf Windows 11 Pro besteht, muss 220 Euro Aufpreis zahlen.
Die gewünschten Anschlüsse kommen obendrauf. USB-C für Thunderbolt 4 etwa kostet jeweils 10 Euro. Neu ist ein 10-Gigabit-Ethernet-Adapter für 109 Euro.
Alle DIY- und Komplett-Konfigurationen des Laptop 13 Pro sind derzeit ausschließlich mit schwarzem Gehäuse vorbestellbar. Einzelteile und Nachrüstsätze erscheinen auch mit silberfarbenen Gehäuseteilen [3]; entsprechende Konfigurationen könnten also noch folgen.
Wer einen bisherigen Framework Laptop 13 besitzt, kann künftig die verbesserten Komponenten der Pro-Version [4] nachrüsten. Der Hersteller bietet dazu Einzelteile und Kits an. Der größere Akku erfordert auch die neue Gehäuse-Unterseite und den neuen „Input Cover Frame“. Mainboards mit den Core-Ultra-300-Prozessoren listet Framework noch nicht.
(Bild: Framework)
URL dieses Artikels:
https://www.heise.de/-11268365
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Orange Pi)
Der OrangePi Zero 3W kombiniert Octa-Core-CPU, NPU und Wi-Fi 6 auf kleinem Raum. Das ist spannend für kompakte Maker-Projekte.
Mit dem OrangePi Zero 3W [1] bringt Orange Pi einen neuen Einplatinenrechner heraus, der sich klar an Maker und Embedded-Entwickler richtet.
Im Zentrum arbeitet der Allwinner A733, ein Achtkern-SoC mit zwei Cortex-A76-Kernen (bis 2,0 GHz) und sechs energieeffizienten Cortex-A55-Kernen. Ergänzt wird das Ganze durch eine integrierte NPU mit bis zu 3 TOPS Rechenleistung für KI-Anwendungen sowie einen zusätzlichen RISC-V-Coprozessor für Echtzeitaufgaben. Für Maker bedeutet das: Neben klassischen Linux-Anwendungen lassen sich auch lokale KI-Inferenz oder zeitkritische Steuerungen direkt auf dem Board umsetzen.
Beim Arbeitsspeicher setzt das Board auf LPDDR5 mit bis zu 16 GByte. Beim Speicher zeigt sich das Board flexibel: Neben optionalem eMMC oder UFS-Modulen steht ein microSD-Kartenslot zur Verfügung.
Für die Konnektivität gibt es Wi-Fi 6 und Bluetooth 5.4, optional mit externer Antenne. Damit eignet sich das Board auch für IoT-Anwendungen oder als Edge-Gateway. Dazu kommen klassische Maker-Schnittstellen über eine 40-Pin-GPIO-Leiste mit Unterstützung für SPI, I2C, UART und PWM – also alles, was man für Sensoren, Bildschirme oder Aktoren benötigt.
Interessant ist auch die Videoausgabe: Neben Mini-HDMI (bis 4K@60fps) unterstützt das Board DisplayPort über USB-C sowie MIPI-DSI. Zwei unabhängige Displays lassen sich gleichzeitig ansteuern. Das eröffnet Einsatzmöglichkeiten für kompakte Multimonitor-Setups oder Systeme wie Infoterminals.
Auch für Kamera-Projekte stehen Anschlüsse bereit. Zwei MIPI-CSI-Schnittstellen ermöglichen den Anschluss von Kameramodulen, etwa für Bildverarbeitung oder Überwachungslösungen. In Kombination mit der integrierten NPU lassen sich hier auch KI-gestützte Anwendungen wie Objekterkennung direkt auf dem Gerät realisieren.
Als Betriebssysteme werden unter anderem Debian, Ubuntu, Android und OpenHarmony unterstützt. Zusätzlich nennt der Hersteller Kompatibilität mit gängigen KI-Frameworks wie TensorFlow oder PyTorch. Damit deckt das Board sowohl klassische Bastelprojekte als auch moderne KI-Anwendungen ab – zumindest auf dem Papier. Wie gut die Softwareunterstützung im Alltag wirklich ist, wird sich wie so oft erst zeigen, wenn die Community das Board durch die Mangel gedreht hat.
Mit PCIe 3.0 (über FPC) steht zudem eine schnelle Erweiterungsmöglichkeit bereit, etwa für SSDs oder spezialisierte Module. Das ist in dieser Größenklasse keine Selbstverständlichkeit und könnte für Bastler spannend sein, die mehr als nur Standard-I/O benötigen.
Für Maker ergeben sich daraus einige typische Einsatzszenarien: kompakte Smart-Home-Zentralen, lokale KI-Auswertung von Sensordaten, kleine Server oder auch portable Geräte mit Display. Durch die geringe Größe könnte das Board auch in mobilen Projekten oder selbstgebauten Handhelds landen. Das Board fällt mit seinen Abmessungen von 65 × 32 mm kompakt aus und dürfte damit auch in Projekten Platz finden, bei denen ein Raspberry Pi zu groß ist.
Erhältlich ist das Board auf Amazon für 73,99 US-Dollar [2]. Dort bekommt man auch direkt einen aktiven Kühler mit dazu.
Wer wissen will, was man mit einem Raspberry Pi Zero alles anstellen kann, sollte sich unbedingt unseren Artikel zu Hackinggadgets für die Hosentasche [3] anschauen.
URL dieses Artikels:
https://www.heise.de/-11267955
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: akf / Erzeugt mit Nano Banana durch Make)
Der Slicer spielt eine zentrale Rolle im 3D-Druck-Workflow. OrcaSlicer gewinnt zunehmend an Bedeutung und erweitert seinen Funktionsumfang stetig.
OrcaSlicer veröffentlicht seine Updates üblicherweise in so hoher Frequenz, sodass man sich daran gewöhnt hat, dass nicht immer „Killer-Features“ enthalten sind. In der neuen Version 2.3.2 hat sich jedoch einiges geändert und wurde ergänzt.
Hinweis: Es gibt einige inoffizielle Webseiten, die OrcaSlicer anbieten – die oben verlinkte Seite ist die offizielle Quelle. Lade dir den Installer herunter oder nutze die portable Version, falls du die alte Installation behalten möchtest oder musst.
(Bild: OrcaSlicer)
Mit Multiline-Infill kann man Druckobjekte stabiler machen, wenn man die Wandstärke nicht erhöhen will oder kann. Das Multiline-Infill ist sauberer geworden und weist weniger Überschneidungen auf [4] (dank Clipper2-Bibliothek). Zudem ist es besser mit dem Hauptobjekt verbunden.
Die Flussrate lässt sich jetzt pro Feature statt nur pro Filament einstellen – etwa eine andere Flow-Rate für Infill als für Wände. Die Option findest du unter „Set other flow ratios“ im Quality-Tab.
(Bild: OrcaSlicer)
Das Brim arbeitet nun zuverlässiger mit der „Elephant Foot Compensation“ zusammen. Sich ablösende, kaum nutzbringende Brims gehören damit weitgehend der Vergangenheit an. Elephant-Foot-Compensation verhindert die Überextrusion des ersten Layers auf dem Druckbett. Dieser Faktor wird nun bei der Erzeugung von Brims einberechnet.
(Bild: OrcaSlicer)
Unter Preferences Control Slicing lässt sich „Auto slice after changes“ aktivieren. Die Wartezeit ist anpassbar, sodass man mehrere Änderungen vornehmen kann, bevor der Slicer loslegt. Da ein laufender Slicing-Vorgang aber bei neuen Parametern abgebrochen und neu gestartet wird, ist es auf schnellen Rechnern kaum nötig, den Wert hochzusetzen. Ein Feature, das ich lange vermisst habe, seit ich vom PrusaSlicer gewechselt bin.
Der Drucker-Tab ist jetzt grafischer und übersichtlicher. Der Düsendurchmesser lässt sich jetzt getrennt vom Drucker einstellen.
Statt eigenständiger Kopien (Clones) lassen sich Objekte jetzt auch als „Instances“ vervielfältigen. Ändert man eine Instanz, folgen die anderen automatisch – sei es bei Filament-Zuordnungen für Multifilament-Druck oder anderen Einstellungen. Das spart auch beim Slicing Zeit, da nur eine Instanz berechnet werden muss. Die Anzahl der Instanzen ist einstellbar, oder man füllt direkt das ganze Druckbett.
Zusätzlich werden inzwischen Kollisionen zwischen (besonders Instanzierten Objekten) besser erkannt und so behandelt, dass keine Fehldrucke entstehen.
Für farbige bzw. aus mehreren Filamentsorten zusammengesetzte Drucke auf Materialwechslern und Toolchangern wurden die Wipe-Tower-Verbesserungen aus Bambu Studio zu Orca portiert:
Die Einstellungen müssen in den jeweiligen Druckprofilen aktiviert werden:
FreshRSS Multimaterial -> Prime Tower -> Enable tower interface featuresCool down from interface boost during prime towerDie Art des Wipe Towers lässt sich inzwischen auch direkt im Druckerprofil auswählen.
Wer das Beste aus seinen Druckern und Filamenten herausholen möchte, sollte beides kalibrieren. In Version 2.3.2 sind die Kalibrierungs-Tools jetzt in der richtigen Reihenfolge im Menü sortiert. Außerdem werden die Firmwares für Input Shaper, Cornering/Jerk erkannt und entsprechend ausgewählt.
Im Drucker-Konfigurator werden nun zusätzliche Materialwechsel-Einheiten und Toolheads unterstützt. Diese lassen sich direkt aus dem Slicer steuern, und die Filamentbelegung der Toolheads ist interaktiv anpassbar. Dies ist noch als experimentell markiert, da es sich teilweise um schlecht dokumentierte Hardware handelt und die Hersteller natürlich eher ihr Ökosystem unterstützen.
Orca 2.3.2 unterstützt jetzt auch die neueren Bambu-Lab-Modelle wie H2D (Pro) und H2S. Außerdem gibt es weitere spezielle Verbesserungen für Bambulab-Nutzer.
Viele zusätzliche Änderungen und Verbesserungen mit Beispielbildern findet man im ausführlichen Changelog: OrcaSlicer 2.3.2 Beta Changelog [6]
In der Make 1/26 hatten wir einen ausführlichen Artikel über Tipps&Tricks für Slicer [7] und einen Artikel über Orca Slicer [8] und warum er immer beliebter wird.
URL dieses Artikels:
https://www.heise.de/-11265708
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Die Buchstaben AI umfliegen Haken und Warndreiecke.
(Bild: tadamichi/Shutterstock.com)
Ein neues Tool berechnet den CO₂-Ausstoß von Claude-Code-Sessions. Laut dem Autor hat sich dabei gezeigt, wie man ihn um bis zu 70% senken kann.
Um die Umweltkosten durch die tägliche Nutzung von Claude Code greifbar zu machen, hat ein Entwickler ein Werkzeug gebaut, das den CO₂-Ausstoß für jede Sitzung berechnet und in Echtzeit in der Statuszeile anzeigt.
Der Programmierer arbeitet nach eigenen Angaben als Wirtschaftsberater, spezialisiert auf die Berechnung von Treibhausgasemissionen für große Unternehmen. Bei seiner täglichen Arbeit mit Claude Code kam ihm irgendwann sein eigener sorgloser Umgang mit generativer KI zuwiderlaufend vor.
Seine Antwort ist Claude-Carbon [1], ein auf Bash und SQLite basierendes Tool, das sich nahtlos in die Claude-Code-Umgebung integriert und die CO₂-Emissionen pro Sitzung in der Statuszeile neben den Kosten anzeigt.
(Bild: Claude-Carbon)
Über vier Monate und 367 Sessions hinweg maß der Entwickler etwa 215 kg CO₂-Äquivalente – was er auf ungefähr eine Tonne pro Jahr hochgerechnet hat. Das entspricht einem Hin- und Rückflug zwischen Paris und New York, allein durch die tägliche Nutzung von KI-Code-Tools verursacht, schreibt er in einem Blogpost. [2]
Die Berechnung beschränkt sich dabei auf die sogenannte Inferenz, also die Energie, die in Rechenzentren verbraucht wird, wenn das Modell die Prompts verarbeitet und Antworten bereitstellt. Training, Hardware-Herstellung, Kühlung und Rechenzentren-Konstruktion sind nicht inbegriffen – der echte Lebenszyklus-Fußabdruck ist also noch höher.
Claude-Carbon unterscheidet sich grundlegend von bestehenden Werkzeugen wie CodeCarbon [3]oder EcoLogits. Während CodeCarbon lokale Hardware-Ressourcen misst und sich nicht für Remote-API-Calls eignet, und EcoLogits als generische Python-Bibliothek fungiert, die API-Responses verschiedenster Anbieter abfängt, ist Claude-Carbon speziell für Claude Code entwickelt worden. Das Tool nutzt native Hooks und Settings der Claude-Code-Umgebung selbst. Es speichert alle Daten lokal in einer SQLite-Datenbank, kann historische Sessions nachträglich analysieren und generiert sogar PNG-Reportkarten für Social Media.
(Bild: codecarbon.io)
Der Autor betont, dass die Werte Schätzungen sind und keine präzisen Messungen. Anthropic veröffentlicht nämlich keine modellspezifischen Energiedaten. Die Faktoren für Sonnet stammen aus einer 2025er Studie (Jegham et al.) [4] über LLM-Inference-Energieverbrauch. Die Werte für Opus und Haiku sind Extrapolationen. Opus wird mit dem Faktor 3× Sonnet berechnet, Haiku mit 0,5× Sonnet.
Auch die CO₂-Intensität basiert auf US-Durchschnittswerten, nicht auf echten regionalen oder tageszeit-spezifischen Daten. Trotz dieser Unsicherheiten ist das Tool wertvoll für ein Größenordnungs-Bewusstsein – nur eben nicht für formale Treibhausgasbilanzen, so der Autor.
Durch die eigene Nutzung des Tools hat der Entwickler einige Einsichten gewonnen, wie sich der Verbrauch ohne Effizienzverlust senken lässt. Der größte Hebel zur Reduktion liegt in der Modellwahl. Opus verbraucht etwa dreimal so viele Token wie Sonnet, Haiku könnte gegenüber Sonnet bis zu 80 Prozent einsparen. Für Aufgaben wie File-Exploration oder Code-Review lohnt sich daher Haiku. Darüber hinaus können Werkzeuge wie RTK (Rust Token Killer) 60–90 Prozent der CLI-Token-Ausgabe herausfiltern, ohne dass die Qualität leidet.
Weiter lässt sich Thinking-Tokens auf 10.000 pro Message deckeln, was eine Reduktion um etwa 70 Prozent ermöglicht. Früheres Context-Compacting bei 50 statt 95 Prozent Auslastung hält Sessions schlanker.
Insgesamt lassen sich durch diese Maßnahmen die Emissionen von Claude-Code-Sessions um 50–70 Prozent reduzieren – von rund einer Tonne CO₂ pro Jahr auf 0,3–0,5 Tonnen.
Der Ersteller betont zudem, dass das Tool ein fundamentales Problem in den Fokus rückt: Anthropic veröffentlicht keine modellspezifischen Energiedaten. Google hatte im August 2025 als erster großer KI-Anbieter Per-Prompt-Daten für sein Gemini-Modell offengelegt [5] (0,24 Wh, 0,03 Gramm CO₂ pro Median-Anfrage). Anthropic – ebenso wie OpenAI – hält sich weiterhin bedeckt. Diese Transparenzlücke zu schließen, argumentiert er, wäre ein wichtiger Schritt, um KI-Nutzung wirklich nachhaltig zu gestalten.
Claude-Carbon [6] ist open source und läuft auf macOS ohne zusätzliche Installation.
URL dieses Artikels:
https://www.heise.de/-11264352
Links in diesem Artikel:
[1] https://github.com/gwittebolle/claude-carbon
[2] https://dev.to/gwittebolle/how-i-measured-1-tonne-of-co2-from-my-ai-coding-sessions-3b3d
[3] https://codecarbon.io/#about
[4] http://arxiv.org/abs/2505.09598
[5] https://cloud.google.com/blog/products/infrastructure/measuring-the-environmental-impact-of-ai-inference?hl=en
[6] https://github.com/gwittebolle/claude-carbon
[7] mailto:mch@make-magazin.de
Copyright © 2026 Heise Medien
(Bild: Waveshare)
Mit integriertem Display und Tastatur wird der Raspberry Pi zum mobilen Linux-Terminal für Maker.
Mit dem PocketTerm35 bringt Waveshare ein tragbares Linux-Terminal auf den Markt, das für den Einsatz mit dem Raspberry Pi 4 Model B und dem Raspberry Pi 5 vorgesehen ist. Das Gerät kombiniert Display, Tastatur und Stromversorgung.
Die Abmessungen des Handhelds betragen 93,5 × 168,5 × 37 mm. Verbaut ist ein 3,5-Zoll-IPS-Touchdisplay mit einer Auflösung von 640 × 480 Pixeln. Ergänzt wird das Display durch eine 67-Tasten-QWERTY-Tastatur (QWERTY entspricht dem US-Layout, deutsche Tastaturen haben ein „QWERTZ“-Layout. Umlaute fehlen und Satzzeichen sind anders verteilt) aus Silikon. Das reicht für Terminalbefehle, kleinere Code-Anpassungen oder das schnelle Editieren von Konfigurationsdateien. Wer längere Texte schreiben will, wird trotzdem vermutlich irgendwann wieder zur „großen“ Tastatur greifen (oder zumindest hoffen, dass die Autokorrektur gut funktioniert).
Im Inneren arbeitet ein Raspberry Pi – je nach Variante entweder ein Pi 4B mit 2 GB RAM oder ein Pi 5 mit 1 GB RAM. Alternativ gibt es auch Bausätze ohne Board, bei denen man dann den eigenen Pi 5 mit 16 GB RAM aus dem Tresor holen kann. Für die Steuerung von Peripherie wie Tastatur, Helligkeit oder Lautstärke ist zusätzlich ein RP2040-Mikrocontroller integriert. Das ist ein interessanter Ansatz, da sich so Eingaben und Systemfunktionen unabhängig vom Hauptsystem regeln lassen.
Das Gerät versteht sich als vollwertiges Linux-Terminal. Über HDMI wird das Display angebunden, während Touch-Eingaben per I2C laufen. Für Audio steht ein integrierter 2-Watt-Lautsprecher zur Verfügung, zusätzlich gibt es einen 3,5-mm-Klinkenanschluss. Die Stromversorgung erfolgt über USB-C oder eine optionale 5000-mAh-Lithiumbatterie. Dank integriertem UPS-Management kann das System nahtlos zwischen externer Stromquelle und Akku wechseln.
Für Maker ergeben sich daraus einige konkrete Einsatzszenarien. Das PocketTerm35 eignet sich etwa als mobiles Terminal für Headless-Systeme: Statt Laptop und Adapter mitzuschleppen, kann man direkt am Gerät auf einen Raspberry Pi zugreifen, Logs prüfen oder Dienste starten. Auch für IoT-Projekte lässt sich das Gerät als Steuer- und Diagnoseeinheit verwenden, etwa um Sensorwerte auszulesen oder Aktoren zu konfigurieren.
Neben klassischen Terminal-Anwendungen unterstützt das Gerät auch grafische Oberflächen sowie Systeme wie RetroPie. Damit lässt sich das PocketTerm35 theoretisch auch als Retro-Handheld verwenden.
Die Konstruktion kombiniert eine CNC-gefräste Aluminium-Front mit einer Kunststoffrückseite. Verschiedene Schnittstellen und Adapter liegen je nach Variante bei, darunter HDMI-Kabel, Montageplatten und Verbindungskabel für den Raspberry Pi.
Unterm Strich positioniert sich das PocketTerm35 zwischen Bastelprojekt und fertigem Werkzeug. Es ersetzt keinen Laptop, kann aber in vielen Situationen ein praktischer Begleiter sein. Vor allem dort, wo Platz, Gewicht oder Aufbauzeit eine Rolle spielen.
Erhältlich ist der Handheld im Waveshare-Shop [1] für 179,99 US-Dollar in der Pi-4-Variante und 148,99 in der Pi-5-Version. Die Bare-Bones-Versionen sind noch nicht erhältlich.
Wer bei der Erwähnung von RetroPie aufgehorcht hat, findet mit unserem DIY-Arcade auf Raspberry-Pi-Basis [2] vielleicht ein neues tolles Projekt.
URL dieses Artikels:
https://www.heise.de/-11259004
Links in diesem Artikel:
[1] https://www.waveshare.com/pocketterm35.htm?sku=34462
[2] https://www.youtube.com/watch?v=oSNMRQo8NTM
[3] https://www.heise.de/make
[4] mailto:das@heise.de
Copyright © 2026 Heise Medien
This is a release focussing on bug fixing, in particular regressions from the release 1.28.0.
Selected new features ✨:
Improved performance 🏎️:
Many bug fixes 🐛
This release has been made by @Alkarex, @Frenzie, @Inverle and newcomers @ciro-mota, @eveiscoull, @hackerman70000, @Hufschmidt, @johan456789, @martgnz, @mmeier86, @netsho, @neuhaus, @RobLoach, @rupakbajgain.
Full changelog:
transliterator_transliterate fallback (when the php-intl extension is unavailable) #8427lastUserModified database column also during mark-as-read action #8346session.cookie-lifetime #8446CURLOPT_ACCEPT_ENCODING #8376, simplepie#960, simplepie#962<template> element #8443.gitignore to ignore installed extensions #8372
