FreshRSS

🔒
✇ Golem.de Full über fivefilters.org

Segmentierungen und Fiber Deep: Vodafone flickt sein Kabelnetz weiter unter Docsis 3.1

Von Achim Sawall — 28. April 2026 um 19:06
Vodafone setzt weiter darauf, sein Koaxialnetz am Leben zu erhalten. Große Investitionen in Docsis 4.0 bleiben aus.
Modernes Koaxialkabel vom chinesischen Messgerätehersteller Noyafa Technology (Bild: Noyafa Technology)
Modernes Koaxialkabel vom chinesischen Messgerätehersteller Noyafa Technology Bild: Noyafa Technology

Vodafone muss sein Kabelnetz weiter segmentieren, um den wachsenden Bedarf der Kunden decken zu können. Wie der Konzern am 28. April 2026 bekanntgab , wurden im vergangenen Monat 260 Segmentierungen und 58 Fiber-Deep-Projekte in 124 Städten durchgeführt.

Rein rechnerisch hingen bei Vodafone laut Angaben vom Januar 2023 noch 500 Haushalte an einem Node und teilten sich die Gesamtkapazität von 1 GBit/s. In Stoßzeiten wie in den Abendstunden können Kabelkunden darum deutliche Netzbeeinträchtigungen spüren.

Besonders viele Maßnahmen waren in Hamburg, Düsseldorf, Wuppertal, Krefeld, München und Nürnberg nötig. Rund 78.000 Haushalte hätten so eine stabilere Versorgung erhalten, erklärte Vodafone.

In einem Segment teilen sich alle die Datenrate

Im Geschäftsjahr 2025/26 führte Vodafone insgesamt 2.438 Netzmodernisierungen durch, darunter 2.168 Segmentierungen und 270 Fiber-Deep-Maßnahmen. Das Vodafone Geschäftsjahr 2025/26 begann am 1. April 2025 und endete am 31. März 2026.

Das Kabelnetz von Vodafone ist in einzelne Versorgungsbereiche (Segmente) aufgeteilt. Reicht die Kapazität eines Segments nicht mehr aus, müssen Techniker diesen Bereich irgendwann aufteilen. Dafür werden bestehende Verstärker modernisiert, zusätzliche Glasfaser-Knotenpunkte errichtet und per Glasfaser angebunden.

Mit Fiber Deep führt Vodafone neue Glasfaserkabel näher an die Wohnungen der Kunden heran. Dazu sollen insbesondere Verstärkerpunkte mit neuen Glasfaserstrecken angeschlossen und in Glasfaserknoten umgewandelt werden. Die verbleibenden Strecken über Koaxialkabel werden verkürzt oder teilweise durch Glasfaser ersetzt.

Während in den USA bereits der Kabelnetzstandard Docsis 4.0 etwa bei Comcast und Mediacom Communications läuft, um bestehende HFC-Infrastrukturen vor allem in suburbanen und ländlichen Gebieten weiter nutzen zu können, zeichnet sich in Deutschland ein anderer Weg ab. In den USA hängt das Kabelnetz jedoch an Masten, was den Ausbau erleichtert.

Der Übergang des Kabelnetzstandards Docsis 3.1 auf Docsis 4.0 sei kein einfaches Software-Upgrade, sondern erfordere in Deutschland umfangreiche Anpassungen entlang der gesamten Signalstrecke – von der Kopfstelle bis zur Anschlussdose in der Wohnung, sagte ein Topmanager Golem im Oktober 2025 .

Zumindest bis zum letzten Verstärker

"Docsis 4.0 setzt in der Regel voraus, dass die Glasfaser näher an die Endkunden herangeführt wird, etwa in den Keller oder zumindest bis zum letzten Verstärker. Das erfordert zusätzliche Glasfaseranbindungen, teilweise auch Tiefbauarbeiten" , sagte er.

Docsis 4.0 nutzt ein deutlich erweitertes Frequenzspektrum – bis zu 1,8 GHz für Full Duplex – gegenüber maximal 1,2 GHz bei Docsis 3.1. Um diese Bandbreite nutzbar zu machen, müssten Verstärker, Abzweiger, teilweise das Koaxialkabel und sogar die Kabeldosen in den Wohnungen ertüchtigt oder ersetzt werden. Auch die aktiven Komponenten in den Kopfstellen (CMTS) seien mit Docsis 4.0 nicht per Software aufrüstbar und müssten neu beschafft werden. "Auf Kundenseite ist ein kompletter Austausch der Kabelmodems oder Router erforderlich" , erklärte der Branchenexperte.

Die notwendige Modernisierung der passiven und aktiven Infrastruktur bedeute für die Kabelnetzbetreiber wie Vodafone oder Tele Columbus erhebliche Investitionen. Die Branchenorganisation Cablelabs hatte bei einem Docsis-4.0-Interoperabilitätstest Downstream-Datenraten von 14 GBit/s gemessen. Dabei wurden Docsis-4.0-fähige Kabelmodems von zehn verschiedenen Anbietern getestet.

Adblock test (Why?)

✇ Golem.de Full über fivefilters.org

Anzeige: Wago-Klemmen mit Hebel bei Amazon günstiger geworden

Von Benjamin Gründken — 28. April 2026 um 18:50
Bei Amazon sind Wago-Klemmen mit Hebel günstiger als dort im Schnitt der letzten Wochen. Sie eignen sich für verschiedene Leitersorten.
Wago-Klemmen mit Hebel nehmen auch flexible Leiter auf. (Bild: Erzeugt mit ChatGPT; Amazon, Wago; Montage: Golem.de) amazon Affiliate

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.

Wago-Klemmen mit Hebel nehmen auch flexible Leiter auf. Bild: Erzeugt mit ChatGPT; Amazon, Wago; Montage: Golem.de

Wago-Klemmen gehören seit Jahren zur Standardausrüstung in der Elektroinstallation. Sie ermöglichen eine schnelle, sichere und werkzeuglose Verbindung von Leitern. Beliebt sind auch die Modelle mit Hebel. Der integrierte Hebelmechanismus sorgt nämlich dafür, dass sich Leiter einfach einführen, lösen und wiederverwenden lassen. Sie nehmen zudem auch flexible und nicht nur starre Leiter auf.

Wichtig ist dabei natürlich: Arbeiten an elektrischen Anlagen sollten grundsätzlich Fachkräften vorbehalten bleiben. Nur geschulte Profis können die sichere Anwendung und normgerechte Installation gewährleisten. So verlangt es auch die Niederspannungsordnung.

Was bietet die 221-413er?

Die Verbindungsklemmen 221-413 sind für bis zu drei Leiter ausgelegt und unterstützen Kabelquerschnitte bis 4 mm², wobei sich durch das transparente Gehäuse die korrekte Position der Leiter visuell überprüfen lassen soll.

Der Hebelmechanismus erlaubt die Verwendung unterschiedlicher Leiterarten: von feindrähtigen bis hin zu massiven Leitern. Das ins Auge fallende Set enthält insgesamt 50 Klemmen.

Preisentwicklung und aktuelles Angebot

Aktuell werden die Klemmen bei Amazon für 14,99 Euro angeboten. Gegenüber der hinterlegten unverbindlichen Preisempfehlung von 20 Euro entspricht das einer Ersparnis von rund 25 Prozent. Gleichzeitig liegt der Preis laut Keepa unter dem 90-Tage-Durchschnitt: Mit Verkauf und Versand über Amazon waren es 17,08 Euro. Laut Golem-Preisvergleich, powered by Geizhals, handelt es sich um den aktuell besten Preis unter den gelisteten Shops. Globus Baumarkt spiegelt diesen Kurs allerdings.

WAGO Verbindungsklemmen 221-413

Zum Angebot

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.

Auf der gemeinsamen Produktseite

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
findet man noch viele weitere Varianten, etwa für fünf Leiter. Auch die 2273er gibt es bei Amazon
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
. Pro Klemme zahlt man hier weniger als bei den Modellen mit Hebeln. Sie kann aber nur starre Leiter aufnehmen.

Adblock test (Why?)

✇ Golem.de Full über fivefilters.org

Anzeige: Curved Gaming Monitor mit 34 Zoll und 240 Hz unter 240 Euro

Von Erik Körner — 28. April 2026 um 18:19
Ein 34 Zoll großer Curved Gaming Monitor von Amzfast ist bei Amazon zum niedrigsten Preis seit Wochen im Angebot.
Der 34 Zoll große Curved Gaming Monitor von Amzfast zum Sparpreis im Amazon-Angebot (Bild: Amazon.de/Amzfast/Golem) amazon Affiliate

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.

Der 34 Zoll große Curved Gaming Monitor von Amzfast zum Sparpreis im Amazon-Angebot Bild: Amazon.de/Amzfast/Golem

Ob für komfortableres Multitasking oder immersives Spielen: Ultratwide-Monitore bieten einige Vorzüge gegenüber herkömmlichen Einzel- und Dual-Monitor-Setups. Ein 34 Zoll großes Gaming-Modell mit Curved-Bildschirm von Amzfast ist im Amazon-Angebot zum niedrigsten Preis seit Wochen für unter 240 Euro im Angebot. Günstiger war es nur einmal: diesen Februar, und auch nur um knapp 2 Euro. Der Deal läuft bis spätestens zum 10. Mai.

Das bietet der Curved Gaming Monitor von Amzfast

Amzfasts Curved Gaming Monitor hat ein flimmerfreies VA-Panel mit einem 21:9-Seitenverhältnis und einer mittelstarken 1500-R-Krümmung. Der Bildschirm stellt Inhalte in bis zu WQHD-Auflösung (3.440 mal 1.440 Pixel) und einer hohen 240-Hz-Bildwiederholrate dar. Dank Adaptive-Sync-Unterstützung kann er seine Bildwiederholrate automatisch an die Framerate des Spiels anpassen, was Tearing vorbeugt. Der Hersteller gibt eine eine Reaktionszeit von 1 ms (MPRT). Eine matte Beschichtung minimiert Reflexionen bei starkem Lichteinfall.

Der Curved Gaming Monitor von Amzfast deckt einen Farbraum von 130 Prozent sRGB beziehungsweise 98 Prozent DCI-P3 ab. Der Kontrastwert beträgt 3.000:1. Auch unterstützt er HDR-Darstellung. Die ist vor allem im Budget-Bereich und bei LCD-Monitoren erfahrungsgemäß eher dürftig und keine Konkurrenz für optimale HDR-Bilder, wie man sie von OLED-Bildschirmen kennt – die dafür entsprechend teuer sind.

Im Menü des Curved Gaming Monitor von Amzfast kann man aus fünf voreingestellten Bildmodi wählen: Gaming, Film, Büro, Standard und Energiesparmodus. Sie passen die Farben und Helligkeit automatisch für den jeweiligen Use Case an. Auf Wunsch lässt sich ein augenschonender Blaulichtfilter zuschalten. Praktisch: Der Monitor unterstützt Bild-im-Bild- und Bild-neben-Bild-Darstellung für einfacheres Multitasking.

Der Curved Gaming Monitor von Amzfast misst 807 mal 440 mal 190 mm mit dem mitgelieferten Ständer. Er lässt sich 5 Grad nach vorn und 15 Grad nach hinten neigen. 75-mal-75-Vesa-Löcher auf der Rückseite erlauben die Montage an Monitorarmen. Zur Verbindung mit PCs oder Konsolen sind je zwei HDMI-2.1- und Displayport-1.4-Anschlüsse verbaut. Kopfhörer und Lautsprecher können via 3,5-mm-Buchse angeschlossen werden; eingebaute Lautsprecher hat der Monitor nicht. An der oft dürftigen Soundqualität integrierter Speaker gemessen, ist das jedoch kein Verlust. Ein 1,5 m langes Displayport-Kabel ist im Lieferumfang enthalten.

Amzfast bei Amazon: Großen Curved Gaming Monitor jetzt zum Sparpreis sichern

Amazon verkauft den 34 Zoll großen Curved Gaming Monitor

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
von Amzfast für 239,99 Euro. Laut Preistracker Keepa hat man in den letzten Wochen im Schnitt 259,99 Euro gezahlt. Mehr reduzierte Gaming-Monitore im Ultra-Wide- und Standard-Format findet man im Amazon-Store
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
des Herstellers, schon ab knapp 133 Euro.

Amzfast 34 Zoll Curved Gaming Monitor

Jetzt für unter 240 Euro bestellen

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.

Adblock test (Why?)

✇ iMonitor Internetstörungen

Störungsmeldung vom 28.04.2026 16:00

Von heise online — 28. April 2026 um 16:00

Neue Störungsmeldung für Provider Vodafone DSL

Details

Beginn
28.04.2026 16:00
Region
Moosburg (a d Isar) (08761)
Provider
Vodafone DSL
Zugangsart
VDSL

Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden

✇ Mac & i ff.org

App Store: Apple führt Monatsabos mit Jahresbindung ein

Von Heise — 28. April 2026 um 15:27
Die neuen Abo-Optionen auf dem iPhone

Apple bietet künftig eine neue monatliche Abo-Option für App-Entwickler an, bei der sich Abonnenten ein Jahr lang an das Angebot binden.

(Bild: Apple)

Entwickler können im App Store bald Monatsabos mit Jahresbindung anbieten. Die Option gilt weltweit – außer in den USA und Singapur.

Apple hat eine neue Abrechnungsoption für automatisch verlängerbare Abonnements im App Store [1] eingeführt. Entwickler können ihren Nutzern künftig monatliche Zahlungen mit einer verbindlichen Laufzeit von zwölf Monaten anbieten – quasi eine Ratenzahlung für Jahresabos zu einem vergünstigten Monatspreis. Und das Herunterbrechen in Monatsraten dürfte Jahresabos insgesamt attraktiver erscheinen lassen. Entwickler erhalten indessen mehr Planungssicherheit, wenn sich Nutzer für ein Jahr binden.

Wie Apple in seinen Developer News [2] mitteilt, lässt sich die neue Option ab sofort in App Store Connect konfigurieren und in Xcode testen. Live geschaltet wird sie mit den kommenden Betriebssystemversionen iOS 26.5, iPadOS 26.5, macOS Tahoe 26.5, tvOS 26.5 und visionOS 26.5, die Apple für Mai 2026 angekündigt hat. Auffällig: Die USA und Singapur sind von der neuen Abo-Variante ausgenommen. Apple nennt keine Gründe für den Ausschluss – denkbar sind regulatorische Besonderheiten oder marktspezifische Erwägungen. Für Entwickler, die Abonnements anbieten, hat Apple zuletzt auch den Analytics-Bereich in App Store Connect massiv ausgebaut: Mit über 100 neuen Metriken für In-App-Käufe und Abonnements [3] lassen sich etwa Kohorten-Analysen und Conversion-Daten auswerten.

Konfiguration in App Store Connect

Technisch müssen Entwickler in App Store Connect eine Subscription Group anlegen und darin ein Abo-Produkt mit der Laufzeit „1 year“ erstellen. Außerhalb der USA und Singapurs aktiviert das System dann automatisch die Option zur monatlichen Abrechnung mit Jahresbindung. Entwickler können Preise pro Land festlegen, die Verfügbarkeit steuern und über sogenannte Levels Upgrades sowie Downgrades zwischen verschiedenen Abo-Stufen ermöglichen. Apple verweist auf die ausführliche Dokumentation zu Abonnements [4] sowie die StoreKit-APIs zur Integration in Apps.

Bestehende Jahresabonnements bleiben von der Neuerung unberührt. Die neue Option ergänzt das bisherige Angebot – Entwickler behalten die volle Kontrolle darüber, welche Abo-Varianten sie anbieten möchten.

Transparenz für Nutzer, Vorteile für Entwickler

Für Abonnenten verspricht Apple Transparenz: In den Kontoeinstellungen sollen abgeschlossene und verbleibende Zahlungen einsehbar sein. Vor einer Verlängerung nach Ablauf der zwölf Monate verschickt Apple E-Mails und Push-Benachrichtigungen. Eine Kündigung ist jederzeit möglich – das Abo verlängert sich dann nach den zwölf Monaten nicht weiter. Hinsichtlich europäischer Verbraucherrechte dürfte die Konstruktion mit der EU-Verbraucherrechterichtlinie vereinbar sein: Die Kündigung bleibt unkompliziert und das 14-tägige Widerrufsrecht gilt weiterhin.

Für Entwickler – gerade auf preissensiblen Märkten wie Deutschland – senkt das Modell die Einstiegshürde: Statt einer großen Einmalzahlung für ein Jahresabo sehen Nutzer überschaubare Monatsbeträge. Das kann die Conversion-Rate erhöhen und die Abwanderung reduzieren. Parallel dazu weitet Apple im App Store auch die Werbemöglichkeiten aus: Ab 2026 erscheinen mehr Anzeigen in den Suchergebnissen [5], was Entwicklern zusätzliche Wege bietet, ihre Apps bekannt zu machen. Bei den Erlösen gilt Apples übliches Modell: 70 Prozent im ersten Jahr, danach 85 Prozent – Teilnehmer am Small Business Program erhalten von Beginn an 85 Prozent.

Vergleich mit Google Play

Google bietet im Play Store mit Zahlungsplänen ein ähnliches Konzept an, bei dem Nutzer rabattierte Monatsraten zahlen. Eine exakte Entsprechung zur 12-monatigen Bindung mit monatlicher Abrechnung gibt es dort allerdings nicht.


URL dieses Artikels:
https://www.heise.de/-11275298

Links in diesem Artikel:

  1. https://www.heise.de/thema/App-Store
  2. https://developer.apple.com/news/?id=agq42lxe
  3. https://www.heise.de/news/Apple-gibt-Entwicklern-mehr-Analytics-Daten-an-die-Hand-11224539.html
  4. https://developer.apple.com/app-store/subscriptions/
  5. https://www.heise.de/news/Apple-weitet-App-Store-Werbung-2026-aus-mehr-Anzeigen-in-Suchergebnissen-11119390.html
  6. https://www.heise.de/mac-and-i
  7. mailto:mki@heise.de

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ Mac & i ff.org

OWC Express 4M2 Ultra: Thunderbolt-5-Gehäuse für vier SSDs

Von Heise — 28. April 2026 um 14:50
Ein SSD-Gehäuse steht neben einem Mac auf einem Schreibtisch

(Bild: OWC)

Das Express 4M2 Ultra nimmt vier M.2-SSDs auf und verbindet sich per Thunderbolt mit einem PC oder Mac.

OWC legt eine Ultra-Version des SSD-Gehäuses Express 4M2 auf. Auch in das Express 4M2 Ultra passen vier M.2-SSDs mit einer Länge von bis zu 80 mm, was für 32 TByte Datenspeicher reicht. Die Ultra-Version nutzt einen neueren Thunderbolt-5-Controller, sodass die bisherige Übersetzung von USB zu PCI Express 4.0 wegfällt.

Im Gehäuse sitzt Intels Thunderbolt-5-Controller JHL9480 alias Barlow Ridge [1], der vier PCIe-4.0-Lanes auf vier M.2-Steckplätze verteilt. Das frühere Modell Express 4M2 kam noch mit einem Asmedia-Brückenchip (ASM2464PDX) [2], der die Datensignale von USB4 beziehungsweise Thunderbolt 4 zu PCIe 4.0 x4 übersetzte.

Die Übersetzung war notwendig, da die integrierten PCIe-3.0-Lanes bei USB4 und Thunderbolt 4 nur die halbe Geschwindigkeit schaffen. Erst Thunderbolt 5 [3] und die verwandte, aber bislang seltene USB4-Version 2.0 bringen den Wechsel auf PCIe 4.0.

Erst im RAID richtig flott

Da jeder M.2-Steckplatz im Express 4M2 Ultra fest verdrahtet ist, steht den SSDs nur jeweils eine PCIe-4.0-Lane zur Verfügung. Daher können die SSDs jeweils lediglich mit maximal 1,6 GByte/s lesen und schreiben. Erst mit einem RAID-Verbund, der alle SSDs gleichzeitig anspricht, sind laut OWC 6,6 GByte/s drin. An Thunderbolt 4 und USB3 sollte das Gehäuse auch funktionieren, dann aber mit halber Geschwindigkeit.

Offenes SSD-Gehäuse
Offenes SSD-Gehäuse

Die SSDs verteilen sich im OWC Express 4M2 Ultra auf zwei Ebenen.

(Bild: OWC)

Auf einen RAID-Controller verzichtet der Hersteller. RAID-Konfigurationen lassen sich über die eigene Software SoftRAID einrichten, die allerdings extra kostet. Ohne RAID verhalten sich die SSDs wie ein „Haufen Datenträger“ (Just a Bunch of Disks, JBOD).

Das Gehäuse besteht aus Aluminium und wiegt etwa 900 Gramm. Ein 40-mm-Lüfter springt ab 35 Grad Celsius Innentemperatur an. Mit 1600 bis 4000 Umdrehungen pro Minute, je nach Temperatur, könnte sich der Lüfter durchaus bemerkbar machen.

Gerätekopplung per Daisy-Chain

Über einen Thunderbolt-5-Ausgang lässt sich weitere Peripherie anschließen. Insgesamt sechs Express 4M2 Ultra sollen aneinandergekoppelt funktionieren, was allerdings nur die Kapazität und nicht die Geschwindigkeit erhöht. Alternativ können Interessierte andere USB-Geräte oder eine Dockingstation anschließen.

OWC verlangt für ein Express 4M2 Ultra [4] ohne Software-RAID-Support 400 US-Dollar, was rund 410 Euro inklusive Mehrwertsteuer (in US-Preisen nicht enthalten) entspricht. Software-RAID-Support kostet 150 US-Dollar Aufpreis. Die Auslieferung soll im dritten Quartal 2026 beginnen, also spätestens im September. Das bisherige Express 4M2 ist deutlich günstiger im Handel erhältlich.


URL dieses Artikels:
https://www.heise.de/-11275285

Links in diesem Artikel:

  1. https://www.intel.de/content/www/de/de/products/sku/225919/intel-jhl9480-thunderbolt-5-accessory-controller/specifications.html
  2. https://www.asmedia.com.tw/product/bDFzXa0ip1YI7Wj1/C64ZX59yu4sY1GW5.html
  3. https://www.heise.de/news/Thunderbolt-5-Das-bessere-USB4-Version-2-0-jetzt-offiziell-9302431.html
  4. https://www.owc.com/solutions/express-4m2-ultra?sku=OWCTB5ULT4M2
  5. https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
  6. https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
  7. mailto:mma@heise.de

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ Mac & i ff.org

AirPods mit Android-Geräten nutzen: LibrePods-App landet im Play Store

Von Heise — 28. April 2026 um 14:31

(Bild: Ivan_Shenets/Shutterstock.com)

Die App LibrePods ermöglicht die Nutzung zahlreicher AirPods-Funktionen auf Android-Geräten ohne Root. Voraussetzung: Android 16 QPR3 oder Oxygen/ColorOS 16.

Die Android-App LibrePods ist im Play Store gelandet. Bei dieser handelt es sich um eine Anwendung, mit der sich die meisten AirPods-Pro- und Max-Funktionen auch auf Android-Geräten nutzen lassen. Jedoch gibt es derzeit noch gewisse Einschränkungen.

Ab Android 16 QPR3 ohne Root

Die Open-Source-App LibrePods für Android des Entwicklers Kavish Devar war bis vor wenigen Tagen nur über Github verfügbar und erforderte Rootrechte [1], um die Funktionsweise bestimmter Bluetooth-Komponenten anzupassen. Das hat sich mit dem neuesten Release und dank der Arbeit Googles am fehlerhaften Android-Bluetooth-Stack – „oder weil Apple sich nicht an die Bluetooth-Standards hält“, wie der Entwickler auf Reddit schreibt – offenbar geändert. Die App steht nun im Play Store [2] zum Download bereit, sie erfordert jedoch mindestens die Android-Version 16 QPR3 [3], die Anfang März 2026 von Google veröffentlicht wurde.

Das bedeutet, dass zunächst zum einen nur Googles Pixel-Geräte ab der 6. Generation die App unterstützen. Allerdings haben dem Entwickler zufolge [4] auch schon OnePlus und Oppo ihre Android-Aufsätze OxygenOS 16 und ColorOS 16 so weit angepasst. Weitere Geräte erhalten seinen Aussagen zufolge erst mit Android 17 [5] Unterstützung ohne Root.

AirPods Pro 2 mit vollem Support

Laut Devar bietet die App vollen Support der Funktionen der AirPods Pro 2 und 3, wobei bei der neuen Generation die Herzfrequenzmessung nicht unterstützt wird. Auch die AirPods Max würden unterstützt. Alle anderen AirPods-Modelle böten immerhin die Grundfunktionen wie Batteriestatus und Ohrerkennung.

Screenshots LibrePod App
Screenshots LibrePod App

Einige der LibrePods-Funktionen erfordern den einmaligen Kauf. Die Grundfunktionen sind kostenfrei nutzbar.

(Bild: Andreas Floemer / heise medien)

Zu den unterstützten Funktionen gehören etwa die Geräuschunterdrückungsmodi, adaptive Transparenz, Akkuanzeige, Gesprächserkennung, Kopfbewegungen und vieles mehr, wobei Kopfbewegungen und weitere Features kostenpflichtig sind – die Freischaltung der Funktionen kostet einmalig 5 Euro.

Weiter sagt der Entwickler [6], die Genauigkeit des Akkustands sei besser als bei anderen Ohrstöpseln. Schließlich sind auch die Gesten – also was beim langen Druck auf die AirPods-Stängel passiert – konfigurierbar, wobei die Aktivierung von Sprachassistenten Teil der Premiumfunktion ist.

Für Nutzerinnen und Nutzer, die in Googles und Apples Ökosystem zu Hause sind und AirPods besitzen, klingt die App durchaus praktisch. Für Linux gibt es sie ebenfalls.


URL dieses Artikels:
https://www.heise.de/-11275141

Links in diesem Artikel:

  1. https://www.heise.de/news/LibrePods-Volle-AirPods-Unterstuetzung-fuer-Android-braucht-Root-11081462.html
  2. https://play.google.com/store/apps/details?id=me.kavishdevar.librepods
  3. https://www.heise.de/news/Pixel-Drop-im-Maerz-Das-ist-neu-im-Update-fuer-Pixel-Geraete-11198213.html
  4. https://www.reddit.com/r/Android/comments/1sx2ft2/librepods_is_now_on_play_store/
  5. https://www.heise.de/thema/Android-17
  6. https://github.com/kavishdevar/librepods/blob/main/README.md
  7. https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
  8. mailto:afl@heise.de

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ Telepolis

Eisen-Flow-Batterie aus China hält 6000 Zyklen ohne Kapazitätsverlust

Von Telepolis — 28. April 2026 um 16:00
Reihen von großen weißen Batteriemodulen mit Lüftern an den Seiten.

Symbolbild: Eine groß angelegte Batterieanlage, die mit der neuen chinesischen Eisen-Flow-Technologie betrieben werden könnte.

(Bild: harhar38 / Shutterstock.com)

Chinesische Forscher präsentieren eine Eisen-Flow-Batterie, die 6000 Zyklen ohne Kapazitätsverlust übersteht. Das Rohmetall kostet 80-mal weniger als Lithium.

Forscher am Institute of Metal Research der Chinesischen Akademie der Wissenschaften (CAS) in Shenyang haben eine neuartige Eisen-Flow-Batterie entwickelt. Sie übersteht mehr als 6.000 vollständige Lade- und Entladevorgänge, ohne messbar an Kapazität zu verlieren – das entspricht über 16 Jahren täglichem Einsatz.

Als Aktivmaterial dient Eisen, das derzeit rund 80-mal günstiger ist als Lithium.

Veröffentlicht wurden die Ergebnisse vom Team um Erstautor Wei Wei sowie den Co-Leitern Tang Ao und Li Ying im Fachjournal Advanced Energy Materials (CAS-Pressemitteilung [1]).

Wie die South China Morning Post [2] berichtet, sehen Fachleute darin einen wichtigen Schritt, um die Speicherung von Strom aus erneuerbaren Quellen im großen Maßstab wirtschaftlich attraktiv zu machen.

Molekularer Schutzschild gegen Verschleiß

Eisen-Flow-Batterien gelten schon länger als hoffnungsvoll: Sie kommen mit einem reichlich vorhandenen Rohstoff aus und nutzen wasserbasierte, nicht brennbare Flüssigkeiten als Elektrolyt.

Bislang scheiterte die Marktreife allerdings an der negativen Seite der Zelle: Das aktive Material zersetzt sich allmählich und wandert durch die Trennmembran. Dieser sogenannte Crossover-Effekt verkürzt die Lebensdauer drastisch.

Das CAS-Team hat dieses Problem mit einem cleveren molekularen Trick gelöst. Der neu entwickelte Eisen-Komplex mit der Formel [Fe(HPF)BHS]⁴⁻ vereint zwei Schutzmechanismen in einem Molekül: Seine sperrige, starre Struktur umhüllt den Eisenkern wie ein Panzer und hält aggressive Hydroxid-Ionen physisch auf Abstand.

Zusätzlich sorgt die hohe negative Ladung des Komplexes über den sogenannten Donnan-Effekt für eine elektrostatische Barriere – sie verringert den Durchtritt durch die Membran um das Hundertfache.

Hohe Effizienz, niedrige Kosten

Laut Interesting Engineering [3] erreicht der Prototyp eine Coulomb-Effizienz von 99,4 Prozent. Auch unter hoher Belastung von 150 mA/cm² bleibt die Energieeffizienz mit 78,5 Prozent bemerkenswert hoch, die Spitzenleistungsdichte liegt bei 392,1 mW/cm².

Über alle 6.000 Zyklen hinweg traten weder schädliche Nebenprodukte noch Ablagerungen auf.

Mit 30 bis 40 Wattstunden pro Liter speichern Flow-Batterien zwar deutlich weniger Energie pro Volumen als Lithium-Ionen-Akkus. Für stationäre Netzspeicher, die Strom über vier bis zwölf Stunden abgeben, ist das aber zweitrangig.

Wichtiger sind hier die sogenannten Levelized Cost of Storage (LCOS) – also die Kosten pro gespeicherter Kilowattstunde über die gesamte Lebensdauer. Und genau die fallen dank der extremen Haltbarkeit deutlich niedriger aus: Berechnungen gehen für Zehn-Stunden-Systeme von rund 0,16 US-Dollar pro Kilowattstunde aus, bis zu 40 Prozent unter dem Niveau vergleichbarer Lithium-Ionen-Speicher.

Internationaler Wettbewerb und Skalierung

Die Forschung kommt zu einem Zeitpunkt, an dem das Rennen um eisenbasierte Flow-Batterien weltweit Fahrt aufnimmt. In den USA entwickelt das Unternehmen ESS Tech aus Oregon saure Eisen-Flow-Systeme und kooperiert dazu mit Google im Rahmen des Project New Horizon (Lieferung bis Ende 2027 geplant).

Allerdings haben diese Designs mit der Bildung von Dendriten zu kämpfen – nadelförmigen Kristallen, die Kurzschlüsse auslösen können. Die alkalische Chemie der chinesischen Variante umgeht dieses Problem.

Bis zur Massenproduktion sind dennoch einige Hürden zu nehmen: Die Membranen müssen für Anlagen im Megawattstunden-Maßstab optimiert werden, auch Pumpen und Systemintegration erfordern weitere Entwicklungsarbeit.

Größere Speicherkapazitäten lassen sich bei Flow-Batterien prinzipiell einfach durch größere Elektrolyt-Tanks erreichen – die nötigen Lieferketten dafür müssen jedoch erst aufgebaut werden.

Für die Energiewende könnte die Technologie trotzdem zum Schlüssel werden. Wenn Wind und Sonne ausbleiben, benötigt das Stromnetz zuverlässige und günstige Langzeitspeicher. Eine Batterie, die 16 Jahre ohne Wartung des Aktivmaterials arbeitet und auf einem der häufigsten Elemente der Erdkruste basiert, erfüllt – zumindest auf dem Papier – die wichtigsten Voraussetzungen dafür.


URL dieses Artikels:
https://www.heise.de/-11275350

Links in diesem Artikel:

  1. http://www.imr.cas.cn/xwzx/kydt/202604/t20260416_8186375.html
  2. https://www.scmp.com/news/china/science/article/3351111/china-unveils-ultra-cheap-all-iron-battery-renewable-energy-storage
  3. https://interestingengineering.com/energy/new-all-iron-battery-sustains-6000-cycles

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ Telepolis

Iran-Krieg: Helium-Engpass gefährdet globale Chipproduktion

Von Telepolis — 28. April 2026 um 15:00
Silizium-Wafer mit aufgedruckten Mikroprozessoren.

(Bild: asharkyu/Shutterstock.com)

Katars Helium-Exporte sinken um 14 Prozent, Spotpreise haben sich verdoppelt. Die Halbleiterbranche steht vor einer Versorgungskrise.

Der Krieg zwischen den USA und Israel einerseits sowie dem Iran auf der anderen Seite hat eine Reihe wirtschaftlicher Verwerfungen ausgelöst – von Öl über Erdgas hin zu Wolfram und Düngemitteln. Doch ein oft übersehener Rohstoff rückt jetzt immer stärker in den Fokus: Helium.

Wie Foreign Policy berichtet [1], hat der Angriff Irans auf Katars Ras-Laffan-Anlage – die größte LNG-Produktionsstätte der Welt – die globale Helium-Versorgung massiv getroffen. Der staatliche Konzern QatarEnergy stoppte die Produktion, erklärte Force Majeure und kürzte die jährlichen Helium-Exporte um 14 Prozent.

Katar lieferte vor Kriegsbeginn rund ein Drittel des weltweit verfügbaren Heliums. Zusammen mit den USA, die 43 Prozent der globalen Produktion beisteuern, deckten beide Länder laut dem U.S. Geological Survey [2] etwa 76 Prozent des Weltmarkts ab.

Diese extreme Konzentration auf wenige Quellen rächt sich nun. Selbst nach dem Waffenstillstand vom 8. April bleibt die Straße von Hormus – der nur 54 Kilometer (29 Seemeilen) [3] breite Nadelöhr-Seeweg, über den die meisten katarischen Helium-Exporte laufen – durch sich überlappende US-amerikanische und iranische Blockaden gesperrt.

Die Spotpreise für Helium haben sich im vergangenen Monat bereits verdoppelt. Da der Großteil des Handels über langfristige Verträge läuft und der Transport von Helium-Containern Zeit benötigt, dürfte der eigentliche Preisschock erst noch kommen.

Der Gasdistributor Airgas (Air Liquide) hat Lieferungen bereits auf 50 Prozent der üblichen Menge rationiert und einen Aufschlag von 13,50 US-Dollar pro 100 Kubikfuß eingeführt.

Unverzichtbar in der Chipfertigung

Helium ist in der modernen Halbleiterproduktion an zahlreichen Stellen unverzichtbar [4]. Das Edelgas kühlt die Lithographie- und Ätzanlagen einschließlich der empfindlichen EUV-Maschinen, stabilisiert die Temperatur von Silizium-Wafern und dient dazu, Verunreinigungen aus der Produktionsumgebung zu spülen.

Seine Wärmeleitfähigkeit ist sechsmal höher als die von Stickstoff, gleichzeitig ist es chemisch völlig inert – Eigenschaften, für die es schlicht kein Substitut gibt.

Patrick Wilson von der Semiconductor & Innovation Group [5] brachte es gegenüber Foreign Policy auf den Punkt: Chiphersteller "brauchen nicht nur sehr viel davon, sondern sie brauchen es ständig".

Eine Studie des Marktforschungsunternehmens IDTechEx aus dem Jahr 2024 prognostiziert laut Bericht, dass die Helium-Nachfrage der globalen Halbleiterindustrie sich im kommenden Jahrzehnt mehr als verfünffachen wird.

Südkorea und Taiwan unter Druck

Besonders angespannt ist die Lage in Südkorea, wo Samsung und SK Hynix zusammen fast drei Viertel aller DRAM-Speicherchips [6] weltweit fertigen. Beide Unternehmen bezogen rund 65 Prozent ihres Heliums aus Katar [7].

Wie heise online bereits berichtete [8], gab SK Hynix zwar kurzfristig Entwarnung – man verfüge über "vielfältige Lieferketten und ausreichende Vorräte". Doch nach Branchenschätzungen reichen die südkoreanischen Bestände nur bis etwa Juni 2026. Danach drohen erste Produktionseinschränkungen.

Die Aktien von Samsung und SK Hynix sackten zwischenzeitlich um beinahe 10 Prozent ab. Auch Taiwan reagiert: Der taiwanesische Halbleiter-Branchenverband TSIA forderte die Regierung in Taipeh auf, strategische Reserven für Helium und Erdgas aufzubauen.

Ein Gas, das sich nicht horten lässt

Eine strategische Bevorratung von Helium ist allerdings physikalisch alles andere als trivial. Flüssiges Helium muss bei 4 Kelvin (minus 269 Grad Celsius) gelagert werden und degradiert in Transportcontainern nach etwa 45 Tagen.

Nicholas Snyder, Chef von North American Helium, bezeichnete das Gas gegenüber Foreign Policy als "verderbliche" Ware: "Es gibt weltweit keine auslieferbaren Speicherkapazitäten, die dieses Problem einfach lösen könnten".

Die USA unterhielten einst eine strategische Helium-Reserve nahe Amarillo in Texas, eingerichtet 1925 und im Kalten Krieg ausgebaut. Doch der Kongress ordnete 1996 deren Privatisierung an – die Reserve sei zu teuer und halte die Preise "künstlich niedrig".

Nach mehreren Verzögerungen wurde der Verkauf 2024 abgeschlossen. "Die Regierung hat im Grunde keine strategische Reserve mehr", sagte Wilson.

Normalisierung dauert Monate

Auch wenn der Waffenstillstand hält und Katar die Produktion wieder hochfährt, rechnet die Branche mit langen Verzögerungen. Bettina Weiss, Stabschefin beim Halbleiter-Branchenverband SEMI, schätzt gegenüber Foreign Policy, dass die Normalisierung der Lieferketten vier bis sechs Monate dauern würde – "selbst wenn die Straße von Hormus heute geöffnet würde".

QatarEnergy geht laut Axios [9] sogar davon aus, dass die Reparaturen an der Ras-Laffan-Anlage drei bis fünf Jahre in Anspruch nehmen könnten.

Alternative Quellen sind begrenzt. US-Produzenten wie Linde und Air Products können ihre Kapazitäten zwar erhöhen, benötigen dafür aber Wochen bis Monate. Russlands Amur-Komplex wäre theoretisch eine Option – steht jedoch unter Sanktionen.

Auch in Deutschland warnt der Verband der Chemischen Industrie (VCI) vor Engpässen. Betroffen wären hierzulande unter anderem Infineon und GlobalFoundries am Standort Dresden.

David Pan, KI-Branchenexperte bei Moody's, fasste die Abhängigkeiten laut Foreign Policy in einer Stellungnahme zusammen: "Die KI-Ökonomie läuft auf Tokens, Tokens laufen auf GPUs, und GPUs hängen von katarischem Helium, israelischem Brom und LNG-Tankern mit einem einzigen, 34 Kilometer breiten Ausgang aus dem Persischen Golf ab."


URL dieses Artikels:
https://www.heise.de/-11275113

Links in diesem Artikel:

  1. https://foreignpolicy.com/2026/04/27/iran-war-hormuz-strait-helium-semiconductors-chips-supply-chain-prices/
  2. https://pubs.usgs.gov/periodicals/mcs2026/mcs2026-helium.pdf
  3. https://www.iea.org/about/oil-security-and-emergency-response/strait-of-hormuz
  4. https://www.heise.de/tp/article/Helium-Mangel-Ein-weiterer-Tiefschlag-fuer-die-Weltwirtschaft-11227708.html
  5. https://www.semiconductorinnovationgroup.com/
  6. https://www.heise.de/tp/article/DRAM-Chips-werden-knapp-Der-Iran-Krieg-trifft-die-Tech-Branche-ins-Mark-11200348.html
  7. https://fortune.com/2026/04/22/helium-forecast-outlook-iran-war-moodys/
  8. https://www.heise.de/news/Anhaltender-Irankrieg-koennte-Speicherkrise-langfristig-verschaerfen-11204349.html
  9. https://www.axios.com/2026/04/07/iran-war-qatar-helium-production

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ Telepolis

Kritik war gestern: Wie KI und Medienlogik die Debattenkultur entkernen

Von Telepolis — 28. April 2026 um 14:15
Aufgeschlagenes Buch in einer Bibliothek

Bild: Shutterstock.com

Weniger Widerspruch, mehr Wohlfühlton: Warum Kulturkritik zur Randnotiz wird – und was das für die Öffentlichkeit bedeutet. Ein Lagebericht.

Die professionelle Kulturkritik verschwindet aus den Medien – und mit ihr die Fähigkeit der Gesellschaft, sich über Kunst und Werte zu verständigen. Doch statt zu kapitulieren, braucht es neue Wege.

Filmkritik sei ein "Traumberuf mit miesen Arbeitsbedingungen", heißt es in einem aktuellen Lagebericht des Verbandes der deutschen Filmkritik [1] (VDFK). Das durchschnittliche Jahreseinkommen aus filmkritischer Arbeit liege bei nur 16.000 Euro brutto – eine Summe, von der niemand leben könne.

Die Konsequenz: Erfahrene Kritikerinnen und Kritiker müssen den Beruf aufgeben.

"Freischaffende Kritiker*innen, die fast 90 Prozent der Befragten ausmachen, verdienen im Schnitt sogar nur 13.300 Euro jährlich mit Filmkritik. Die meisten Befragten gehen weiteren beruflichen Tätigkeiten nach. Selbst wer 70 bis 100 Prozent des Gesamteinkommens mit Filmkritik erwirtschaftet, kommt auf lediglich 21.000 Euro brutto im Jahr."

VDFK, Prekäre Bedingungen für Filmkritik [2]

Die Auftragslage sei spürbar eingebrochen: Es gibt weniger Geld für Filmkritiken und weniger Auftraggeber – und der Druck frisst sich längst auch in die Redaktionen hinein.

Der VDFK warnt, dass der Bedeutungsverlust von Kulturkritik eine "Gefahr für den demokratischen Diskurs" darstelle. Die Begründung: "Kulturkritik ist Gesellschaftskritik."

Wer Filme, Bücher oder Theaterstücke analysiere, setze sich immer auch mit den Werten und Konflikten einer Gesellschaft auseinander. Was der VDFK für die Filmkritik beschreibt, trifft auf größere Teile der Kulturkritik zu, die ihr einstmaliges Prestige eingebüßt hat und ihr Selbstverständnis neu evaluieren muss.

Radio macht Literaturkritik zur Serviceleistung

Besonders drastisch zeigt sich der Wandel im öffentlich-rechtlichen Rundfunk. Der Germanist und Literaturkritiker Herbert Hoven schildert unter dem Titel "Fünf Minuten für E. T. A. Hoffmann [3]", wie Literaturkritik im Radio zu einer oberflächlichen "Serviceleistung" verkommt.

Klassische Rezensionen würden durch kurze "Buchtipps" ersetzt, die den Kriterien einer echten Rezension nicht mehr gerecht werden könnten. Das Radio verstehe sich nur noch als "Nebenbei-Medium", das eine "positive Grundstimmung" erzeugen solle. Differenzierte Auseinandersetzungen werden selten.

Diese Entwicklung ist eng mit ökonomischem Druck verwoben. Redaktionelle Entscheidungen orientierten sich zunehmend an Marketingstrategien und der Ausrichtung auf "Eroberungszielgruppen". Statt selbstbewusst Themen zu setzen, biederten sich Redaktionen einem vermeintlichen Publikumsgeschmack an. Die von Hoven zitierte Schriftstellerin Kathrin Röggla spricht in diesem Kontext von "reinem Populismus".

Ein Beispiel für diese Vereinfachung: E.T.A. Hoffmann werde als "Steven King seiner Zeit" bezeichnet, um junge Zielgruppen zu erreichen. Solche Vergleiche mögen eingängig klingen, führten aber zum Verlust sprachlicher Präzision und "gedanklicher Trennschärfe", kritisiert Hoven.

Der Schauspieler Ulrich Tukur warnt in diesem von Hoven zitierten Kontext gar vor einem "Verbrechen": Die Zuschauer würden "ständig mit Brei abgefüttert", bis ihnen die "Zähne ausfallen".

KI überschwemmt das Netz mit generierten Texten

Parallel zu diesem Rückzug der professionellen Kulturkritik verändert künstliche Intelligenz die digitale Öffentlichkeit fundamental: Seit Ende 2022 sei rund ein Drittel aller neu veröffentlichten Websites KI-generiert – zeigt eine Studie [4] von Forschern der Stanford University, dem Imperial College London und dem Internet Archive.

Sie sprechen von einem "AI takeover of the web [5]" – einer KI-Übernahme des Internets. Die stilistischen Folgen sind messbar: KI-generierte Texte führen zu einer geringeren semantischen Vielfalt und einem insgesamt positiveren, "fröhlicheren" Ton.

Die Forschenden warnen vor einem "sanitized, repetitive web" – einem bereinigten, sich wiederholenden Internet. Interessanterweise konnte die Hypothese eines Anstiegs von Falschaussagen durch KI (Truth Decay) nicht bestätigt werden.

Neue Wege statt Kapitulation

Der Rückzug der professionellen Kulturkritik und die Ausbreitung von KI-Inhalten sind zwei Seiten derselben Medaille, angetrieben durch ökonomischen Druck zur Kostenreduktion und Reichweitenmaximierung.

Wo menschliche Kritik aus finanziellen Gründen verschwindet, entsteht ein Vakuum, das KI mit uniformen, konfliktfreien Texten füllt. Das macht deutlich, was auf dem Spiel steht: eine Öffentlichkeit, in der Meinungsvielfalt und kritische Auseinandersetzung nicht nur möglich bleiben, sondern gesucht werden, um Leben und ein Gefühl für wichtige Nuancen statt klotzigem Denken in die res publica zu bringen.

Statt zu resignieren, braucht es den Mut zu neuen Formaten, die komplexe Analysen zugänglich machen, ohne sie zu verflachen. Kulturkritik wird gebraucht – nicht trotz, sondern gerade wegen der Komplexität unserer Zeit. Es liegt an den Medien, den Kritikern selbst und nicht zuletzt am Publikum, ihr eine Zukunft zu sichern.


URL dieses Artikels:
https://www.heise.de/-11275135

Links in diesem Artikel:

  1. https://www.vdfk.de/prekaere-bedingungen-fuer-filmkritik-ergebnisse-einer-umfrage-des-vdfk-6947
  2. https://www.vdfk.de/prekaere-bedingungen-fuer-filmkritik-ergebnisse-einer-umfrage-des-vdfk-6947
  3. https://literaturkritik.de/public/rezension.php?rez_id=31950
  4. https://ai-on-the-internet.github.io/?ref=404media.co
  5. https://www.404media.co/study-finds-a-third-of-new-websites-are-ai-generated/

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ heise Security

Social-Media-Verbot für Jugendliche: Australiens Kontrolle greift nicht

Von Heise — 28. April 2026 um 14:38

Plattformen prüfen wenig, Konten bleiben bestehen. Neue Daten zeigen systematische Schwächen des weltweit ersten Verbots.

Das vor knapp fünf Monaten in Australien eingeführte Social-Media-Verbot für unter 16-Jährige erweist sich offenbar in der Praxis als weitgehend ineffektiv. Nach einer ersten groß angelegten Umfrage der Molly Rose Foundation haben 61 Prozent der befragten 12- bis 15-Jährigen, die bereits vorher Konten besaßen, weiterhin Zugriff auf mindestens eines davon. Plattformen wie TikTok, YouTube und Instagram ergreifen demnach oftmals keine Maßnahmen, um Minderjährige zu identifizieren und auszuschließen.

Für die Erhebung [1] wurden im März 1.050 australische Jugendliche befragt. Die Daten zeigen, dass die Social-Media-Anbieter bisherige Accounts zum großen Teil unangetastet lassen: Bei YouTube gaben 64 Prozent der verbliebenen jungen Nutzer an, der Betreiber habe nichts unternommen, um ihre Konten zu deaktivieren. Bei Instagram und TikTok äußerten dies jeweils rund 60 Prozent. Knapp ein Viertel der Teenager hat Alterskontrollen bei bestehenden Konten zudem aktiv umgangen.

Technische Hilfsmittel wie VPNs kamen dabei lediglich bei vier bis fünf Prozent zum Einsatz. Stattdessen griffen einige Jugendliche Berichten zufolge auf Ausweise ihrer Eltern oder auf bedruckte Masken zurück, um die Gesichtserkennungssysteme zu umgehen.

Jugendschutzziele bisher nicht erreicht

Das politische Kernziel, die Sicherheit von Kindern im Netz zu erhöhen, wird der Umfrage zufolge verfehlt. Über die Hälfte der betroffenen Jugendlichen (51 Prozent) gab an, sich online nicht sicherer zu fühlen als vor dem Verbot. Gleichzeitig weichen die Jugendlichen auf andere digitale Dienste aus: 43 Prozent nutzen verstärkt Gaming-Plattformen, 39 Prozent verbringen mehr Zeit mit Messengern.

Allerdings verzeichnet die Studie auch erste Teilerfolge: Immerhin 31 Prozent der betroffenen Jugendlichen gaben an, sich nun sicherer zu fühlen, und die Hälfte bemerkten, nun weniger Zeit online zu verbringen. Die Stiftung warnt jedoch, dass dieser Effekt mit der Zeit wieder verschwinden könnte.

Die Molly Rose Foundation rät anderen Ländern wie Großbritannien vor diesem Hintergrund davon ab, das australische Gesetz zu kopieren. Ein pauschales Verbot entbinde Tech-Konzerne von ihrer Verantwortung für sicheres Produktdesign und erzeuge lediglich Scheinsicherheit. Die Organisation fordert stattdessen schärfere Regulierungen, um die Plattformbetreiber rechtlich in die Pflicht zu nehmen und gefährliche Algorithmen direkt zu verändern.

Die australische Regierung hatte den Tech-Konzernen bei Gesetzesverstößen bereits mit Klagen vor dem Bundesgericht gedroht [2]. Sie habe demnach Untersuchungen wegen systematischer Verstöße gegen die Altersprüfung eingeleitet. Den Unternehmen sollen bei nachgewiesener Missachtung der Gesetze Bußgelder von bis zu 49,5 Millionen Australischen Dollar (rund 30 Millionen Euro) pro Verstoß drohen.

Weitere Länder könnten Australien folgen

Ab Dezember 2025 hatte Australien als erstes Land ein weitreichendes Social-Media-Verbot für unter 16-Jährige verhängt [3]. Die Regierung wolle damit die psychische Gesundheit der Kinder vor schädlichen Einflüssen aus dem Netz schützen. So sollen Gefahren wie Cybermobbing und suchtfördernde Algorithmen aktiv eingedämmt werden. 4,7 Millionen Konten [4] sind nach Angaben der australischen Behörden anschließend gesperrt worden.

Kritiker bezweifeln jedoch die Wirksamkeit des Verbots [5], da Jugendliche solche Sperren leicht umgehen könnten. Zudem warnen Experten davor, dass ein Pauschalverbot junge Menschen von wichtigen digitalen Netzwerken und Hilfsangeboten isoliert. Als Alternative fordern Medienpädagogen stattdessen etwa eine gezielte Förderung der digitalen Medienkompetenz und die stärkere Regulierung der Plattformalgorithmen.

Auch in Europa werden ähnliche Social-Media-Verbote diskutiert. Eingesetzt werden könnte etwa eine kürzlich vorgestellte Wallet-App [6] der EU zur Altersverifikation. Bisherige Verbotspläne der deutschen Regierungsparteien CDU und SPD stoßen dabei allerdings auf erhebliche rechtliche Hürden [7].


URL dieses Artikels:
https://www.heise.de/-11275105

Links in diesem Artikel:

  1. https://mollyrosefoundation.org/wp-content/uploads/2026/04/MRF_Australia-Social-Media-Ban-Research_Briefing-April-26.pdf
  2. https://www.reuters.com/sustainability/society-equity/australia-investigates-tech-giants-over-social-media-ban-compliance-2026-03-30/
  3. https://www.heise.de/news/Social-Media-Verbot-in-Australien-tritt-in-Kraft-Jugendliche-verlieren-Accounts-11109147.html
  4. https://www.heise.de/news/Australien-4-7-Millionen-Social-Media-Konten-von-Unter-16-Jaehrigen-gesperrt-11142562.html
  5. https://www.heise.de/hintergrund/Medienforscherin-kritisiert-ein-generelles-Social-Media-Verbot-11205362.html
  6. https://www.heise.de/hintergrund/EU-App-zur-Altersverifikation-ist-startklar-11252753.html
  7. https://www.heise.de/hintergrund/Social-Media-Verbot-per-EU-Wallet-Was-der-SPD-Plan-bedeuten-wuerde-11183974.html
  8. https://www.heise.de/ct
  9. mailto:hag@heise.de

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ heise Security

GitHub CLI führt standardmäßige Telemetrie-Erfassung ein

Von Heise — 28. April 2026 um 13:56
GitHub-Logo an Gebäudewand

(Bild: Sundry Photography / Shutterstock.com)

GitHub CLI sammelt Telemetriedaten, um die Nutzung agentischer Tools zu analysieren. User machen automatisch mit, sofern sie nicht per Opt-out widersprechen.

GitHub CLI erhebt mit Version 2.91.0 Telemetriedaten. Die Datensammelei des offiziellen Kommandozeilentools von GitHub erfolgt clientseitig in pseudonymisierter Form und ist standardmäßig aktiv. Anwenderinnen und Anwender, die das nicht wollen, können per Opt-out aussteigen.

Die Datenerhebung dient laut GitHub [1] dazu, die agentische Nutzung von GitHub CLI besser zu verstehen. Dazu benötigt das Entwicklungsteam einen Einblick in die praktische Nutzung der Funktionen. Die gesammelten Daten würden in der internen Analyseinfrastruktur von GitHub landen. Nachdem das Telemetriefeature anfänglich lediglich in den Release Notes zu Version 2.91.0 [2] erwähnt und in die Dokumentation aufgenommen wurde, hat es GitHub inzwischen auch offiziell in seinem Blog [3] kommuniziert.

Die Dokumentation für GitHub CLI nennt mehr als 20 Felder wie agent, architecture, is_tty und skill_names, die telemetrisch im Fokus stehen. Über die Umgebungsvariable export GH_TELEMETRY=log oder die Konfigurationsoption gh config set telemetry log lässt sich ein Protokollierungsmodus aktivieren. Wenn das Logging aktiv ist, gibt das Tool einen Einblick in die erhobenen Telemetriedaten, ohne diese jedoch tatsächlich zu übermitteln.

Drei Möglichkeiten zum Opt-out

Anwenderinnen und Anwender können GitHub CLI prinzipiell das Datensammeln auf dreierlei Arten untersagen: Über das Setzen der Umgebungsvariable export GH_TELEMETRY=false, wobei ein false-äquivalenter Wert wie 0 oder disabled ebenfalls funktioniert; des Weiteren über export DO_NOT_TRACK=true und zum Dritten per CLI-Konfiguration mit gh config set telemetry disabled.

Mit der Analyse von Nutzerdaten begann GitHub bereits im April dieses Jahres [4]. Eine Änderung der Nutzungsbedingungen erlaubt es der zu Microsoft gehörenden Softwareentwicklungsplattform seitdem, Interaktionen der Anwenderinnen und Anwender mit Copilot Free, Pro und Pro+ für das Modelltraining der eigenen KI zu verwenden. Business- und Enterprise-Konten sind davon ausgenommen. Auch hier gibt es die Möglichkeit, dem per Opt-out zu widersprechen. Erwähnenswert: Das Arch-Linux-Paket deaktiviert die GitHub-Telemetrie ab Version 2.91.0-3 [5] standardmäßig. Bei anderen Distributionen müssen Nutzerinnen und Nutzer selbst aktiv werden.


URL dieses Artikels:
https://www.heise.de/-11274735

Links in diesem Artikel:

  1. https://cli.github.com/telemetry
  2. https://github.com/cli/cli/releases/tag/v2.91.0
  3. https://github.blog/changelog/2026-04-22-github-cli-opt-out-usage-telemetry/
  4. https://www.heise.de/news/Nur-mit-Opt-out-GitHub-trainiert-kuenftig-Copilot-Modelle-mit-Nutzerdaten-11225588.html
  5. https://www.mail-archive.com/arch-commits%40lists.archlinux.org/msg1038440.html
  6. mailto:manuel.masiero@heise.de

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ heise Security

Secure-Boot-Zertifikate: Microsoft Defender verschafft Überblick

Von Heise — 28. April 2026 um 13:49
Kaputtes Sicherheitsschloss

(Bild: Maksim Kabakou / Shutterstock.com)

Die Zeit wird knapp: Die Secure-Boot-Zertifikate aus 2011 laufen ab Juni dieses Jahres ab. Microsoft Defender hilft im Enterprise-Umfeld.

Microsoft will im Enterprise-Umfeld helfen, die Maschinen mit ablaufenden Secure-Boot-Zertifikate aus dem Jahr 2011 zu identifizieren. Einige Hilfestellung für Netzwerke gab es bereits, nun soll auch der Microsoft Defender helfen, betroffene Geräte aufzuspüren und auf den aktuellen Stand zu bringen.

Im Message-Center der Windows-Release-Health-Notizen [1] hat Microsoft jetzt die neue Funktion für den Microsoft Defender angekündigt. Es handelt sich um ein Dashboard, von dem aus IT-Verantwortliche in Netzen den Sicherheitsstatus ihrer betreuten Geräte einsehen können. Jetzt können IT-Teams an zentraler Stelle die Verbreitung der Secure-Boot-Zertifikate aus dem Jahr 2023 in ihrem Gerätepark einsehen, erklärt das Unternehmen. Ein Blog-Eintrag in der Techcommunity [2] geht etwas detaillierter darauf ein.

Auswirkungen abgelaufener Secure-Boot-Zertifikate

Microsoft erklärt dort, dass Secure Boot die Integrität des Boot-Prozesses eines Geräts sicherstellt, indem nur vertrauenswürdige Software gestartet wird. Sofern Geräte keine neuen Zertifikate erhalten, können sie nicht in den Genuss neuer Sicherheitsmaßnahmen für den frühen Startvorgang kommen. Die Geräte starten weiterhin, können aber keine neueren Schutzmaßnahmen in der frühen Startphase des Systems mehr erzwingen. Im Verlauf der Zeit schwäche das die „Root of Trust“ des Geräts und setzt sie neuen Klassen von Angriffen aus, die vor dem Laden des Betriebssystems und der vollständigen Sicherheitskontrollen aktiv werden.

Konkret könnten bösartige oder manipulierte Boot-Komponenten nicht mehr zuverlässig blockiert werden, wenn sie nicht mit vertrauten Zertifikaten signiert sind. Geräte könnten nicht in der Lage sein, neue Secure-Boot-Richtlinien zu übernehmen, die vor neu entdeckten Bedrohungen beim Bootvorgang schützen sollen. Außerdem können Angreifer zur Startzeit Techniken zur Erlangung von Persistenz einsetzen, bevor traditionelle Sicherheitskontrollen greifen.

Um das zu verhindern, sollen IT-Verantwortliche einen Überblick erhalten, welche Geräte bereits erfolgreich das Update absolviert haben und welche Geräte noch Aufmerksamkeit diesbezüglich benötigen. Im Microsoft-Defender-Dashboard haben die Entwickler daher eine neue Empfehlung (Recommendations) eingebaut. Die unterteilt die Geräte in drei Klassen: „Exposed Devices“ vertrauen noch den alten Secure-Boot-Zertifikaten, ohne Vertrauen in die neueren Zertifikate. „Compliant Devices“ haben die neuen 2023er-Zertifikate und den signierten Boot-Manager. „Not applicable Devices“ hingegen haben Secure Boot deaktiviert oder unterstützen es nicht.

Aus dieser Empfehlungsansicht heraus können Admins sich „Exposed Devices“ genauer ansehen und herausfinden, welche Systeme noch Aufmerksamkeit benötigen. Filter lassen sich nach Betriebssystemplattform und Gerätekontext anwenden, um die Gegenmaßnahmen besser zu priorisieren. Die Gerätedaten lassen sich zudem exportieren, um sie mit Infrastruktur- und Plattform-Teams zu teilen. Natürlich lässt sich der Verteilungsprozess der Secure-Boot-Zertifikate damit überwachen. Microsoft schreibt nichts dazu, ob das mit Zusatzkosten verbunden ist.

Microsoft deckt damit nun unterschiedliche Netzwerkdimensionen ab. Auf den einzelnen Rechner hilft etwa die Windows-Sicherheits-App, den Status der Secure-Boot-Zertifikate [3] auf der konkreten Maschine einzusehen. IT-Verantwortliche müssen insbesondere auf Windows-Servern jedoch selbst aktiv werden, dort verteilt Microsoft die neuen Zertifikate nicht mit automatischen Windows-Updates [4]. Dass die Zertifikate auslaufen, darauf hat Microsoft bereits seit Juni 2025 aufmerksam [5] gemacht. Die Vorbereitungen sollten Admins nun abschließen und zügig an die Verteilung der neuen Secure-Boot-Zertifikate gehen.


URL dieses Artikels:
https://www.heise.de/-11275033

Links in diesem Artikel:

  1. https://learn.microsoft.com/en-us/windows/release-health/windows-message-center#4840
  2. https://techcommunity.microsoft.com/blog/MicrosoftDefenderATPBlog/assess-secure-boot-status-with-microsoft-defender/4510356
  3. https://www.heise.de/news/Update-Status-der-Secure-Boot-Zertifikate-in-Windows-Sicherheit-App-11246648.html
  4. https://www.heise.de/news/Microsoft-Anleitung-fuer-Secure-Boot-Zertifikate-von-Windows-Servern-11187588.html
  5. https://www.heise.de/news/Vorbereiten-auf-Einschlag-Microsoft-warnt-vor-Secure-Boot-Zertifikat-Update-10461866.html
  6. https://pro.heise.de/security/?LPID=39555_HS1L0001_27416_999_0&wt_mc=disp.fd.security-pro.security_pro24.disp.disp.disp
  7. mailto:dmk@heise.de

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ heise developer neueste Meldungen ff.org

GitHub streicht kostenlose Modelle aus den Copilot-Tarifen

Von Heise — 28. April 2026 um 14:09
Jemand tippt auf ein Smartphone, es erscheint ein Roboter und ein Einkaufswagen.

(Bild: Lalaka/Shutterstock.com)

Neue Tarife für den Copilot: Statt pauschal Premiumanfragen berechnet GitHub nun den konkreten Token-Verbrauch. Die kostenlosen Modelle entfallen dabei.

GitHub stellt das Bezahlmodell für den KI-Assistenten Copilot ab dem 1. Juni 2026 auf verbrauchsbasierend um: Die monatlichen Kosten für die bisherigen Tarife bleiben gleich, aber GitHub rechnet AI Credits für die Nutzung von Tokens ab. Ein Credit entspricht dabei 0,01 US-Dollar und die Kosten variieren je nach Modell. Leistungsfähigere erfordern mehr Credits pro Token.

In die Kosten fallen [1] hinein: Input-, Output- und Cache-Tokens, so wie sie in der API-Abrechnung des jeweiligen Modells erscheinen. Eine Million Output-Token kosten dabei zwischen 1,25 US-Dollar für GPT-5.4 nano und 30 Dollar für GPT-5.5. Claude Opus 4.7 kommt auf 25 Dollar, Gemini 3.1 Pro auf 12 Dollar.

Einen Fallback auf ein kostenloses, einfaches Modell wie bisher (GPT-5 mini, GPT-4.1 und GPT-4o) gibt es nicht mehr. Anwenderinnen und Anwender, die ihr Budget aufgebraucht haben, müssen ein Update kaufen. Für Reviews kommen die üblichen Minutenpreise für Actions hinzu.

Free-Tarif bleibt

Immer gratis bleiben jedoch Code-Vorschläge und auch den Free-Tarif will GitHub erhalten, allerdings ist noch nicht klar, zu welchen Bedingungen. Derzeit sind es 50 Premium-Anfragen und 2000 Code-Vorschläge.

Der Anbieter rechnet damit, dass in den Pro-Tarifen insbesondere Anwender von Token-aufwendiger Nutzung von agentic coding mit höheren Kosten rechnen müssen. Damit begründet GitHub auch die Umstellung [2]: „Die Nutzung von Agenten wird zum Standard und bringt signifikant höhere Anforderungen an Rechen- und Inferenzleistung mit sich.“ Das bisherige Tarifmodell berechnete Premiumanfragen an teure Modelle unabhängig vom Umfang der Anfrage. Die Komplexität der Anfragen und des Kontexts nimmt mit dem Einsatz von Agenten jedoch erheblich zu.

Automatische Umstellung ab Juni

Kunden der bisherigen monatlichen Tarife stellt GitHub automatisch um. Jährliche Verträge wird die Firma nicht verlängern und berechnet den Kunden während der restlichen Laufzeit einen Multiplikator für teurere Modelle. Ab Mai will GitHub auf der Abrechnungsseite in den Kundenkonten eine Übersicht zeigen, was die bisherige Nutzung nach der Umstellung kosten würde.

Als Zuckerl erhalten Business- und Enterprise-Kunden ein Addon in den ersten drei Monaten: Credits im Wert von 30 Dollar für Business- und 70 Dollar für Enterprise-Verträge („promotional included usage“).

Die vor einer Woche eingeführte Sperre [3] für individuelle Neukunden wird laut GitHub mit den neuen Tarifen aufgehoben. Derzeit versuchen alle Modell-Anbieter, die Kosten zu optimieren. Zuletzt experimentierte Anthropic mit dem Ausschluss von Claude Code [4] aus den Tarifen von Einzelanwendern.

In der Diskussion auf der FAQ-Seite [5] kritisieren Anwender insbesondere den Wegfall der kostenlosen Modelle bei Überschreitung des Budgets. Viele sehen das als Hauptvorteil des bisherigen Copilot-Tarifs gegenüber der Konkurrenz.


URL dieses Artikels:
https://www.heise.de/-11274893

Links in diesem Artikel:

  1. https://docs.github.com/de/copilot/reference/copilot-billing/models-and-pricing
  2. https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/
  3. https://www.heise.de/news/GitHub-Copilot-Neukunden-ausgesperrt-Nutzung-staerker-begrenzt-11265219.html
  4. https://www.heise.de/news/Anthropic-nimmt-testweise-Claude-Code-aus-dem-Pro-Tarif-11267811.html
  5. https://github.com/orgs/community/discussions/192948
  6. mailto:who@heise.de

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ heise developer neueste Meldungen ff.org

GitHub CLI führt standardmäßige Telemetrie-Erfassung ein

Von Heise — 28. April 2026 um 13:56
GitHub-Logo an Gebäudewand

(Bild: Sundry Photography / Shutterstock.com)

GitHub CLI sammelt Telemetriedaten, um die Nutzung agentischer Tools zu analysieren. User machen automatisch mit, sofern sie nicht per Opt-out widersprechen.

GitHub CLI erhebt mit Version 2.91.0 Telemetriedaten. Die Datensammelei des offiziellen Kommandozeilentools von GitHub erfolgt clientseitig in pseudonymisierter Form und ist standardmäßig aktiv. Anwenderinnen und Anwender, die das nicht wollen, können per Opt-out aussteigen.

Die Datenerhebung dient laut GitHub [1] dazu, die agentische Nutzung von GitHub CLI besser zu verstehen. Dazu benötigt das Entwicklungsteam einen Einblick in die praktische Nutzung der Funktionen. Die gesammelten Daten würden in der internen Analyseinfrastruktur von GitHub landen. Nachdem das Telemetriefeature anfänglich lediglich in den Release Notes zu Version 2.91.0 [2] erwähnt und in die Dokumentation aufgenommen wurde, hat es GitHub inzwischen auch offiziell in seinem Blog [3] kommuniziert.

Die Dokumentation für GitHub CLI nennt mehr als 20 Felder wie agent, architecture, is_tty und skill_names, die telemetrisch im Fokus stehen. Über die Umgebungsvariable export GH_TELEMETRY=log oder die Konfigurationsoption gh config set telemetry log lässt sich ein Protokollierungsmodus aktivieren. Wenn das Logging aktiv ist, gibt das Tool einen Einblick in die erhobenen Telemetriedaten, ohne diese jedoch tatsächlich zu übermitteln.

Drei Möglichkeiten zum Opt-out

Anwenderinnen und Anwender können GitHub CLI prinzipiell das Datensammeln auf dreierlei Arten untersagen: Über das Setzen der Umgebungsvariable export GH_TELEMETRY=false, wobei ein false-äquivalenter Wert wie 0 oder disabled ebenfalls funktioniert; des Weiteren über export DO_NOT_TRACK=true und zum Dritten per CLI-Konfiguration mit gh config set telemetry disabled.

Mit der Analyse von Nutzerdaten begann GitHub bereits im April dieses Jahres [4]. Eine Änderung der Nutzungsbedingungen erlaubt es der zu Microsoft gehörenden Softwareentwicklungsplattform seitdem, Interaktionen der Anwenderinnen und Anwender mit Copilot Free, Pro und Pro+ für das Modelltraining der eigenen KI zu verwenden. Business- und Enterprise-Konten sind davon ausgenommen. Auch hier gibt es die Möglichkeit, dem per Opt-out zu widersprechen. Erwähnenswert: Das Arch-Linux-Paket deaktiviert die GitHub-Telemetrie ab Version 2.91.0-3 [5] standardmäßig. Bei anderen Distributionen müssen Nutzerinnen und Nutzer selbst aktiv werden.


URL dieses Artikels:
https://www.heise.de/-11274735

Links in diesem Artikel:

  1. https://cli.github.com/telemetry
  2. https://github.com/cli/cli/releases/tag/v2.91.0
  3. https://github.blog/changelog/2026-04-22-github-cli-opt-out-usage-telemetry/
  4. https://www.heise.de/news/Nur-mit-Opt-out-GitHub-trainiert-kuenftig-Copilot-Modelle-mit-Nutzerdaten-11225588.html
  5. https://www.mail-archive.com/arch-commits%40lists.archlinux.org/msg1038440.html
  6. mailto:manuel.masiero@heise.de

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ heise developer neueste Meldungen ff.org

Cross-Plattform-Applikationen mit Rust 3: Fachlichkeiten und Shell-Integration

Von Heise — 28. April 2026 um 09:25
Rust

(Bild: iX)

Das Framework Crux verbindet fachliche Typen, modulare Apps und Cross-Plattform-Integration mit Rust und generiert skalierbare sowie testbare Anwendungen.

Nach einer Einführung in das Framework Crux geht es im dritten und letzten Teil der Artikelreihe nun um fortgeschrittene Konzepte und die praktische Integration in realen Anwendungen. Die folgenden Punkte zu fachlichen Typen, Aufteilung in mehrere Apps und dem Einsatz in konkreten Shell-Technologien zeigen einen detaillierten Blick aus der Praxis.

Fachliche Typen

In langlebigen Softwareprojekten ist es ratsam, fachliche Typen unabhängig vom eingesetzten Framework zu definieren. Im Rahmen der in den vorherigen Teilen gezeigten E-Mail-App bietet sich zum Beispiel der Typ EmailAddress an: Dieser Typ kapselt die Validierung und Repräsentation einer E-Mail-Adresse und stellt sicher, dass nur gültige Werte im System verwendet werden. Die Logik zur Prüfung – etwa auf das Vorhandensein des Zeichens @ – ist direkt im Typ verankert und nicht Teil der Crux-App.

Dadurch bleibt die fachliche Logik klar von technischen Details getrennt. Sie kann unabhängig von Crux, anderen Frameworks oder der konkreten Plattform getestet, wiederverwendet und weiterentwickelt werden. Sollte sich die technische Umgebung ändern, bleibt die Kernlogik erhalten und muss nicht neu geschrieben werden.

Fachliche Typen wie EmailAddress erhöhen die Wartbarkeit und Verständlichkeit des Codes und schützen vor Fehlern, indem sie ungültige Zustände bereits beim Erstellen verhindern.

Listing 1: Fachlicher Typ EmailAddress

#[derive(Clone, PartialEq, Eq, Hash, Debug, serde::Serialize, serde::Deserialize)]
pub struct EmailAddress(String);

#[derive(thiserror::Error, Debug)]
pub enum EmailError {
    #[error("missing @")]
    MissingAt,
}

impl EmailAddress {
    /// Der Smart-Constructor garantiert eine gültige Adresse
    pub fn parse(s: impl Into<String>) -> Result<Self, EmailError> {
        let s = s.into();
        if s.contains('@') { Ok(Self(s)) } else { Err(EmailError::MissingAt) }
    }

    pub fn as_str(&self) -> &str { &self.0 }
}

Fachliche Typen wie EmailAddress lassen sich unabhängig vom Framework testen.

Listing 2: Tests für EmailAddress

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn valid_email_is_accepted() {
        let email = EmailAddress::parse("marcel.koch@example.org");
        assert!(email.is_ok());
        assert_eq!(email.unwrap().as_str(), "marcel.koch@example.org");
    }

    #[test]
    fn invalid_email_is_rejected() {
        let email = EmailAddress::parse("marcel.kochexample.org");
        assert!(email.is_err());
        assert_eq!(email.unwrap_err(), EmailError::MissingAt);
    }
}

Der erste Test prüft, dass eine gültige E-Mail-Adresse akzeptiert und korrekt gespeichert wird. Der zweite Test stellt sicher, dass eine ungültige E-Mail-Adresse (ohne @) abgelehnt und der passende Fehler (MissingAt) zurückgegeben wird.

Aufteilung in mehrere Apps oder Crates

Wächst das Entwicklungsteam der App, kann es sinnvoll sein, das Team und auch die Anwendung in mehrere eigenständige Apps und Crates aufzuteilen. Ein Kontaktmanagement könnte die bisherige E-Mail-App erweitern und alle eingehenden Kontaktdaten speichern, aktualisieren oder löschen. Dabei bekommt das Kontaktmanagement eine eigene Crux-App, verwaltet in einem separaten Crate. Dieses separate Crate beinhaltet ein abgegrenztes Feature und wird auch als Feature-Crate bezeichnet. Jedes Feature-Crate definiert dabei seine eigenen Events, Models, ViewModels und Effekte – das Model ist also explizit Teil des jeweiligen Features. Die Haupt-App integriert die einzelnen Feature-Crates und koordiniert deren Zusammenspiel.

Listing 3: contacts (Feature-Crate)

// contacts/src/lib.rs
#[derive(Clone, Debug)]
pub struct Contact {
    pub name: String,
    pub email: EmailAddress,
}

pub enum ContactsEvent {
    AddContact(Contact),
    RemoveContact(EmailAddress),
    EditContact(EmailAddress, Contact),
}

#[derive(Default)]
pub struct ContactsModel {
    pub contacts: Vec<Contact>,
}

pub struct ContactsViewModel {
    pub contacts: Vec<Contact>,
}

pub enum ContactsEffect {
    ShowContactAdded(EmailAddress),
    ShowContactRemoved(EmailAddress),
}

pub fn update(event: ContactsEvent, model: &mut ContactsModel) -> Vec<ContactsEffect> {
    match event {
        ContactsEvent::AddContact(contact) => {
            model.contacts.push(contact.clone());
            vec![ContactsEffect::ShowContactAdded(contact.email)]
        }
        ContactsEvent::RemoveContact(email) => {
            model.contacts.retain(|c| c.email != email);
            vec![ContactsEffect::ShowContactRemoved(email)]
        }
        ContactsEvent::EditContact(email, new_contact) => {
            if let Some(c) = model.contacts.iter_mut().find(|c| c.email == email) {
                *c = new_contact.clone();
            }
            vec![]
        }
    }
}

pub fn view(model: &ContactsModel) -> ContactsViewModel {
    ContactsViewModel {
        contacts: model.contacts.clone(),
    }
}

Das E-Mail-Feature übernimmt die Funktion der bisherigen E-Mail-App:

Listing 4: email (Feature-Crate)

// email/src/lib.rs
pub enum EmailEvent {
    SendEmail(EmailAddress),
    EmailSent(bool),
}

#[derive(Default)]
pub struct EmailModel {
    pub last_sent: Option<EmailAddress>,
}

pub struct EmailViewModel {
    pub last_sent: Option<String>,
}

pub enum EmailEffect {
    SendEmailRequest(String),
}

Die Haupt-App aggregiert die Feature-Modelle und koordiniert die Kommunikation:

Listing 5: Haupt-App-Integration (App-Crate)

// app/src/lib.rs
use contacts::{ContactsEvent, ContactsModel, ContactsViewModel, ContactsEffect};
use email::{EmailEvent, EmailModel, EmailViewModel, EmailEffect};

pub enum AppEvent {
    Email(EmailEvent),
    Contacts(ContactsEvent),
}

pub struct AppModel {
    pub email: EmailModel,
    pub contacts: ContactsModel,
}

pub struct AppViewModel {
    pub email: EmailViewModel,
    pub contacts: ContactsViewModel,
}

pub enum AppEffect {
    Email(EmailEffect),
    Contacts(ContactsEffect),
}

pub fn update(event: AppEvent, model: &mut AppModel) -> Vec<AppEffect> {
    match event {
        AppEvent::Email(email_event) => {
            email::update(email_event, &mut model.email)
                .into_iter().map(AppEffect::Email).collect()
        }
        AppEvent::Contacts(contacts_event) => {
            contacts::update(contacts_event, &mut model.contacts)
                .into_iter().map(AppEffect::Contacts).collect()
        }
    }
}

pub fn view(model: &AppModel) -> AppViewModel {
    AppViewModel {
        email: email::view(&model.email),
        contacts: contacts::view(&model.contacts),
    }
}

Durch diese Aufteilung bleibt die Anwendung modular, testbar und erweiterbar. Jedes Feature verwaltet seinen eigenen Zustand und lässt sich unabhängig entwickeln, testen und warten. Die Haupt-App sorgt für die Orchestrierung und das Zusammenführen der einzelnen ViewModels zu einer konsistenten Oberfläche. So entsteht eine skalierbare Architektur.

Native Technologien

Um den Rust-Core in andere Sprachen und Plattformen (Crux nennt diesen Bereich Shell, siehe auch Teil 2 der Artikelserie [4]) einzubinden, stehen verschiedene Werkzeuge zur Verfügung. Zwei bekannte Ansätze sind das Tool uniFFI und das Crate serde_generate. In Kombination erreichen beide das Ziel, die Schnittstelle zwischen Rust und Fremdtechnologien wie Swift, Kotlin oder Python zu generieren.

uniFFI und serde_generate

Crux nutzt eine Kombination aus uniFFI und serde_generate. Beide Werkzeuge ergänzen sich optimal: uniFFI übernimmt die Bereitstellung der Schnittstellen in die jeweilige Fremdsprache – kurz als „bindgen“ bezeichnet. serde_generate ergänzt um die (komplexen) Typen wie Events, ViewModels oder Effekte und sorgt für die Serialisierung – kurz unter „typegen“ zusammengefasst.

uniFFI ist ein von Mozilla entwickeltes Tool, das automatisch FFI-Bindings (Foreign Function Interface) für verschiedene Zielsprachen generiert. Die Schnittstellen werden entweder in einer UDL-Datei (Universal Data Link, Interface-Definition) definiert oder – moderner und komfortabler – direkt über Rust-Macros wie #[uniffi::export]. So lassen sich Funktionen und Methoden in Rust markieren, die dann in Sprachen wie Swift, Kotlin oder C# verfügbar gemacht werden. Crux nutzt uniFFI, um die zentralen Funktionen wie process_event, handle_response und view für die Shell bereitzustellen.

serde_generate ergänzt uniFFI, indem es aus Rust-Typen die Serialisierungs- und Deserialisierungsroutinen sowie Typdefinitionen für andere Sprachen generiert. Damit lassen sich komplexe Datenstrukturen – etwa Events, ViewModels oder Effekte – zwischen Rust und der Fremdsprache austauschen. Die eigentliche Logik bleibt dabei in Rust, während die Daten in der Fremdsprache verarbeitet oder angezeigt werden können. Crux verwendet serde_generate, um sicherzustellen, dass die Typen in der Shell typsicher und idiomatisch zur Verfügung stehen.

Ein typischer Ablauf mit Crux, uniFFI und serde_generate sieht so aus:

Listing 6: uniFFI: process_event-Export

static CORE: LazyLock<Bridge<EmailApp>>
    = LazyLock::new(|| Bridge::new(Core::new()));

#[uniffi::export]
#[must_use]
pub fn process_event(data: &[u8]) -> Vec<u8> {
  match CORE.process_event(data) {
    Ok(effects) => effects,
    Err(e) => panic!("{e}"),
  }
}

In der Fremdsprache lässt sich die Funktion direkt aufrufen. Die Typen für Events, Effekte und ViewModels werden mithilfe von serde_generate in die Zielsprache übersetzt und stehen dort als native Klassen oder Strukturen zur Verfügung. So entsteht eine typsichere Integration.

Die folgenden Beispiele zeigen den Einsatz des generierten Codes für Events und den Aufruf der Funktion process_event in Kotlin, Swift und C#.

Kotlin (Android):

Listing 7: Kotlin: Event-Sealed Klassen und Aufruf

// Automatisch generiert durch serde_generate
sealed class Event : Serializable {
    data class ChangeEmail(val email: String) : Event()
    data class ChangeName(val name: String) : Event()
    object ApplyChanges : Event()
}

// Automatisch generiert durch uniFFI
external fun process_event(data: ByteArray): ByteArray

// Anwendung in Kotlin:
val event = Event.ChangeEmail("marcel.koch@example.org")
val serialized = Bincode.serialize(event)
val result: ByteArray = process_event(serialized)
val viewModel = Bincode.deserialize<ViewModel>(result)

In Kotlin werden die Events als versiegelte Klassen (Sealed Classes) abgebildet. Die Funktion process_event steht als native Funktion zur Verfügung. Die Kommunikation erfolgt über serialisierte ByteArrays. Das User Interface (UI) kann das zurückgegebene ViewModel direkt verwenden.

Swift (iOS/macOS):

Listing 8: Swift: Event-Enum und Aufruf

// Automatisch generiert durch serde_generate
public enum Event: Codable {
    case changeEmail(String)
    case changeName(String)
    case applyChanges
}

// Automatisch generiert durch uniFFI
@_cdecl("process_event")
public func process_event(_ data: Data) -> Data

// Anwendung in Swift:
let event = Event.changeEmail("marcel.koch@example.org")
let serialized = try Bincode.serialize(event)
let result: Data = process_event(serialized)
let viewModel = try Bincode.deserialize(ViewModel.self, from: result)

serde_generate bildet die Events in Swift als Enums mit assoziierten Werten ab. Die Funktion process_event nimmt das durch Bincode serialisierte Event entgegen und gibt das serialisierte ViewModel zurück. Das ViewModel steht nach der Deserialisierung als natives struct in Swift zur Verfügung.

C# (.NET MAUI, Windows etc.):

Listing 9: C#: Event-Klassen und Aufruf

// Automatisch generiert durch serde_generate
[Serializable]
public abstract class Event {
    public class ChangeEmail : Event {
        public string Email { get; set; }
    }
    public class ChangeName : Event {
        public string Name { get; set; }
    }
    public class ApplyChanges : Event {}
}

// Automatisch generiert durch uniFFI (über DllImport)
[DllImport("my_rust_lib")]
public static extern byte[] process_event(byte[] data);

// Anwendung in C#:
var eventObj = new Event.ChangeEmail { Email = "marcel.koch@example.org" };
var serialized = Bincode.Serialize(eventObj);
var result = process_event(serialized);
var viewModel = Bincode.Deserialize<ViewModel>(result);

serde_generate bildet die Events in C# als Klassenhierarchie ab. Die Funktion process_event wird über DllImport eingebunden und lässt sich wie eine normale Methode aufrufen. Die generierte Klasse Bincode deserialisiert ViewModel und stellt sie der Shell in C# zur weiteren Verwendung zur Verfügung.

WebAssembly mit wasm-pack

WebAssembly (Wasm) bringt die App direkt in den Browser. Am einfachsten lässt es sich mit wasm-pack nutzen. Ähnlich wie bei uniFFI verlangt wasm-pack ein Attribut an der Funktion: #[wasm_bindgen::prelude::wasm_bindgen].

Listing 10: wasm-pack: process_event-Export mit wasm_bindgen

static CORE: LazyLock<Bridge<EmailApp>>
    = LazyLock::new(|| Bridge::new(Core::new()));

#[cfg_attr(target_family = "wasm", wasm_bindgen::prelude::wasm_bindgen)]
#[cfg_attr(not(target_family = "wasm"), uniffi::export)]
pub fn process_event(data: &[u8]) -> Vec<u8> {
  match CORE.process_event(data) {
    Ok(effects) => effects,
    Err(e) => panic!("{e}"),
  }
}

Beide Attribute (uniFFI und wasm-pack) können die Funktion auszeichnen, um den Code für uniFFI und wasm-pack nutzbar zu gestalten. Die TypeScript-Seite kann die Funktion wie die anderen Fremdsprachen aufrufen, indem man serialisierte Objekte übergibt:

export function process_event(data: Uint8Array): Uint8Array;

Flutter Rust Bridge

Die Flutter Rust Bridge (FRB) schließt die Lücke zwischen Crux und Dart-Code in Flutter. FRB generiert automatisch die notwendigen Typen, Funktionen und Serialisierungen, sodass Dart/Flutter die Pendants der Rust-Typen (zum Beispiel Event oder ViewModel) direkt verwenden kann.

Beispiel: Anbindung von process_event

Listing 12: Flutter Rust Bridge: Rust-Seite

// src/lib.rs
use flutter_rust_bridge::frb;

#[derive(Debug, Clone, serde::Serialize, serde::Deserialize)]
pub enum Event {
    ChangeEmail(String),
    ChangeName(String),
    ApplyChanges,
}

#[derive(Debug, Clone, serde::Serialize, serde::Deserialize)]
pub struct ViewModel {
    pub name: String,
    pub email: String,
}

#[frb]
pub fn process_event(event: Event) -> ViewModel {
    // Event verarbeiten, ViewModel erzeugen
    // ...
    ViewModel { name: "Marcel".into(), email: "marcel.koch@example.org".into() }
}

Die Flutter Rust Bridge generiert eine Dart-API, mit der sich die Rust-Typen direkt verwenden lassen:

Listing 13: Flutter Rust Bridge: Dart-Seite

import 'package:my_crux_bridge/my_crux_bridge.dart';

Future<void> sendEvent() async {
  final event = Event.changeEmail('marcel.koch@example.org');
  final viewModel = await api.processEvent(event);
  // viewModel ist ein Dart-Objekt mit den Feldern name und email
  print('Name: ${viewModel.name}, Email: ${viewModel.email}');
}

Alternative zu serde_generate: facet_generate

Während serde_generate sowohl Typen als auch Code für die Serialisierung generiert, konzentriert sich facet_generate auf die reine Generierung der Typen und lässt die Serialisierung beiseite. Das kann wichtig sein, wenn mehrere Arten an Serialisierung umgesetzt werden sollen. Beispiele für mehrere Arten wären JSON, Protobuf und Binary Canonical Serialization (BCS). Auch die Kombination von facet_generate (Typen) und serde (Serialisierung ohne Typen) ist möglich.

Logging und Tracing in Crux-Apps

Um den Ablauf einer Crux-App verfolgen zu können, gibt es mehrere Ansätze. Üblicherweise kommen dabei Standard-Tools wie die Crates tracing oder env_logger zum Einsatz, die Log-Ausgaben und Tracing-Informationen direkt auf den Standard-Output schreiben. Diese Methode eignet sich besonders für die Entwicklung und das Debugging, da die Ausgaben unmittelbar sichtbar sind und sich mit bestehenden Rust-Ökosystem-Tools flexibel steuern lassen.

Ergänzend dazu kann ein eigener Effect die Tracing-Nachrichten aus dem Core an die Shell weitergeben. Dazu nimmt ein Tracing Layer und Subscriber die Nachrichten entgegen und leitet sie über einen Channel an den Effect. Die Shell entscheidet über die Weiterverarbeitung, wie das Schreiben in eine Datei oder in ein Analysetool.

Listing 14: Logging-Layer und Crux-Integration

use std::sync::mpsc::{Sender, Receiver, channel};
use tracing::{event, Event as TracingEvent, Subscriber};
use tracing_subscriber::Layer;
use crux_core::{Command, App};
use crux_core::capability::Operation;

#[derive(Debug, Clone)]
pub struct LogOp {
    pub level: String,
    pub message: String,
}

impl Operation for LogOp {
    type Output = ();
}

#[effect]
#[derive(Debug, Clone)]
pub enum Effect {
    Log(LogOp),
    // Weitere Effekte ...
}

#[derive(Debug, Clone)]
pub enum Event {
    // ... andere Events ...
    LogReceived(LogOp),
    ChangeEmail(String),
}

// Custom Layer für Tracing, der LogOp in einen Channel schreibt
pub struct ChannelLogLayer {
    pub sender: Sender<LogOp>,
}

impl<S: Subscriber> Layer<S> for ChannelLogLayer {
    fn on_event(&self, event: &TracingEvent<'_>, _ctx: tracing_subscriber::layer::Context<'_, S>) {
        let level = event.metadata().level().to_string();
        let mut message = String::new();
        event.record(&mut tracing_subscriber::fmt::MakeVisitor::new(&mut message));
        let op = LogOp { level, message };
        let _ = self.sender.send(op);
    }
}

// Initialisierung: Channel und Layer
let (log_sender, log_receiver): (Sender<LogOp>, Receiver<LogOp>) = channel();
let log_layer = ChannelLogLayer { sender: log_sender };
tracing_subscriber::registry().with(log_layer).init();

// In der Shell: Channel pollen und Event in die Crux-App einspeisen
loop {
    if let Ok(log_op) = log_receiver.try_recv() {
        // LogOp als Event in die Crux-App einspeisen
        core.process_event(Event::LogReceived(log_op));
    }
    // ... weitere Event-Loop-Logik ...
}

// Crux-App mit update-Methode gemäß Crux-API
impl App for EmailApp {
    // ...
    fn update(
    // ...
    ) -> Command<Self::Effect, Self::Event> {
        match event {
            Event::ChangeEmail(email) => {
                // Hier wird das Tracing-Event ausgelöst
                event!(tracing::Level::INFO, "E-Mail geändert: {}", email);
                // ...
            }
            Event::LogReceived(log_op) => {
                // Command an die Shell auslösen, LogOp enthält Level und Message
                Command::notify_shell(Effect::Log(log_op))
            }
            // ... andere Events ...
        }
    }
}

Erweiterte Konzepte und praktische Integration

Dieser finale Teil der Serie hat gezeigt, wie sich die Crux-Architektur für größere, komplexere Anwendungen erweitern lässt. Die Einführung fachlicher Typen wie EmailAddress demonstriert, wie man die domänenspezifische Logik unabhängig vom Framework entwickeln und testen kann.

Die modulare Aufteilung in mehrere Crates zeigt, wie sich die Architektur für Teams und größere Anwendungen skalieren lässt. Rust-Developer können jedes Feature unabhängig entwickeln, testen und warten, während die Haupt-App die Orchestrierung übernimmt. Diese Struktur ermöglicht es, komplexe Anwendungen übersichtlich und wartbar zu halten.

Die Integration in verschiedene Zielplattformen durch uniFFI, serde_generate, wasm-pack und Flutter Rust Bridge zeigt die Flexibilität des Ansatzes. Die automatische Generierung von Bindings für verschiedene Sprachen und Plattformen reduziert den Aufwand für die Integration erheblich und ermöglicht es, den Rust-Core in nahezu jeder Umgebung zu verwenden.

Logging und Tracing vervollständigen die Architektur. Die Möglichkeit, Log-Events als Effects zu behandeln, ermöglicht eine flexible und plattformunabhängige Behandlung von Protokollierungsanforderungen.

Nachhaltige Cross-Plattform-Entwicklung – mit Rust

Die drei Teile zusammen zeigen einen vollständigen Weg zu nachhaltiger Cross-Plattform-Entwicklung. Von den grundlegenden Konzepten über die praktische Umsetzung mit Crux bis hin zu erweiterten Konzepten für größere Anwendungen wird deutlich, wie sich langlebige Anwendungen mit Rust umsetzen lassen.

Die Kombination aus Rust als Core-Sprache, Crux als Framework und den vorgestellten Integrationsmöglichkeiten bietet einen robusten, wartbaren und zukunftssicheren Ansatz für die plattformübergreifende Entwicklung. Die explizite Trennung von fachlicher und technischer Logik, die modulare Architektur und die umfassende Testbarkeit machen diesen Ansatz robust, flexibel und nachhaltig.

Weitere spannende Themen

Die vorgestellten Konzepte lassen sich noch weiter ausbauen und erweitern. So könnte der Rust-Core auch bestehende C-Bibliotheken integrieren und als Brücke zwischen modernen Anwendungen und bewährten Legacy-Systemen dienen. Auch Mehrsprachigkeit kann auf elegante Weise gelöst werden, indem die Übersetzungen in die Bibliothek einkompiliert werden und so zusätzlich Dateien wegfallen. Ein weiterer Aspekt kann die Aufteilung der Logik zwischen Client und Server sein, was sowohl die Vorteile von Client-seitiger Reaktivität als auch von Server-seitiger Sicherheit und Performance nutzt.


URL dieses Artikels:
https://www.heise.de/-11273602

Links in diesem Artikel:

  1. https://www.heise.de/hintergrund/Cross-Plattform-Applikationen-mit-Rust-1-Langlebig-und-flexibel-10646857.html
  2. https://www.heise.de/hintergrund/Cross-Plattform-Applikationen-mit-Rust-2-Crux-im-Einsatz-11163186.html
  3. https://www.heise.de/hintergrund/Cross-Plattform-Applikationen-mit-Rust-3-Fachlichkeiten-und-Shell-Integration-11273602.html
  4. https://www.heise.de/hintergrund/Cross-Plattform-Applikationen-mit-Rust-2-Crux-im-Einsatz-11163186.html
  5. mailto:mdo@ix.de

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ c't-Themen

heise+ | Batteriewechselrichter im Labortest: Viel Verlust bei niedriger Leistung

Von Heise — 28. April 2026 um 13:00

Balkonkraftwerkspeicher mit billigem Strom laden, später verbrauchen: Ob sich das lohnt, wollten wir genau wissen und haben den Wirkungsgrad gemessen.

Energie geht in einem geschlossenen System nicht verloren, sie wird nur umgewandelt. Diesen physikalischen Grundsatz auf einen Batteriespeicher zu übertragen, wäre aber naiv: Ein solcher Speicher ist nämlich kein geschlossenes System, sondern ein ziemlich offenes – beim Laden und Entladen von Batterien geht immer Energie in Form von Wärme verloren. Das kann jeder Betreiber mit einfachem Handauflegen fühlen; fassen Sie beispielsweise auch mal Ihr Ladegerät an, wenn es das Smartphone gerade per Schnellladen vollgetankt hat. Ist Wandlungsverlust ein akademisches Problem? Mitnichten, denn dieser Verlust entscheidet maßgeblich, in welchen Szenarien ein solcher Speicher wirtschaftlich betrieben werden kann.

In unserem Vergleichstest von vier Balkonkraftwerkspeichern [1] [1] ging es vor allem um das Szenario, dass der Speicher mit Strom aus Photovoltaikmodulen geladen wird. Die getesteten Geräte sind so gebaut, dass man reichlich reichlich PV-Leistung anschließen kann: Hängt man an einen solchen Speicher vier Module mit zusammen über 1600 Watt, kommt an vielen Tagen im Jahr so viel Energie rein, dass die Akkus rasend schnell voll sind und der Wirkungsgrad beim Laden bei der Betrachtung der Wirtschaftlichkeit nicht ins Gewicht fällt.

Interessanter ist der Wirkungsgrad beim Entladen, und zwar gleich aus zwei Gründen. Viele Betreiber erhoffen sich von einem Speicher, den abendlichen und nächtlichen Bedarf zu decken: Kühlschrank, Router, Smart Home, Standby-Verluste. Investiert man auch in einen Zwischenzähler, kann ein Batteriespeicher passend regeln und die Leistung decken. Wie hoch der Bedarf ausfällt, ist schnell ermittelt: Am alten elektromechanischen Zähler ist das mit einer Ablesung am Abend und einer am Morgen getan. Die Leistung erhält man, indem man die Energie durch die verstrichene Zeit teilt. Bei digitalen Zählern erhält man die Leistung komfortabel über ein Auslesegerät mit magnetischem Lesekopf [7] [7]. In einer kleinen Wohnung mag dieser Verbrauch unter 100 Watt liegen, in einem Einfamilienhaus auch mal bei 200 Watt oder mehr. Also einfach einen Speicher kaufen, der den nächtlichen Bedarf decken kann? Nicht ganz, denn vor dem Kauf müsste man wissen, wie viel des eingespeicherten Stroms beim Entladen wieder herauskommt. Entscheidend wird diese Frage, wenn man vorhat, mit einem dynamischen Stromtarif in Zeiten billigen Netzstroms zu laden, um später am Tag keinen teuren Strom kaufen zu müssen. Doch wie effizient ist eigentlich ein solcher Batteriespeicher beim Entladen? Dieser Frage gehen wir im Folgenden nach.


URL dieses Artikels:
https://www.heise.de/-11265907

Links in diesem Artikel:

  1. https://www.heise.de/tests/XXL-Speicher-fuer-Balkonkraftwerke-im-Test-10640165.html
  2. https://www.heise.de/tests/Batteriewechselrichter-im-Labortest-Viel-Verlust-bei-niedriger-Leistung-11265907.html
  3. https://www.heise.de/ratgeber/Solaranlagen-im-Winter-Warum-Kaelte-gut-und-Schnee-oft-kein-Problem-ist-11135628.html
  4. https://www.heise.de/hintergrund/Guenstige-PV-Module-per-Gebrauchtmarkt-Perfekt-fuer-Bastler-riskant-fuer-Daecher-10442808.html
  5. https://www.heise.de/hintergrund/PV-Heimspeicher-mit-Netzstrom-laden-Was-moeglich-ist-und-ob-es-sich-lohnt-10278256.html
  6. https://www.heise.de/tests/Smarter-Wechselrichter-SolarFlow-800-mit-Akkuanschluss-von-Zendure-im-Test-10319731.html
  7. https://www.heise.de/-11193106.html

Copyright © 2026 Heise Medien

Adblock test (Why?)

✇ Golem.de Full über fivefilters.org

Mehr Qubits: Cisco stellt Quanten-Switch Für Quanten-Clustercomputer vor

Von Johannes Hiltscher — 28. April 2026 um 13:50
Clustercomputer waren für Supercomputer ein bahnbrechender Ansatz. Cisco erwartet von dem Konzept den Durchbruch für Quantencomputer .
Dieser Chip steckt in Ciscos Quanten-Switch. (Bild: Cisco Systems)
Dieser Chip steckt in Ciscos Quanten-Switch. Bild: Cisco Systems

Wenn große Computer zu aufwendig oder zu teuer zu bauen sind, nimm einfach viele einfache, günstige und schalte sie per Netzwerk zusammen. So etwa lässt sich in einem Satz das Konzept der Clustercomputer zusammenfassen. Nach diesem Prinzip funktioniert heute jeder Supercomputer, und wenn Cisco Recht behält, auch der erste praktisch nutzbare Quantencomputer.

Zumindest die Netzwerk-Hardware ist schon einmal da: Cisco hat den ersten Quanten-Switch vorgestellt . Dessen Prinzip unterscheidet sich grundlegend von klassischen Netzwerk-Switches: Während die ein Datenpaket von einem Computer annehmen und es an einen anderen weiterleiten, tauscht der Quanten-Switch den Zustand verschränkter Photonen. Die werden von den Kommunikationspartnern an ihn geschickt.

Über die verschränkten Photonen können die vernetzten Quantencomputer den Zustand von Qubits austauschen. Und das ohne Messung, welche den Zustand auf einen der Grundzustände festlegen würde. Das ermöglicht, dass mehrere Quantencomputer gemeinsam ein Problem bearbeiten. So addiert sich die Anzahl ihrer Qubits. Einen Chip für die Erzeugung verschränkter Photonen hatte Cisco 2025 vorgestellt .

Eingebauter Übersetzer für Codierung

Der Universal Quantum Switch ermöglicht dabei eine einfachere, sternförmige Vernetzung. Bislang müssen Quantencomputer direkt verbunden werden, um zu kommunizieren, was kaum skalierbar ist.

Dass der Cluster-Ansatz mittelfristig wohl die einzige realistische Möglichkeit ist, für reale Probleme nutzbare Quantencomputer zu bauen, sieht auch IBM so . Mehr als wenige Zehntausend Qubits pro Computer sind zeitnah nicht absehbar, Hunderttausende bis Millionen wären für reale Probleme erforderlich.

Während die Photonenquelle bei Raumtemperatur arbeitet, muss der Switch gekühlt werden. Er nutzt einen supraleitenden Nanodrahtdetektor. Die Hardware kann laut Cisco die üblichsten Qubit-Codierungen umwandeln, so dass Quantencomputer und -sensoren unterschiedlicher Hersteller verbunden werden können. Das soll nicht nur das Zusammenschalten von Quantencomputern mit unterschiedlichem Funktionsprinzip, sondern auch die geteilte Nutzung etwa von Sensoren ermöglichen.

Aktuell handelt es sich beim Universal Quantum Switch noch um einen Prototyp. Details haben Ciscos Forscher in einer über Arxiv abrufbaren Veröffentlichung geteilt. Die Austauschfrequenz ist mit maximal 470 Austauschoperationen pro Sekunde auf kurze Distanz aktuell noch nicht allzu hoch – aber höher als zuvor demonstriert. Über eine Distanz von 17,6 km wurde eine Austauschfrequenz von 0,65 erreicht, bessere Detektoren ermöglichen hier noch eine Steigerung.

Adblock test (Why?)

✇ Golem.de Full über fivefilters.org

Anzeige: 360°-Überwachungskamera bei Amazon für keine 23 Euro

Von Martin Deiß — 28. April 2026 um 13:44
Aktuell gibt es bei Amazon die Tapo C201 im Angebot. Die 360°-Überwachungskamera ist für keine 23 Euro erhältlich.
Bei Amazon gibt es derzeit die Tapo C201 im Angebot. Sie ist für keine 23 Euro erhältlich. (Bild: Amazon, Tapo) amazon Affiliate

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.

Bei Amazon gibt es derzeit die Tapo C201 im Angebot. Sie ist für keine 23 Euro erhältlich. Bild: Amazon, Tapo

Überwachungskameras für den Innenbereich eignen sich nicht nur, um die Wohnung bei Abwesenheit im Blick zu behalten, sie können auch als Babyphone-Ersatz oder zum Beobachten von Haustieren genutzt werden. Obwohl vielseitig einsetzbar, muss eine entsprechende Kamera kein Vermögen kosten. So gibt es bei Amazon derzeit die Tapo C201 zum Sparpreis im Angebot. Sie ist gegenüber der unverbindlichen Preisempfehlung von 26,99 Euro um 15 Prozent reduziert und kostet damit nur noch 22,94 Euro.

Ein guter Deal, wie das Preisvergleichsportal Geizhals zeigt. Ein Händler bietet die Kamera aktuell zwar für nur 19,21 Euro an, verlangt aber Versandkosten in Höhe von 7,47 Euro. Damit liegt der Endpreis bei 26,68 Euro. Damit lohnt sich das Amazon-Angebot zumindest für Prime-Kunden mehr.

Das hat die Überwachungskamera von Tapo zu bieten

Die Tapo C201 zeichnet Videos mit einer Auflösung von 1.920 × 1.080 Pixeln auf. Das Bild dürfte ausreichend scharf sein, um Bewegungen, Personen und größere Details zuverlässig zu erkennen.

Auch eine Infrarot-Nachtsicht in Schwarz-Weiß ist an Bord. Diese soll laut Hersteller eine Reichweite von bis zu zwölf Metern erreichen.

Privatsphäre und Aktivitätszonen

Dadurch, dass sich die Kamera horizontal um 360 Grad und vertikal um 114 Grad bewegen kann, lässt sich mit ihr ein Raum nahezu vollständig erfassen. Damit dabei die Privatsphäre gewahrt wird, ist es möglich, Bereiche festzulegen, die ausgespart werden.

Außerdem lassen sich Aktivitätszonen definieren: Die Kamera ist in der Lage, Bewegungen zu erkennen und in einem solchen Fall eine Smartphone-Benachrichtigung zu senden.

Zwei-Wege-Kommunikation und Babyphone-Ersatz

Die Tapo C201 ist sowohl mit einem Mikrofon als auch mit einem Lautsprecher ausgestattet. So ist es über das Smartphone möglich, zu hören, was im Raum passiert, und mit Personen oder Haustieren zu kommunizieren.

Daneben soll die Kamera auch Babygeschrei erkennen und dadurch als Babyphone-Ersatz genutzt werden können.

Speichermöglichkeiten und Smart-Home-Integration

Aufnahmen können lokal auf einer Micro-SD-Karte mit einer Kapazität von bis zu 512 GB gespeichert werden. Alternativ steht mit Tapo Care ein kostenpflichtiger Cloud-Speicherdienst zur Verfügung, der auch zusätzliche Funktionen wie eine Video-Historie oder erweiterte Benachrichtigungen bietet.

Neben der Smartphone-App kann die Tapo C201 auch per Sprachbefehl gesteuert werden. Sie ist mit Alexa und Google Assistant kompatibel und kann somit auch in bestehende Smart-Home-Systeme integriert werden.

Gute Bewertungen und aktuelles Angebot

In der Praxis scheint die Überwachungskamera überzeugen zu können. Das lassen zumindest die Amazon-Bewertungen vermuten. Bei bisher 1.131 Bewertungen erreicht sie gute 4,5 von 5 Sterne.

Aktuell gibt es die Kamera bei Amazon im Angebot

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
. Sie ist mit 15 Prozent Rabatt auf die unverbindliche Preisempfehlung von 26,99 Euro und damit für nur 22,94 Euro erhältlich.

Tapo C201 360° WLAN-Überwachungskamera für Innenräume

Jetzt im Angebot sichern

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.

Von Tapo gibt es noch viele weitere Smart-Home-Gadgets zu entdecken. Eine Übersicht liefert der Amazon-Store von Tapo

Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
. Für den Vergleich verschiedener Sicherheitskameras empfiehlt sich die Bestsellerliste Überwachungskameras
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
. Hier sind zahlreiche Modelle aufgelistet, sortiert nach ihrer aktuellen Beliebtheit bei Amazon-Kunden.

Adblock test (Why?)

✇ Golem.de Full über fivefilters.org

Nordsee-Windparks: BP und Total wollen Windkraftausbau ausbremsen

Von Friedhelm Greis — 28. April 2026 um 13:40
Mineralölkonzerne haben Milliarden in Nordsee- Windparks investiert. Nun wollen sie die Vergabe weiterer Flächen verzögern.
Windparks in der Nordsee sind eine recht zuverlässige erneuerbare Energiequelle. (Bild: dpa/Picture Alliance/Reuters)
Windparks in der Nordsee sind eine recht zuverlässige erneuerbare Energiequelle. Bild: dpa/Picture Alliance/Reuters

Die Mineralölkonzerne BP und Total drängen auf eine Verlangsamung des Windkraftausbaus in der Nordsee. Das berichtet der NDR unter Berufung auf entsprechende Pläne der beiden Unternehmen. Diese befürchten, dass neue Windkraftanlagen den Ertrag der eigenen Windparks schmälern könnten.

BP und Total ersteigerten im Juli 2023 für jeweils 6,74 beziehungsweise 3,75 Milliarden Euro die Rechte an drei Nordsee-Windparks mit einer Erzeugungsleistung von jeweils 2 Gigawatt. Total ersteigerte im Juni 2024 für knapp zwei Milliarden Euro eine weitere Lizenz für 1,5 Gigawatt Leistung. "Die Erlöse aus den Offshore-Ausschreibungen fließen zu 90 Prozent in die Stromkostensenkung und zu jeweils fünf Prozent in den Meeresnaturschutz sowie die Förderung einer umweltschonenden Fischerei" , schrieb die Bundesnetzagentur damals.

Windparkausbau gesetzlich vorgeschrieben

Dem NDR-Bericht zufolge drängen BP und Total nun darauf, den aktuellen Flächenentwicklungsplan (PDF) des Bundesamts für Seeschifffahrt und Hydrografie (BSH) abzuändern. Demnach soll die geplante Kapazität von 70 Gigawatt erst im Jahr 2057 und nicht schon im Jahr 2041 erreicht werden.

Allerdings widerspricht dies der gesetzlichen Vorgabe des sogenannten Windenergie-auf-See-Gesetzes , das in Paragraf 1 vorschreibt: "Ziel dieses Gesetzes ist es, die installierte Leistung von Windenergieanlagen auf See, die an das Netz angeschlossen werden, auf insgesamt mindestens 30 Gigawatt bis zum Jahr 2030, auf insgesamt mindestens 40 Gigawatt bis zum Jahr 2035 und auf insgesamt mindestens 70 Gigawatt bis zum Jahr 2045 zu steigern."

Pläne führen zu weniger Windstrom

BP und Total begründen ihre Forderung mit einer Studie des Fraunhofer Instituts für Windenergiesysteme (IWES). Demnach führt der Windschatten der zusätzlich geplanten Windparks dazu, dass die eigenen Anlagen nicht so effizient betrieben werden können. Dadurch amortisierten sich die Investitionen später. Die Studie geht ohne den Windschatten von zwei bis zehn Prozent höheren Erträgen in den Flächen aus, die von BP und Total erworben wurden.

Allerdings halte die Studie fest, dass insgesamt deutlich weniger Windstrom produziert werde und die Erträge zeitweise um ein Drittel sinken könnten. "Der Re-Order-Plan führt natürlich zu einem deutlichen Einbruch der Offshore-Windenergieerträge in der deutschen Nordsee insgesamt" , sagte Co-Autor Bernhard Stoevesandt vom Fraunhofer IWES und fügte hinzu: "Das ist eine Abwägung zwischen: Wie sehr soll sich das für die Firmen lohnen? und: Wie viel Strom soll der Offshore-Wind der Gesellschaft bringen?"

Total Energies bezeichnete auf NDR-Anfrage die Studie als proaktiven Vorschlag, die Windenergie auf See effizienter und damit günstiger für die Stromkunden zu machen. Die Vorschläge kämen "bereits gebauten, bereits bezuschlagten, aber auch zukünftigen Flächen zugute" . Mögliche Mindererträge in der Stromerzeugung könnten über einen höheren Zubau in den Nachbarstaaten kompensiert werden.

Die zuständige BSH-Referatsleiterin Lea Haefke verwies dem Bericht zufolge darauf, dass die Abschattungseffekte bereits bekannt gewesen seien, als die Unternehmen Milliarden für die Flächen in der Nordsee geboten hätten. Die Berechnungen seien jedoch ökonomisch nachvollziehbar.

Um die Forderungen umzusetzen, müssten der Flächenentwicklungsplan und das Windenergie-auf-See-Gesetz geändert werden, was in diesem Jahr ohnehin noch geplant sei. Daher seien die Firmen schon beim Bundeswirtschaftsministerium vorstellig geworden. Allerdings gibt es aus der Koalitionsfraktion Kritik an dem Vorstoß. Es sei zwar sinnvoll, Abschattungseffekte zu vermeiden, sagte die energiepolitische Sprecherin der SPD-Fraktion, Nina Scheer. Das dürfe aber "unterm Strich nicht zu einem Minus an Erträgen führen oder die Ausbauziele in Menge und Zeit verfehlen lassen" .

Offshore-Wind am verlässlichsten

Die Nordsee gilt als eines der weltweit am besten geeigneten Gebiete für Offshore-Windparks. Die Wassertiefe ist gering, während der Wind verlässlich, aber fast nie zu stark weht.

Blickt man auf die Daten zur Stromeinspeisung ins deutsche Netz, konnten etwas mehr als 7 GW Windkraftleistung eine Energiemenge von 21 Terawattstunden beitragen. Das entspricht ungefähr dem Doppelten eines Windrades an Land. Auch die Zeiten, in denen gar kein Strom aus Offshore-Windparks gewonnen werden kann, sind deutlich kürzer als an Land. Die Anrainerstaaten wollen bis zum Jahr 2050 eine Windkraftleistung von 300 Gigawatt in der Nordsee installieren .

Adblock test (Why?)

❌