Anmelden
Streamen auf Reisen scheitert oft, weil die Dienste aufs Heimatland eingeschränkt sind. Ein Fritz-VPN-Reiserouter hilft. Wir zeigen, wie Sie ihn einrichten.
Streamen unterwegs wird schwierig, wenn der Anbieter seinen Dienst aufs Heimatland oder gar die Heimatregion des Kunden beschränkt und keine Mediendaten rausrückt, wenn Sie anderswo unterwegs sind. Das gilt nicht nur bei den üblichen Verdächtigen, also Netflix und Co. Auch die Mediatheken der öffentlich-rechtlichen Sender könnten solche Streamingwünsche zurückweisen. Der klassische Weg, aus diesem Gehege auszubrechen, führt über bezahlte VPNs darauf spezialisierter Anbieter. Doch die muss man auf jedem Gerät einzeln einrichten. Das geht mit passender Hardware einfacher und langfristig preisgünstiger.
Ein Reiserouter als VPN-Zentrale mit Verbindung zum eigenen Heimrouter versorgt per WLAN gleich mehrere Clients. Deren Konfiguration beschränkt sich damit auf das Herstellen einer WLAN-Verbindung. Solch ein Gerät muss kein Vermögen kosten: Eine gebrauchte Fritzbox 4040 ist für 30 bis 40 Euro zu haben und hat im Winter 2025 noch ein FritzOS-Update auf Version 8.03 bekommen. Die jüngere Fritzbox 4050 reißt als Neugerät mit 120 Euro oder gebraucht ab 90 Euro zwar ein größeres Loch in die Kasse. Sie funkt aber auch mit Wi-Fi 6, was in dichter besiedelten Gegenden vorteilhaft ist, und dürfte noch länger mit FritzOS-Updates versorgt werden.
Zunächst sei kurz umrissen, was erreicht werden soll: Der Reiserouter erhält seinen Internetzugang vom Netz der Unterkunft. Gibt es im Zimmer Netzwerkanschlüsse, verbindet man den WAN-Port des Reiserouters per Patchkabel mit einem der Ports. Hängt ein Access-Point vor der Tür, nimmt der Reiserouter per WLAN damit Verbindung auf.
URL dieses Artikels:
https://www.heise.de/-11112413
Links in diesem Artikel:
[1] https://www.heise.de/ratgeber/Fritzbox-als-Reiserouter-Unterwegs-online-wie-daheim-11112413.html
[2] https://www.heise.de/ratgeber/Router-austauschen-So-schlaegt-sich-die-alte-Fritzbox-7490-gegen-ihre-Nachfolger-11196149.html
[3] https://www.heise.de/hintergrund/Routerdefekte-durch-falsche-Kondensatoren-auch-bei-Fritzbox-6890-LTE-11086055.html
[4] https://www.heise.de/ratgeber/FritzOS-Version-8-20-Ausfallschutz-und-Neuerungen-in-der-kommenden-Firmware-10400083.html
[5] https://www.heise.de/tests/Fritzbox-5690-Pro-im-Test-AVMs-erster-Router-mit-DSL-und-Glasfasermodem-9799123.html
[6] https://www.heise.de/tests/Fritzbox-7690-im-Test-AVMs-schneller-DSL-Router-mit-Wi-Fi-7-9770521.html
Copyright © 2026 Heise Medien
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Google AI Edge Eloquent: Ein Chatbot ist die App nicht (hier auf dem Mac).
Das kleinere KI-Modell des Suchriesen läuft lokal auf iOS und Mac und macht damit Whisper Konkurrenz. Für mehr braucht es aber die Cloud.
Der Name wirkt zwar etwas sperrig, doch Googles jüngste iOS-App namens Google AI Edge Eloquent [1] kann im Alltag durchaus nützlich sein: Mit dem kostenlosen Tool kann man ohne Abogebühr auf iPhone und Mac Spracheingaben in hoher Qualität in Textform umwandeln. Dazu nutzt die App das hauseigene freie Sprachmodell Gemma, das wiederum auf Googles großen Gemini-Modellen basiert.
Neben der Diktatfunktion kann Edge Eloquent noch mehr: Verlässt man den Offline-Modus, kann die App den erfassten Text auch automatisch bereinigen und in Form bringen. „[Die App] wandelt unstrukturierte und stockende Sprache automatisch in fehlerfreien Text um, wobei sie den Kontext versteht, um die eigentliche Bedeutung wiederzugeben“, schreibt Google in seinem Beipackzettel. Parallel ist es möglich, ein eigenes Wörterbuch zu erstellen, um das Vokabular des Nutzers besser zu erkennen. Das gesamte maschinelle Lernen läuft dabei auf dem iPhone oder Mac ab, auch Audio oder andere persönliche Daten sollen nicht bei Google landen.
Im Kurztest zeigte sich dann allerdings, dass die App für eine ganze Reihe von Features doch Googles Cloud benötigt, etwa zum weiteren Polieren der Texte. Immerhin gibt es einen klar ersichtlichen Cloud-Schalter, über den gesteuert werden kann, was im Internet landet und was nicht. Nützlich: Die App wirft automatisch Ähs und Ahs aus der Transkribierung und kann zudem erkennen, wenn sich der Nutzer selbst korrigiert und nur die korrekte Fassung übernehmen. Gemma soll dabei auch auf älteren iPhones ausreichend schnell sein – ab dem iPhone 15 wird sie empfohlen. Google verspricht darüber hinaus eine „Zero Cost Architecture", bei der Nutzer nichts zu zahlen haben und es keine Nutzungslimits geben soll.
Google AI Edge Eloquent läuft anfangs nur als App, soll aber in späteren Versionen über eine eigene Zusatztastatur tiefer in iOS integriert werden können. Wie genau dies umgesetzt wird, blieb zunächst unklar. Google macht mit der Anwendung offenen Transkribierungsmodellen wie Whisper von OpenAI Konkurrenz, das bereits in vielen iOS-Apps aus dem Diktierbereich steckt.
Einen zentralen Nachteil gibt es allerdings noch: Die App versteht derzeit im Gegensatz zu Whisper-basierten Anwendungen nur die englische Sprache für das Diktat. Wer es in Deutsch oder anderen Sprachen probiert, scheitert. Folgerichtig steht sie derzeit auch nur im US-amerikanischen App Store zum Download bereit. Eine weitere Gemma-basierte App namens Google AI Edge Gallery [2] bietet Zugriff auf weitere Gemma-4 [3]-Funktionen, darunter einen Chatbot, agentische Funktionen und Bilderkennung. Die App ist auch für Android verfügbar, Google AI Edge Eloquent hingegen nur für Apple-Geräte.
URL dieses Artikels:
https://www.heise.de/-11247707
Links in diesem Artikel:
[1] https://apps.apple.com/us/app/google-ai-edge-eloquent/id6756505519
[2] https://apps.apple.com/de/app/google-ai-edge-gallery/id6749645337
[3] https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/
[4] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[5] https://www.heise.de/mac-and-i
[6] mailto:bsc@heise.de
Copyright © 2026 Heise Medien
WhatsApp auf einem Smartphone
(Bild: PixieMe / Shutterstock.com)
WhatsApp beginnt mit der Einführung von Usernamen. Damit erfüllt Meta einen lang gehegten Wunsch der Nutzer, die App ohne Preisgabe der Telefonnummer zu nutzen.
Drei Jahre hat WhatsApp die Funktion in Betatests erprobt [1], jetzt wurde offenbar damit begonnen, die Nutzung von Usernamen für erste Nutzer einzuführen. Dies berichtet das Blog WABetaInfo [2], das regelmäßig über Veränderungen in dem beliebten Messenger berichtet. Angeblich steht die Funktion aktuell nur sehr wenigen Nutzern zur Verfügung und soll langsam in den Apps für Android und iOS ausgerollt werden.
Mit der Alternative eines Nutzernamens erfüllt WhatsApp einen oft gehörten Wunsch. Durch seine Verwendung müssen Nutzer anderen nicht mehr ihre Mobilfunknummer kundtun, die bislang verwendet wurde, um User im Netzwerk zu finden oder ihnen Nachrichten zu schreiben. Der quelloffene Messenger Signal bietet eine solche Funktion bereits seit dem Frühjahr 2024 allen seinen Nutzern an. Meta hingegen hat sich sehr viel Zeit gelassen.
Ob man zum erlesenen Kreis derer gehört, die bereits einen Username einstellen können, ist in den Profileinstellungen ersichtlich. Taucht dort ein neues Feld für den Nutzernamen auf, kann dieses direkt angetippt werden, um diesen festzulegen. Wer nichts angezeigt bekommt, muss sich noch in Geduld üben. Meta selbst hat sich bislang nicht zum Rollout geäußert. Bereits im Oktober 2025 tauchte eine Funktion zur Reservierung von Nutzernamen in Betaversionen auf [3].
Laut WABetaInfo [4] können nur Nutzernamen neu ausgewählt werden, die noch nicht in den anderen Meta-Netzwerken Facebook und Instagram existieren. Es ist allerdings möglich, den gleichen Nutzernamen zu wählen, wenn man diesen schon in den anderen beiden Netzwerken besitzt. Hierfür sei aber über ein Account Center ein Nachweis nötig. Erst dann sei die Übernahme auf WhatsApp möglich. Die Verwendung eines übergreifenden Nutzernamens ist allerdings mit dem Risiko verknüpft, dass andere etwa auf Grundlage des Instagram-Kontonamens auch auf den WhatsApp-Nutzernamen eines Users schließen können.
Wer sich Kontaktanfragen über den Usernamen vom Leib halten möchte, kann einen Code einstellen. Nur wer Nutzernamen und Code kennt, kann dann einen Erstkontakt herstellen. Dies soll gegen Spam und Stalking helfen.
WhatsApp-Nutzernamen dürfen laut WABetaInfo drei bis 35 Zeichen lang sein und nur aus Kleinbuchstaben, Ziffern, Punkten und Unterstrichen bestehen. Die Anmutung einer Domain oder das Präfix „www.“ sind untersagt. Außerdem muss ein Nutzername mindestens einen Buchstaben enthalten.
URL dieses Artikels:
https://www.heise.de/-11249443
Links in diesem Artikel:
[1] https://www.heise.de/news/WhatsApp-soll-Nutzernamen-mit-PIN-Schutz-erhalten-9842293.html
[2] https://wabetainfo.com/whatsapp-is-rolling-out-the-username-feature-on-android-and-ios/
[3] https://www.heise.de/news/WhatsApp-Beta-Version-bringt-Nutzernamen-Reservierung-10747957.html
[4] https://wabetainfo.com/whatsapp-is-rolling-out-the-username-feature-on-android-and-ios/
[5] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[6] mailto:mki@heise.de
Copyright © 2026 Heise Medien
Radiologie-Anwendung mit dem Pro Display XDR.
(Bild: Apple)
Dank passender Kalibrierung lässt sich Apples neues Top-Display auch im Medizinbereich verwenden. Hier soll es sogar ein Schnäppchen sein.
Mediziner, die Apple-Technik in der Praxis einsetzen, können das kürzlich erschienene Studio Display XDR [1] in einem ersten Markt auch professionell nutzen: Der Bildschirm bekam in den Vereinigten Staaten nun die Zulassung der Food and Drug Administration (FDA) zum Einsatz in der Radiologie. Damit kann der Screen in der Diagnostik verwendet werden. Laut Apple-Marketingchef Greg Joswiak muss dazu auf dem Mac macOS 26.4 [2] laufen. „Das heißt, dass Radiologen jetzt den weltbesten Pro-Bildschirm im Bereich der allgemeinen Radiologie einsetzen können.“ Es sei „fantastisch, diese Überschneidung von Gesundheit und Technik zu sehen“, lobte er.
Das Studio Display XDR ist einer von zwei neuen Bildschirmen [3], die Apple im März vorgestellt hatte. Während das Studio Display 2026 nur minimale Verbesserungen wie Thunderbolt 5 erhielt, kommt das Studio Display XDR mit bis zu 2000 Lux, 120 Hertz und 2304 Mini-LEDs als Backlight. Diese Funktionen sind es auch, die die medizinische Nutzung erlauben. So wird der DICOM-Standard für die Anzeige von Inhalten aus bildgebenden Verfahren ebenso unterstützt wie eine Kalibrierung mit Medical-Imaging-Calibrator.
Günstig ist das Studio Display XDR zwar mit mindestens 3399 Euro (ohne Ständer und mit VESA-Mount [4]) nicht, doch im Wettbewerb mit professionellen Bildschirmen für den medizinischen Bereich ist dieser Preis geradezu ein Schnäppchen – besonders wenn man 5K-Auflösung und Helligkeit einberechnet. Allerdings ist der Screen mit 27 Zoll relativ klein geraden, das Pro Display XDR [5], zuletzt völlig veraltet, hatte Apple mit seinen knapp 32 Zoll ersatzlos aus dem Programm gestrichen.
Apple hatte bereits zuvor mitgeteilt, dass man DICOM-Fähigkeit und medizinische Kalibrierung anstrebt, mit der FDA-Zulassung sind sie nun offiziell. Für DICOM bietet macOS in der aktuellen Version passende Presets, die sich durch die Systemeinstellungen auswählen lassen. Apple bereitet offenbar auch eine Zertifizierung in weiteren Ländern vor, darunter vermutlich Europa. Auch hier könnte der Konzern mit dem Screen im Radiologie-Bereich punkten.
Das Studio Display XDR spielt seine Vorteile allerdings nur mit passenden Macs aus. So sind nur Apple-Silicon-Geräte überhaupt kompatibel [6], 120 Hertz unterstützen nur neuere Macs beziehungsweise bessere ausgestattete Maschinen. M1, M1 Pro, M1 Max, M1 Ultra, M2 und M3 stellen nur 60 Hertz dar.
URL dieses Artikels:
https://www.heise.de/-11248314
Links in diesem Artikel:
[1] https://www.heise.de/tests/Apple-Studio-Display-XDR-im-Test-Referenz-mit-doppeltem-Hertzschlag-11227427.html
[2] https://x.com/gregjoz/status/2041586768806604896
[3] https://www.heise.de/tests/Studio-Display-2026-im-Test-5K-Mattscheibe-mit-Thunderbolt-5-11204379.html
[4] https://www.heise.de/news/Studio-Display-XDR-Apple-reduziert-Preis-mit-VESA-Mount-deutlich-11243501.html
[5] https://www.heise.de/tests/Fuenf-gegen-6K-Apples-Pro-Display-XDR-gegen-andere-Monitore-4659309.html
[6] https://www.heise.de/news/Neue-Studio-Displays-Kein-Intel-Support-und-ein-120-Hertz-Problem-11198029.html
[7] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[8] https://www.heise.de/mac-and-i
[9] mailto:bsc@heise.de
Copyright © 2026 Heise Medien
Ohne Schuhe zum Sehnsuchtsort. Fernreisen bleiben teuer. Bild: Shutterstock.com
Kerosinpreise reagieren verzögert: Gestörte Raffinerien, längere Flugrouten und fehlende Kapazitäten treiben Ticketpreise weiter nach oben.
Die zweiwöchige Waffenruhe im Irankrieg, von der heute weltweit berichtet wird, hat die Rohölpreise deutlich sinken lassen. Laut einem Bericht der türkischen Nachrichtenagentur Yenişafak [1] unter Berufung auf die International Air Transport Association (IATA) fielen die Preise um rund 15 Prozent.
Allerdings sind noch ein paar entscheidende Fragen offen, wie aus den aktuellen Meldungen zur Waffenruhe zu erfahren ist. So berichtet die Tagesschau heute Mittag:
"Auch was die von den USA geforderte Öffnung der Straße von Hormus angeht, bleiben Fragen offen. Der iranische Außenminister Abbas Araghtschi erklärte, die Durchfahrt durch die Straße werde unter iranischer Militärverwaltung erlaubt sein. Ob dies bedeutet, dass der Iran seine Kontrolle über die Wasserstraße vollständig aufgeben wird, ist unklar.“
Tagesschau [2], 08.04.2026
Durch die Meerenge läuft ein Fünftel des weltweiten Öl- und Gastransports. Trotz der Aussichten auf eine Öffnung warnt IATA-Generaldirektor Willie Walsh [3], dass sich Flugtreibstoffversorgung und Kerosinpreise erst nach Monaten normalisieren werden – selbst wenn Rohöl wieder fließt.
IATA-Generaldirektor Willie Walsh erklärte am Mittwoch in Singapur vor Journalisten, es sei schwer zu sagen, wie lange die Erholung dauern werde, aber "das wird nicht schnell gehen [4]".
Die Versorgung werde noch Monate brauchen, um das erforderliche Niveau zu erreichen, "angesichts der Störungen der Raffineriekapazitäten im Nahen Osten". Walsh betonte gegenüber Reportern:
"Ich glaube nicht, dass das in Wochen passiert."
Auch wenn der Fluss von Rohöl wieder einsetze, bleibe das Problem bestehen, solange es Störungen bei den Raffineriekapazitäten gegeben habe. "Ich glaube nicht, dass allen vollständig bewusst war, wie stark die Kapazitäten in bestimmten Teilen der Welt konzentriert sind", fügte er hinzu.
Dem Luftfahrtdatendienst OAG [5] zufolge lagen die niedrigsten verfügbaren Economy-Tarife in den ersten elf Wochen 2026 im Schnitt 24 Prozent über Vorjahr.
Erfahrungen aus der Vergangenheit zeigten laut Walsh, dass die Luftfahrtindustrie auf höhere Ölpreise mit steigenden Ticketpreisen reagiere. "Das ist unvermeidlich [6]", sagte er. Die Herausforderung für die Branche liege in der zeitlichen Verzögerung zwischen Preisbewegungen auf den Energiemärkten und deren Auswirkung auf die tatsächlichen Einnahmen der Fluggesellschaften.
Selbst bei geöffneter Meerenge werde es Zeit brauchen, bis Raffineriekapazitäten, Logistik und durch Wochen des Konflikts gestörte Lieferketten wieder das Vorkriegsniveau erreichen.
Treibstoff mache rund 20 bis 25 Prozent der Betriebskosten von Airlines aus, wie mehrere Hintergrundquellen berichten.
Für EU-Airlines hätten sich Flüge nach Asien wegen Umwegen derzeit um ein bis drei Stunden verlängert; der Treibstoffverbrauch liege dadurch um zehn bis 25 Prozent höher, so die Frankfurter Rundschau [7].
Ein Teil des Flugverkehrs, der sonst durch den Nahen Osten verlaufen wäre, wurde laut Walsh zu Fluggesellschaften außerhalb der Region verlagert. Dies sei jedoch "ein vorübergehendes Problem". Es gebe keine Möglichkeit, dass sie die Kapazitäten ersetzen können, die von den Golf-Airlines bereitgestellt wurden, fügte er hinzu.
Die US-Energiebehörde EIA [8] erwartet selbst bei Wiederaufnahme der Schifffahrt durch Hormus keine rasche Rückkehr zum Vorkriegsniveau. In ihrer jüngsten Prognose normalisieren sich die Ölströme erst bis Ende 2026.
Airlines können steigende Kosten über Treibstoffzuschläge, höhere Grundpreise, Zusatzgebühren oder Kapazitätskürzungen weitergeben, wie mehrere Hintergrundquellen beschreiben. Sogenanntes Fuel Hedging – also die Absicherung von Treibstoffpreisen im Voraus – federe Preissprünge bei manchen Airlines zunächst ab, dieser Schutz wirke aber nur teilweise und zeitlich begrenzt.
Große US-Airlines meldeten zuletzt trotz stark gestiegener Treibstoffkosten robuste Buchungen, was darauf hindeutet, dass die Nachfrage bislang einen Teil des Kostendrucks auffängt, berichtete AP [9].
Für Reisende mit Fernreiseplänen bedeutet die Lage: Selbst wenn die Waffenruhe hält und die Meerenge dauerhaft wieder geöffnet wird, dürften Flugtickets – insbesondere für Langstrecken – vorerst teuer bleiben.
Die vorliegenden Quellen liefern keine belastbaren Szenarien für den Fall eines Scheiterns der Waffenruhe.
URL dieses Artikels:
https://www.heise.de/-11248932
Links in diesem Artikel:
[1] https://en.yenisafak.com/economy/jet-fuel-prices-to-take-months-to-normalize-even-if-hormuz-reopens-3716827
[2] https://www.tagesschau.de/ausland/asien/iran-usa-waffenruhe-100.html
[3] https://www.rfi.fr/en/international-news/20260408-jet-fuel-supplies-to-take-months-to-recover-from-war-disruption-iata
[4] https://thepeninsulaqatar.com/article/08/04/2026/jet-fuel-supplies-to-take-months-to-recover-from-war-disruption-iata
[5] https://www.oag.com/blog/infographics-march-pricing-surge
[6] https://www.rfi.fr/en/international-news/20260408-jet-fuel-supplies-to-take-months-to-recover-from-war-disruption-iata
[7] https://www.fr.de/wirtschaft/iran-krieg-treibt-flugpreise-hoch-wer-jetzt-besonders-tief-in-die-tasche-greifen-muss-zr-94250325.html
[8] https://www.eia.gov/outlooks/steo/report/global_oil.php
[9] https://apnews.com/article/iran-war-jet-fuel-prices-f6ba525d65107e5eda8823d5212d7bff
Copyright © 2026 Heise Medien
Symbolbild: Eines der bisher eingesetzten Nasams-Luftabwehrsysteme
(Bild: Michele Ursi/Shutterstock.com)
Das ukrainische Unternehmen Fire Point will Patriot-Alternative für unter 1 Mio. US-Dollar bauen. Gefördert wird das Projekt von Investoren aus dem Nahen Osten.
Der ukrainische Rüstungshersteller Fire Point plant ein neues Luftabwehrsystem, das die Kosten für das Abfangen ballistischer Raketen drastisch senken soll. Firmenmitgründer und Chefentwickler Denys Shtilierman sagte [1] der Nachrichtenagentur Reuters, man wolle die Abfangkosten auf unter eine Million US-Dollar drücken.
"Wenn wir das schaffen, wäre das ein Wendepunkt in der Luftverteidigung", so Shtilierman. Erste Tests gegen ballistische Raketen seien für Ende 2027 vorgesehen.
Zum Vergleich: Das US-amerikanische Patriot-System, hergestellt von Raytheon und Lockheed Martin, benötigt laut Shtilierman häufig zwei bis drei Abfangraketen pro Ziel, wobei jede einzelne mehrere Millionen Dollar kostet. Eine Patriot-Abfangrakete kann demnach über 13,5 Millionen Dollar kosten.
Gleichzeitig sind Patriot-Systeme angesichts der Kriege in der Ukraine und im Nahen Osten zunehmend knapp, und auch das europäische Pendant SAMP/T wird nur in geringer Stückzahl produziert.
Fire Point führt nach Angaben Shtiliermans Gespräche mit mehreren europäischen Unternehmen, um das System zu entwickeln. Konkrete Namen nannte er nicht, verwies aber auf europäische Firmen wie Weibel, Hensoldt, SAAB und Thales, die über gute Radarlösungen verfügten.
Besonders interessiert sei Fire Point an Zusammenarbeit in den Bereichen Radar, Zielerfassung und Kommunikationssysteme – Felder, in denen dem Unternehmen eigene Expertise fehlt.
Fabian Hoffmann, Raketenexperte und Forscher an der Norwegischen Verteidigungshochschule, bezeichnete das Ziel bis 2027 gegenüber Reuters als "ehrgeizig". Dennoch dürfte die Nachfrage hoch sein – selbst wenn die Trefferquote pro Rakete geringer ausfalle als beim Patriot-System, so Hoffmann.
Fire Point wurde nach der russischen Invasion 2022 gegründet und ist heute Angaben zufolge der größte ukrainische Hersteller von Langstreckendrohnen, die für Angriffe tief im russischen Hinterland eingesetzt werden. Das Unternehmen produziert nach eigenen Angaben täglich Hunderte Langstreckendrohnen zu Stückkosten von rund 50.000 Euro sowie drei Flamingo-Marschflugkörper pro Tag, die jeweils etwa 600.000 Euro kosten.
Der Flamingo wurde in den vergangenen Monaten unter anderem gegen russische Militäreinrichtungen und Rüstungsfabriken eingesetzt, darunter eine Raketenanlage fast 1.400 Kilometer innerhalb Russlands.
Parallel entwickelt das Unternehmen zwei neue ballistische Raketen. Die kleinere FP-7 mit rund 300 Kilometern Reichweite soll laut Shtilierman "in naher Zukunft" erstmals militärisch eingesetzt werden und ähnelt dem US-System ATACMS.
Die größere FP-9 kann einen 800 Kilogramm schweren Gefechtskopf bis zu 850 Kilometer weit tragen und würde damit Moskau in Reichweite bringen. Shtilierman sagte, Angriffe auf die russische Hauptstadt würden "einen massiven Umschwung im russischen Denken" auslösen. Das russische Verteidigungsministerium reagierte nicht auf eine Anfrage von Reuters.
Hoffmann merkte an, dass ein breiterer Einsatz ballistischer Raketen die russische Luftverteidigung zusätzlich belasten könnte, die durch ukrainische Angriffe bereits geschwächt sei.
Fire Point wartet derzeit auf die Genehmigung der ukrainischen Kartellbehörde für den Einstieg eines Investors aus dem Nahen Osten. Der geplante Erwerb eines 30-Prozent-Anteils für 760 Millionen Dollar würde das Unternehmen mit 2,5 Milliarden Dollar bewerten.
Ukrainische Medien identifizierten den Interessenten laut Reuters als die emiratische Rüstungsfirma Edge Group. Weder Edge Group noch die ukrainische Kartellbehörde äußerten sich dazu. Eine Entscheidung wird bis etwa Oktober erwartet.
Die Investition wäre laut Shtilierman ein erster Schritt zum Aufbau eines Weltraumstartplatzes in den Vereinigten Arabischen Emiraten, mit dem Ziel, ein Netzwerk europäischer Satelliten in niedrigen Umlaufbahnen aufzubauen.
Fire Point habe bereits eine Kohlefaser-Wickelmaschine gebaut, die die Herstellung großer Feststoffbooster für Satellitenträger ermöglicht. Das Projekt befinde sich allerdings noch im Konzeptstadium.
Die Ukraine hat ihre kriegsbedingten Exportbeschränkungen für Rüstungsgüter zuletzt gelockert, doch jedes Geschäft unterliegt weiterhin strenger staatlicher Prüfung. Fire Point hat nach eigenen Angaben Interesse von Golfstaaten an seinen Drohnenprodukten erhalten und wartet auf die Exportgenehmigung der ukrainischen Regierung.
Die monatliche Exportkapazität liege bei bis zu 2.500 Langstreckendrohnen. Der Export des Flamingo-Marschflugkörpers sei hingegen aufgrund regulatorischer Hürden deutlich schwieriger.
Präsident Wolodymyr Selenskyj hatte im März erklärt, die Ukraine habe bereits 228 Spezialisten in fünf Staaten des Nahen Ostens entsandt, darunter die VAE, Saudi-Arabien und Katar, um bei der Abwehr iranischer Drohnenangriffe zu unterstützen. "Ich glaube, niemand hat eine mit unserer vergleichbare Erfahrung", sagte Selenskyj laut Reuters. Russland habe seit Kriegsbeginn fast 60.000 Shahed-Drohnen und ähnliche Systeme gegen die Ukraine eingesetzt.
Die Flamingo-Produktion soll ab Oktober mit einem neuen, hauseigenen Triebwerk hochgefahren werden. Zudem soll eine Raketentreibstoff-Fabrik in Dänemark noch in diesem Jahr den Betrieb aufnehmen, sobald zwei ausstehende Genehmigungen der dänischen Behörden vorliegen.
URL dieses Artikels:
https://www.heise.de/-11248248
Links in diesem Artikel:
[1] https://www.reuters.com/business/aerospace-defense/ukraine-missile-maker-targets-game-changer-air-defence-system-by-2027-2026-04-06/
Copyright © 2026 Heise Medien
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
WhatsApp auf einem Smartphone
(Bild: PixieMe / Shutterstock.com)
WhatsApp beginnt mit der Einführung von Usernamen. Damit erfüllt Meta einen lang gehegten Wunsch der Nutzer, die App ohne Preisgabe der Telefonnummer zu nutzen.
Drei Jahre hat WhatsApp die Funktion in Betatests erprobt [1], jetzt wurde offenbar damit begonnen, die Nutzung von Usernamen für erste Nutzer einzuführen. Dies berichtet das Blog WABetaInfo [2], das regelmäßig über Veränderungen in dem beliebten Messenger berichtet. Angeblich steht die Funktion aktuell nur sehr wenigen Nutzern zur Verfügung und soll langsam in den Apps für Android und iOS ausgerollt werden.
Mit der Alternative eines Nutzernamens erfüllt WhatsApp einen oft gehörten Wunsch. Durch seine Verwendung müssen Nutzer anderen nicht mehr ihre Mobilfunknummer kundtun, die bislang verwendet wurde, um User im Netzwerk zu finden oder ihnen Nachrichten zu schreiben. Der quelloffene Messenger Signal bietet eine solche Funktion bereits seit dem Frühjahr 2024 allen seinen Nutzern an. Meta hingegen hat sich sehr viel Zeit gelassen.
Ob man zum erlesenen Kreis derer gehört, die bereits einen Username einstellen können, ist in den Profileinstellungen ersichtlich. Taucht dort ein neues Feld für den Nutzernamen auf, kann dieses direkt angetippt werden, um diesen festzulegen. Wer nichts angezeigt bekommt, muss sich noch in Geduld üben. Meta selbst hat sich bislang nicht zum Rollout geäußert. Bereits im Oktober 2025 tauchte eine Funktion zur Reservierung von Nutzernamen in Betaversionen auf [3].
Laut WABetaInfo [4] können nur Nutzernamen neu ausgewählt werden, die noch nicht in den anderen Meta-Netzwerken Facebook und Instagram existieren. Es ist allerdings möglich, den gleichen Nutzernamen zu wählen, wenn man diesen schon in den anderen beiden Netzwerken besitzt. Hierfür sei aber über ein Account Center ein Nachweis nötig. Erst dann sei die Übernahme auf WhatsApp möglich. Die Verwendung eines übergreifenden Nutzernamens ist allerdings mit dem Risiko verknüpft, dass andere etwa auf Grundlage des Instagram-Kontonamens auch auf den WhatsApp-Nutzernamen eines Users schließen können.
Wer sich Kontaktanfragen über den Usernamen vom Leib halten möchte, kann einen Code einstellen. Nur wer Nutzernamen und Code kennt, kann dann einen Erstkontakt herstellen. Dies soll gegen Spam und Stalking helfen.
WhatsApp-Nutzernamen dürfen laut WABetaInfo drei bis 35 Zeichen lang sein und nur aus Kleinbuchstaben, Ziffern, Punkten und Unterstrichen bestehen. Die Anmutung einer Domain oder das Präfix „www.“ sind untersagt. Außerdem muss ein Nutzername mindestens einen Buchstaben enthalten.
URL dieses Artikels:
https://www.heise.de/-11249443
Links in diesem Artikel:
[1] https://www.heise.de/news/WhatsApp-soll-Nutzernamen-mit-PIN-Schutz-erhalten-9842293.html
[2] https://wabetainfo.com/whatsapp-is-rolling-out-the-username-feature-on-android-and-ios/
[3] https://www.heise.de/news/WhatsApp-Beta-Version-bringt-Nutzernamen-Reservierung-10747957.html
[4] https://wabetainfo.com/whatsapp-is-rolling-out-the-username-feature-on-android-and-ios/
[5] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[6] mailto:mki@heise.de
Copyright © 2026 Heise Medien
Samsung-Galaxy-Smartphone erhält ein Update.
(Bild: Below the Sky / Shutterstock.com)
Samsung schließt mit dem April-Sicherheitsupdate 47 Lücken auf Galaxy-Smartphones. 14 davon sind kritisch, vier weitere als hoch eingestufte betreffen Exynos.
Samsung verteilt seit dem 7. April wichtige Sicherheitspatches für zahlreiche Galaxy-Smartphones. Die Aktualisierung sollte nach und nach für alle Modelle bereitgestellt werden, die noch seitens des Herstellers unterstützt werden. 14 der 47 gestopften Sicherheitslücken stuft Samsung [1] als „kritisch“ ein.
Wie der Konzern auf seiner Webseite zu Sicherheitsupdates schreibt, stammen einige der Patches von Google, die im Security-Bulletin für April 2026 [2] aufgeführt sind. Andere Patches betreffen indes nur Samsung-Geräte. Unter anderem sollen Angreifer durch die Lücken Android-Smartphones ins Visier nehmen und Geräte abstürzen lassen können. Zusätzlich seien unbefugte Zugriffe auf eigentlich abgeschottete kryptografische Schlüssel möglich. Entsprechend ist es ratsam, die Patches einzuspielen, sobald sie angeboten werden.
Vier als hoch eingestufte Schwachstellen (CVE-2025-52908, CVE-2025-52909, CVE-2025-54601, CVE-2025-54602) betreffen Exynos-Chips von Samsungs Halbleitersparte. Entsprechend sind Geräte mit Qualcomm- oder MediaTek-Chips nicht davon betroffen. Fehler auf der Hardware-Ebene können unter Umständen die gesamte Sicherheitsarchitektur eines Geräts untergraben, sofern sie ungepatcht bleiben. Neben den Patches von Google und Samsungs Halbleiter-Sparte stellt der Konzern mit dem Sicherheitspatch zehn weitere SVE-Einträge (Samsung Vulnerabilities and Exposures) bereit, um das System abzudichten.
Drei der SVEs stuft Samsung [3] als „hoch“ ein, während die weiteren „moderat“ sind. Die hoch eingestuften Schwachstellen ermöglichen Angreifern mit physischem Zugang zum Gerät unter anderem die Umgehung von „Knox Guard“ durch eine fehlerhafte Überprüfung auf außergewöhnliche Zustände in „Device Care“ (SVE-2025-2188 (CVE-2026-21007)). Eine weitere Lücke (SVE-2025-2589 (CVE-2026-21010)) ermöglicht es lokalen Angreifern, im Retail-Modus Funktionen mit erhöhten Rechten auszulösen. Die dritte als hoch eingestufte Schwachstelle ermöglicht es physischen Angreifern, die Beschränkungen durch fehlerhafte Eingabevalidierung bei Daten zu Netzwerkbeschränkungen zu umgehen (SVE-2026-0775 (CVE-2026-21003)). Viele der Lücken betreffen Android-Versionen 14, 15 und 16.
URL dieses Artikels:
https://www.heise.de/-11248922
Links in diesem Artikel:
[1] https://www.heise.de/thema/Samsung
[2] https://www.heise.de/news/Patchday-Sicherheitsprobleme-im-Android-Schluesselspeichersystem-geloest-11246522.html
[3] https://security.samsungmobile.com/securityUpdate.smsb
[4] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[5] https://pro.heise.de/security/?LPID=39555_HS1L0001_27416_999_0&wt_mc=disp.fd.security-pro.security_pro24.disp.disp.disp
[6] mailto:afl@heise.de
Copyright © 2026 Heise Medien
(Bild: AFANASEV IVAN / Shutterstock.com)
Mehrere Sicherheitslücken in Nvidia DALI und Triton Inference Server gefährden Systeme. Sicherheitspatches stehen zum Download bereit.
Nach erfolgreichen Attacken können Angreifer Nvidia Triton Inference Server abstürzen lassen. Auf Systeme mit DALI kann Schadcode gelangen. Auch wenn es zurzeit noch keine Hinweise auf Attacken gibt, sollten Admins die reparierten Versionen zeitnah installieren.
Triton Inference Server hilft beim Aufsetzen verschiedener KI-Modelle. DALI verarbeitet unter anderem Bilder und Videos im Deep-Learning-Kontext. Derzeit ist unklar, an welchen Parametern Admins bereits attackierte Computer erkennen können.
Wie aus einer Warnmeldung hervorgeht [1], ist Triton Inference Server über insgesamt fünf Sicherheitslücken angreifbar. Vier Schwachstellen sind mit dem Bedrohungsgrad „hoch“ eingestuft. Aufgrund von unzureichenden Überprüfungen können Angreifer mit bestimmten Anfragen DoS-Zustände und somit Abstürze auslösen (etwa CVE-2026-24146). Außerdem können Informationen leaken (CVE-2026-24147 „mittel“).
Dagegen ist den Entwicklern zufolge die Version r26.02 gerüstet. Alle vorigen Ausgaben seien verwundbar. Davon sind alle Plattformen betroffen, auf denen Triton Inference Server läuft.
Weil DALI nicht vertrauenswürdige Daten verarbeitet, kann Schadcode auf Systeme gelangen und diese kompromittieren. Dieses Sicherheitsproblem haben die Entwickler eigenen Angaben zufolge in der Ausgabe 2.0 gelöst. Alle vorigen Versionen seien über den geschilderten Weg angreifbar, warnen die Entwickler in einer Meldung [2]. Wie die Installation vonstattengeht, steht in einem Supportbeitrag [3]. Die Softwareschwachstellen betreffen alle Plattformen.
Zuletzt hat Nvidia im Februar dieses Jahres [4] die KI-Tools Megatron Bridge und NeMO Framework gegen mögliche Schadcode-Attacken gerüstet.
URL dieses Artikels:
https://www.heise.de/-11248938
Links in diesem Artikel:
[1] https://nvidia.custhelp.com/app/answers/detail/a_id/5816
[2] https://nvidia.custhelp.com/app/answers/detail/a_id/5811
[3] https://docs.nvidia.com/deeplearning/dali/user-guide/docs/installation.html
[4] https://www.heise.de/news/Nvidia-KI-Tools-Megatron-Bridge-und-NeMo-Framework-als-Einfallstor-fuer-Angreifer-11182013.html
[5] https://pro.heise.de/security/?LPID=39555_HS1L0001_27416_999_0&wt_mc=disp.fd.security-pro.security_pro24.disp.disp.disp
[6] mailto:des@heise.de
Copyright © 2026 Heise Medien
(Bild: M5Stack)
Mehr als nur IoT: Mit Kamera-Verbindung, Display-Anbindung und H.264-Encoder eröffnet das Stamp-P4 neue Möglichkeiten für smarte Projekte.
Mit dem Stamp-P4 ist ein neues Embedded-Modul auf Basis des ESP32-P4NRW32 erschienen. Im Kern arbeitet ein 32-Bit-RISC-V-Dual-Core-Prozessor mit bis zu 360 MHz, ergänzt durch einen stromsparenden Coprozessor mit 40 MHz. Dazu kommen 16 MB Flash und 32 MB PSRAM direkt auf dem Modul. Diese Kombination erlaubt Anwendungen, die über typische Sensor- oder IoT-Szenarien hinausgehen, etwa einfache Bildverarbeitung, grafische Benutzeroberflächen oder lokale KI-Inferenz.
Interessant für Maker sind vor allem die integrierten Multimedia-Schnittstellen. Das Modul bietet eine MIPI-CSI-Kameraanbindung sowie eine MIPI-DSI-Schnittstelle für Displays. Ergänzt wird das Ganze durch einen Hardware-H.264-Encoder, einen ISP (Image Signal Processor) und einen Pixelbeschleuniger. Damit lassen sich Bild- und Videodaten direkt auf dem Gerät verarbeiten, ohne alles erst in die Cloud zu schieben. Für Projekte wie DIY-Überwachungssysteme, visuelle Sensorik oder eigene Smart-Displays ergibt sich dadurch ein deutlich größerer Spielraum.
Auch bei der Konnektivität ist das Stamp-P4 breit aufgestellt. Neben USB 2.0 OTG, SDIO und einem Ethernet-Interface (RMII) lassen sich zusätzliche Module anbinden, etwa für Wi-Fi 6. Das Basismodul verfügt über kein Funkmodul. Die Integration ins eigene Projekt wird durch verschiedene Bauformen erleichtert. Das Modul unterstützt sowohl SMT-Pads mit 1,27 mm beziehungsweise 2,00 mm Raster als auch klassische 2,54-mm-DIP-Header. Damit kann man es direkt auf eigene PCBs löten oder ganz pragmatisch auf ein Breadboard stecken. Auch „fliegende Verdrahtung“ ist möglich – nicht schön, aber manchmal eben der schnellste Weg zum Prototyp.
Mit insgesamt 44 GPIOs sowie Schnittstellen wie I2C, UART und USB steht genügend Peripherie für komplexere Aufbauten zur Verfügung. Der Stromverbrauch liegt laut Datenblatt bei rund 30 mA im Betrieb und unter 1 mA im Deep-Sleep-Modus, was für diese Leistungsklasse durchaus moderat ist. Eine integrierte Überspannungsschutzschaltung sorgt zusätzlich dafür, dass das Modul auch kleinere Fehlversuche im Labor eher verzeiht – das soll ja bei Maker-Projekten gelegentlich vorkommen.
Für die Entwicklung stehen mehrere Plattformen bereit, darunter Arduino IDE, ESP-IDF, PlatformIO und UiFlow2. Damit richtet sich das Modul sowohl an Einsteiger, die schnell loslegen wollen, als auch an erfahrene Entwickler, die tiefer in die Hardware eingreifen möchten.
Auf der offiziellen Dokumentationsseite [1] findet man einen Einstiegs-Guide für die Entwicklung. Für die Praxis nennt der Hersteller etwa Edge-AI-Geräte, industrielle HMIs oder eigenständige Kameraknoten als Anwendungsbereiche. Mit Abmessungen von knapp 30 × 22 mm bleibt das Modul dabei erstaunlich kompakt. Erhältlich ist das Board im M5Stack-Shop [2] für 19,95 US-Dollar. Wer mehr über das ESP-Ökosystem wissen will, findet in unserem ESP32-Kompass [3] alle Infos, die man sich nur wünschen kann.
URL dieses Artikels:
https://www.heise.de/-11248140
Links in diesem Artikel:
[1] https://docs.m5stack.com/en/core/Stamp-P4
[2] https://shop.m5stack.com/products/m5stamp-esp32p4-module
[3] https://www.heise.de/ratgeber/ESP32-Hardware-Kompass-Welches-Modell-Sie-fuer-Ihr-naechstes-Projekt-benoetigen-10321040.html
[4] https://www.heise.de/make
[5] mailto:das@heise.de
Copyright © 2026 Heise Medien
(Bild: Tada Images / Shutterstock.com)
Mit DeerFlow stellt ByteDance ein Super-Agenten-Framework vor, das durch Sandboxes eine sichere und parallele Ausführung der Agenten erlaubt.
OpenClaw hat es vorgemacht und gezeigt, zu welchen Leistungen LLMs schon in der Lage sind, wenn Agenten sie richtig nutzen. Allerdings sind die damit verbundenen Gefahren [1] nicht nur groß, sondern sogar unüberschaubar: In manchen Fällen klaute OpenClaw Kreditkarten oder übernahm gleich den ganzen Computer [2]. Dennoch steckt in der Technologie ein enormes Potenzial, was einige Nachahmer gefunden hat, die versuchen, die Schwächen zu korrigieren.
Einer der ersten Player, der sich aus der Deckung wagt, ist ByteDance, die Muttergesellschaft von TikTok, mit dem Tool DeerFlow [3] (Deep Exploration and Efficient Research Flow). Nachdem das Projekt bereits über 56.000 Sterne auf GitHub erhalten hat, lohnt es sich, einen genaueren Blick darauf zu werfen.
ByteDance möchte, dass man für die Nutzung ein Coding-Abo abschließt, notwendig ist der aber nicht: DeerFlow lässt sich genauso mit lokalen Modellen verwenden. Etwas schwieriger wird es bei lokaler Nutzung allerdings, wenn das Framework selbstständig Websuchen durchführen soll. Das ist außerordentlich sinnvoll, denn der Knowledge Cutoff der meisten LLMs liegt beträchtlich in der Vergangenheit und sie sind über neue Entwicklungen nicht informiert. Hier kann man zum Beispiel die Search-Engine Tavily [4] hinzufügen, für die es eine freie Variante gibt, mit der sich tausend Suchanfragen pro Monat durchführen lassen. Die gibt es auch bei InfoQuest [5], das ByteDance proprietär anbietet. Allerdings ist die Anzahl der Anfragen insgesamt auf tausend pro Account limitiert, Preise für weitere sind nicht direkt zu finden. Interessanterweise bietet ByteDance diesen Dienst in China selbst gar nicht an, möglicherweise auch aus Zensurgründen.
Alle lassen sich lokal installieren und konfigurieren. Die ausführliche Anleitung dazu findet sich auf GitHub [7]. Zunächst muss man eine Konfigurationsdatei im YAML-Format anpassen. Anschließend lassen sich Docker-Container starten, in denen das System dann läuft. Die Container öffnen einen Port (2026, ob das Zufall ist?) auf dem Host-System. Das Ganze funktioniert ziemlich unproblematisch, wenn man alle Environment-Variablen in .env schreibt, die Variablen der Shell verwendet das System nämlich nicht. Das Ergebnis sieht dem Playground von DeerFlow [8] sehr ähnlich, aber es lässt sich mit neuen Chats ergänzen.
Spielt man mit dem Playground, merkt man dem Tool auch seine Herkunft aus dem Deep Research an. Komplexe Themen kann der Agent selbst recherchieren und kommt zu guten Ergebnissen, die auch neue Entwicklungen beinhalten. Die Vorschläge für den heise-Verlag (siehe Abbildung 1) sind wie von anderen Agenten gewohnt sehr umfangreich und klingen auch sinnvoll. Allerdings ist das bei Weitem noch nicht alles.
Intern baut DeerFlow auf LangChain und LangGraph und ist damit hervorragend erweiterbar. Genau das betont auch ByteDance und bezeichnet das Framework als „Super Agent Harness“ [9] – also ein Framework, das sich ausgezeichnet erweitern lässt. Angeblich haben die ByteDance-Developer DeerFlow neu konzipiert, als sie genau diese Erweiterungsfähigkeit von LangChain als einen entscheidenden Punkt erkannt haben.
Derartige Erweiterungen können auf unterschiedlicher Ebene erfolgen. Zentral dafür sind Skills und Tools, in denen Anwender über Markdown-Files Workflows definieren. Auch der im Beispiel der Abbildung benutzte Research-Workflow basiert auf einem solchen Skill. Von Anwendern bereitgestellte Skills lädt DeerFlow bei Bedarf nach, wenn sie benötigt werden. Das spart Speicher und Rechenzeit und erlaubt eine dynamische Erweiterung des Systems zur Laufzeit. Tools sind etwas fortgeschrittener und erledigen komplexe Aufgaben wie beispielsweise die Websuche, können aber auch Bash-Skript oder Python-Programme in einer Sandbox sicher ausführen.
ByteDance hat erkannt, dass komplexe Aufgaben sich nur schlecht in einem einzigen Durchlauf erledigen lassen. Daher stammt das Konzept der Sub-Agenten, die ihren eigenen Kontext, eigene Tools und Abschlussbedingungen haben. Das erlaubt, sie parallel zueinander laufen zu lassen und damit Zeit zu sparen.
Die Sandbox funktioniert in DeerFlow wie ein eigener Computer. Jeder Prozess erhält eine eigene Umgebung mit einem separaten Filesystem, in dem sich wiederum Skills usw. befinden können. Durch diese Isolation können die Prozesse unabhängig voneinander agieren.
Großen Wert legt ByteDance auf die Isolation von Kontexten. Jeder Agent verfügt über einen eigenen Kontext und wird nicht von anderen Agenten gestört. Nebenbei erlaubt das die schon angesprochene Parallelisierung von Agenten. Um den Kontext möglichst klein zu halten (und damit Speicher bzw. Token im LLM zu sparen), findet ständig eine Zusammenfassung statt.
DeerFlow hat ein Langzeitgedächtnis und merkt sich Inhalte auch über eine Unterhaltung hinaus. Es fungiert somit als Wissensspeicher und passt sich den Wünschen der Benutzer immer besser an. Diese Daten speichert es alle lokal. Mit Empfehlungen und Apps, auf die man nicht mehr verzichten möchte, kennt sich ByteDance ja bestens aus. Im Gegensatz zu TikTok entsteht bei DeerFlow aber ein echter Mehrwert.
ByteDance veröffentlicht mit DeerFlow ein Agenten-Framework mit vielen neuen Ideen und zeigt damit, wie sich Agenten zukünftig entwickeln könnten. Besonders spannend sind dabei die einfach zu implementierenden Skills, die Isolation und Parallelisierung sowie die Sandboxen, die gefährliche Situationen wie bei OpenClaw vermeiden sollen.
Agentische KI beschäftigt Forscher gerade sehr intensiv. Noch weiß niemand ganz genau, wie sich das Feld entfalten wird. Alternative Tools wie n8n [10] oder Dify [11] sind hier noch deutlich statischer als DeerFlow, aber möglicherweise ergeben sich für sie nun auch neue Richtungen. Umso spannender wird es zu beobachten, wie sich das DeerFlow-Framework weiterentwickelt.
URL dieses Artikels:
https://www.heise.de/-11248176
Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/Die-Sicherheitsrisiken-von-KI-Assistenten-wie-OpenClaw-11164056.html
[2] https://www.businessinsider.com/openclaw-moltbook-cybersecurity-risks-researchers-ai-2026-2
[3] https://deerflow.tech/
[4] https://www.tavily.com/
[5] https://docs.byteplus.com/en/docs/InfoQuest/What_is_Info_Quest
[6] https://genai-summit.bettercode.eu/?wt_mc=intern.academy.dpunkt.konf_dpunkt_vo_bcc_genai_summit.empfehlung-ho.link.link&LPID=33686
[7] https://github.com/bytedance/deer-flow
[8] https://deerflow.tech/workspace/
[9] https://github.com/bytedance/deer-flow?tab=readme-ov-file#from-deep-research-to-super-agent-harness
[10] https://n8n.io/
[11] https://dify.ai/
[12] mailto:who@heise.de
Copyright © 2026 Heise Medien
(Bild: NicoElNino/Shutterstock.com)
Konsistenz (und Eventual Consistency) wird oft als technisches Risiko behandelt. Dabei gab es sie schon vor Computern. Wer sie ignoriert, baut fragile Systeme.
Im Deutschen hat sich eine Übersetzung eingebürgert, die das Denken über verteilte Systeme in eine falsche Richtung lenkt. „Eventual Consistency“ wird häufig als „eventuell konsistent“ wiedergegeben. Eventuell, also möglicherweise. Eine Datenbank, die möglicherweise konsistent ist, klingt nach einem System, dem man besser nicht vertraut. Kein Wunder, dass viele Entwicklerinnen und Entwickler reflexartig nach stärkeren Garantien greifen, sobald der Begriff fällt.
Die englische Bedeutung von „eventual“ ist jedoch eine andere. Sie meint „letztendlich“ oder „am Ende“. Eventual Consistency bedeutet also nicht, dass Konsistenz vielleicht eintritt. Sie bedeutet, dass Konsistenz verlässlich eintritt, nur nicht sofort. Die Frage ist nicht, ob, sondern wann. Und diese Frage ist keine technische, sondern eine fachliche. Das war sie schon immer.
Ein besseres mentales Modell als „möglicherweise inkonsistent“ ist das der veralteten Daten. In jedem Moment kann irgendein Teil eines Systems auf Daten zugreifen, die den allerletzten Stand nicht widerspiegeln. Die Daten sind nicht falsch. Sie sind nur nicht aktuell. Sie waren vor einem Moment korrekt. Sie werden in einem Moment wieder korrekt sein. Gerade eben sind sie veraltet. Jedes System hat irgendwo veraltete Daten. Die Frage ist nicht, ob Daten veraltet sein können, sondern wie veraltet akzeptabel ist. Millisekunden? Sekunden? Minuten? Stunden? Die Antwort hängt vom Anwendungsfall ab, und sie lautet selten „niemals“.
Es gibt noch etwas, das sich in der Softwareentwicklung hartnäckig hält: Die Behauptung, eine relationale Datenbank sei immer konsistent. Transaktionen garantieren es. ACID garantiert es. Nach dem Commit sind die Daten da, und jeder sieht sie. Das stimmt allerdings nur innerhalb einer einzelnen Datenbankinstanz, für eine einzelne Abfrage, in einem einzelnen Moment. So funktionieren reale Systeme nicht.
Wer Read-Replicas einsetzt, akzeptiert bereits, dass Leseoperationen veraltete Daten liefern können. Wer einen Cache verwendet, akzeptiert, dass die gecachten Daten zum Zeitpunkt des Lesens nicht mehr aktuell sein müssen. Wer eine mobile App betreibt, akzeptiert, dass die Anzeige auf dem Gerät den Stand der letzten Synchronisation zeigt, nicht den aktuellen. Und wer HTML serverseitig rendert, akzeptiert, dass die Seite zum Zeitpunkt der Auslieferung bereits veraltet sein kann.
In dem Moment, in dem Daten die Datenbank verlassen, beginnen sie zu altern. Bis sie den Bildschirm einer Nutzerin oder eines Nutzers erreichen, sind sie bereits ein Schnappschuss der Vergangenheit. Die Kundin sieht „Bestellung bestätigt“, aber das Lagersystem hat den Auftrag noch nicht verarbeitet. Der Kunde sieht „3 Stück auf Lager“, aber jemand anders hat gerade zwei davon in den Warenkorb gelegt. Das ist kein Fehler. Das ist die Funktionsweise verteilter Systeme. Und jedes System mit einer Bedienoberfläche ist ein verteiltes System, denn das Endgerät ist ein eigener Knoten, das Netzwerk ist unzuverlässig, und zwischen Anfrage und Antwort vergeht Zeit.
Ich begegne in meiner Beratungsarbeit regelmäßig Teams, die überzeugt sind, ihre Systeme seien stark konsistent. Bei genauerem Hinsehen zeigt sich fast immer, dass die Konsistenz an der Datenbankgrenze endet. Dahinter beginnt eine Welt aus Caches, Replikas, Message-Queues und gerenderten Oberflächen, in der Daten bereits veraltet sind, bevor sie ankommen. Das System ist längst eventually consistent. Es gibt nur niemanden, der das ausspricht.
Eventual Consistency ist kein Phänomen, das mit verteilten Softwaresystemen entstanden ist. Sie ist ein Grundproblem der physischen Welt, und Unternehmen haben seit Jahrhunderten Wege gefunden, damit umzugehen.
Man stelle sich eine Firma mit zwei Vertriebsbüros in verschiedenen Städten vor, zu einer Zeit, als das Telefon das schnellste Kommunikationsmittel war. Beide Büros verkaufen aus demselben Lagerbestand. Eine Kundin in München möchte die letzte Einheit eines Produkts kaufen. Ein Kunde in Hamburg möchte dieselbe Einheit kaufen. Keiner der beiden Vertriebsmitarbeiter weiß, was der andere gerade macht.
Wie haben Unternehmen dieses Problem gelöst? Nicht durch perfekte Echtzeitsynchronisation. Sie haben akzeptiert, dass Konflikte auftreten werden, und Prozesse entwickelt, um sie zu behandeln. Sie haben überbucht und sich entschuldigt. Sie haben Sicherheitsbestände geführt. Sie haben im Lager angerufen, bevor sie eine Lieferung zugesagt haben. Sie haben enttäuschte Kundinnen und Kunden kompensiert. Sie haben Risiken gemanagt, nicht Konsistenz.
Das gleiche Produkt, das gleiche Problem, nur mit Stift und Papier statt mit Datenbanken. Keine Technologie der Welt kann diese grundlegende Herausforderung eliminieren: zwei Personen, zwei Orte, eine Ressource, unvollständige Information. Die Naturgesetze garantieren, dass Information Zeit braucht, um sich auszubreiten. Perfekte Synchronisation ist nicht nur schwierig. Sie ist unmöglich.
Das Interessante daran ist, dass diese analogen Prozesse oft erstaunlich gut funktioniert haben. Nicht weil sie Inkonsistenzen verhindert hätten, sondern weil sie Strategien für den Umgang mit ihnen entwickelt hatten. Die Buchhaltung glich am Ende des Tages die Bestände ab. Der Vertrieb rief im Zweifelsfall im Lager an. Und wenn doch einmal zwei Kunden dasselbe Produkt zugesagt bekamen, gab es ein Gespräch, eine Entschuldigung und eine Lösung. Der Geschäftsprozess war auf Konflikte vorbereitet, weil niemand auf die Idee gekommen wäre, sie für unmöglich zu erklären.
Wenn ich mit Teams über Eventual Consistency spreche, hilft dieser historische Blick oft mehr als jedes Architekturdiagramm. Er verschiebt das Problem aus der technischen Ecke in die geschäftliche, wo es hingehört. Die Frage lautet nicht: Wie verhindern wir Inkonsistenz? Sie lautet: Wie gehen wir mit ihr um?
Wenn Entwicklerinnen und Entwickler über Eventual Consistency diskutieren, stellen sie häufig die falsche Frage. Sie fragen: Ist Eventual Consistency hier akzeptabel? Das rahmt Konsistenz als binäre Eigenschaft, als hätte man sie oder hätte sie nicht.
Die richtigen Fragen sind anders: Wie häufig tritt ein Konflikt tatsächlich auf? Wenn zwei Nutzerinnen oder Nutzer gleichzeitig den letzten Artikel kaufen wollen: Passiert das einmal am Tag? Einmal im Monat? Einmal im Jahr? Die Häufigkeit entscheidet darüber, ob ein Konflikt ein reales Problem ist oder eine theoretische Sorge. Was kostet ein Konflikt? Ist die Konsequenz eine enttäuschte Kundin? Eine Rückerstattung? Ein manueller Eingriff? Ein rechtliches Problem? Die Kosten bestimmen, wie viel Aufwand die Vermeidung rechtfertigt. Und was kostet die Vermeidung? Stärkere Konsistenzgarantien sind nicht kostenlos. Sie erfordern Koordination, also Latenz. Sie erfordern Sperren, also geringeren Durchsatz. Sie erfordern Infrastruktur, also Geld.
Das sind betriebswirtschaftliche Fragen, keine Ingenieursfragen. Das Entwicklungsteam kann erklären, was technisch möglich ist und was jede Option kostet. Aber die Entscheidung über das akzeptable Risiko gehört ins Business. Ein Bezahlsystem und ein Social-Media-Feed haben unterschiedliche Toleranzen. Eine Patientenakte und ein Warenkorb haben unterschiedliche Anforderungen. Der Kontext bestimmt die Antwort.
Genau deshalb gehören Diskussionen über Eventual Consistency nicht ausschließlich in Technik-Meetings. Das Team mag starke Meinungen über technische Korrektheit haben, weiß aber vielleicht nicht, dass die Fachabteilung eine Verzögerung von einer Sekunde bereitwillig akzeptieren würde, wenn dafür die Infrastrukturkosten sinken. Oder es weiß nicht, dass ein bestimmter Anwendungsfall regulatorische Anforderungen hat, die stärkere Garantien verlangen. Das Gespräch braucht beide Perspektiven.
Alltagsbeispiele zeigen, wie selbstverständlich Eventual Consistency bereits ist. Paketverfolgung zeigt einen Status, der vor Stunden erfasst wurde. Das Paket wurde gescannt, als es das Sortierzentrum verlassen hat. Seitdem ist es unterwegs, möglicherweise bereits zugestellt. Die angezeigte Information ist veraltet, und das stört niemanden, weil ein ungefährer Überblick über den Fortschritt ausreicht. Bestandsanzeigen in Online-Shops sind ein ähnlicher Fall. „Nur noch 3 auf Lager“ war korrekt, als die Seite gerendert wurde. Inzwischen hat vielleicht jemand eines gekauft. Vielleicht hat jemand eines in den Warenkorb gelegt, ohne zu bestellen. Die Zahl ist ein Hinweis, keine Garantie. Und das ist akzeptabel, weil der Checkout-Prozess den Grenzfall abfängt, in dem der Artikel tatsächlich vergriffen ist.
Besonders aufschlussreich ist das Beispiel der Fluggesellschaften. Airlines überbuchen bewusst, weil sie wissen, dass ein Teil der Passagiere nicht erscheinen wird. Das Buchungssystem akzeptiert mehr Reservierungen, als Sitzplätze vorhanden sind. Wenn doch alle erscheinen, wird das Problem am Gate gelöst: Kompensation, Umbuchung, Upgrade. Das System ist darauf ausgelegt, Konflikte zu akzeptieren und sie nachträglich zu lösen. Das ist kein Versagen der Konsistenz. Es ist eine Geschäftsstrategie, die jedes Jahr Millionen von Flügen mit freien Sitzen füllt, die sonst leer geblieben wären.
All diese Systeme funktionieren. Ihre Nutzerinnen und Nutzer beschweren sich nicht, weil das Konsistenzfenster kurz genug ist oder weil der Geschäftsprozess die Ausnahmen elegant abfängt. Das Ziel war nie perfekte Konsistenz. Das Ziel war ausreichende Konsistenz.
Unter den vielen Beispielen, die ich in Gesprächen über Eventual Consistency verwende, ist eines besonders aufschlussreich, weil es die Perspektive komplett umdreht.
Geldautomaten sind normalerweise online und mit den Systemen der Bank in Echtzeit verbunden. Bei einer Abhebung prüft der Automat den Kontostand, verifiziert die Deckung und gibt das Geld aus. Einfach und konsistent. Doch was passiert, wenn die Netzwerkverbindung ausfällt und der Automat offline geht?
Die meisten Entwicklerinnen und Entwickler, denen ich diese Frage stelle, antworten: „Der Automat muss den Betrieb einstellen. Keine Verbindung bedeutet keine Kontostandsprüfung. Keine Prüfung bedeutet mögliche Überziehungen. Also abschalten, bis die Verbindung wiederhergestellt ist.“ Das ist die naheliegende, die sichere, die technisch korrekte Antwort. Es ist aber auch die falsche.
Man stelle sich einen prominenten Millionär vor, der an einem Geldautomaten steht und 50 Euro abheben möchte, nur um zu erfahren, dass der Automat außer Betrieb ist. Die Schlagzeile am nächsten Tag: „Bank lässt Topkunden wegen Netzwerkproblem im Regen stehen.“ Das ist keine Schlagzeile, die eine Bank gebrauchen kann. Der Reputationsschaden übersteigt jedes Überziehungsrisiko bei einer Kleinbetragabhebung um ein Vielfaches.
Was machen Banken also tatsächlich? Der Automat arbeitet weiter, auch offline. Aber mit intelligentem Risikomanagement. Die meisten Ausfälle sind kurz: Die Verbindung bricht für wenige Minuten ab und stellt sich dann von selbst wieder her. Bis jemand etwas bemerkt, hat sich das Problem bereits gelöst. Die meisten Menschen heben zudem nur Geld ab, wenn sie wissen, dass sie es haben. Niemand möchte die Peinlichkeit erleben, an einem Geldautomaten mit einer Schlange hinter sich abgelehnt zu werden. Diese Selbstselektion reduziert das Überziehungsrisiko erheblich. Und für den Fall, dass die Verbindung länger ausfällt, begrenzt die Bank den maximalen Abhebungsbetrag im Offline-Modus.
Doch der eigentlich interessante Punkt liegt woanders. Wenn jemand im Offline-Modus sein Konto tatsächlich überzieht, hat die Bank zwei Möglichkeiten, die Situation zu rahmen. Erste Variante: „Kunde nutzte Systemschwachstelle während Netzwerkausfall.“ Das klingt nach einem Sicherheitsvorfall. Zweite Variante: „Bank zeigte Flexibilität und half Kunden trotz technischer Schwierigkeiten.“ Das klingt nach exzellentem Kundenservice. Und nebenbei: Die Bank berechnet Überziehungszinsen. Der Kunde, der 50 Euro abgehoben hat, die er nicht hatte, zahlt sie zurück, mit Aufschlag. Die Bank hat eine technische Einschränkung in eine Einnahmequelle verwandelt.
Das ist es, was fachliches Denken über Konsistenz bedeutet. Die Entwicklerin sieht ein Konsistenzproblem und will es um jeden Preis verhindern. Die Geschäftsseite sieht eine Risiko-Ertrags-Rechnung und findet eine Lösung, die besser ist als sowohl „immer konsistent“ als auch „immer verfügbar“. Die beste Antwort lag nicht im Engineering-Meeting. Sie lag im Business-Meeting.
Die Gefahr liegt nicht in Eventual Consistency. Sie liegt darin, so zu tun, als gäbe es sie nicht.
Wer sein System für stark konsistent hält, entwirft keine Kompensationslogik. Wer keine Konflikte erwartet, baut keine Konfliktbehandlung. Wer keine veralteten Daten einplant, gestaltet keine Benutzererfahrung, die damit umgehen kann. Und wenn dann die Race Condition doch eintritt, wenn der Cache im falschen Moment veraltete Daten liefert, wenn die Replica-Verzögerung zu einer sichtbaren Inkonsistenz führt, gibt es keinen Plan. Das System versagt auf eine Weise, die niemand vorhergesehen hat, weil sich niemand die Mühe gemacht hat, sie vorherzusehen.
Wer Eventual Consistency dagegen anerkennt, entwirft dafür. Man denkt darüber nach, was passiert, wenn Daten veraltet sind. Man baut idempotente Operationen, die gefahrlos wiederholt werden können. Man schafft Kompensationsmechanismen für den Fall, dass etwas schiefgeht. Man kommuniziert Unsicherheit gegenüber Nutzerinnen und Nutzern, statt falsche Sicherheit zu vermitteln.
In der Praxis bedeutet das konkrete Entwurfsentscheidungen. Statt „Bestellung erfolgreich“ anzuzeigen, wenn die Bestellung lediglich angenommen wurde, zeigt man „Bestellung wird verarbeitet“ und aktualisiert den Status, sobald die Verarbeitung abgeschlossen ist. Statt eine Schaltfläche nach dem Klick zu deaktivieren und auf Konsistenz zu hoffen, gestaltet man die Operation idempotent, sodass ein doppelter Klick keinen Schaden anrichtet. Statt einen Fehler zu zeigen, wenn ein Artikel zwischen Warenkorb und Checkout vergriffen ist, bietet man eine Alternative an. Das sind keine technischen Notlösungen. Das sind durchdachte Benutzererlebnisse, die auf einer ehrlichen Einschätzung der Systemrealität basieren.
Die deutsche Fehlübersetzung ist dabei versehentlich tiefgründig. „Eventuell konsistent“ klingt bedrohlich, weil Unsicherheit bedrohlich klingt. Aber Unsicherheit ist die Realität verteilter Systeme. Die Wahl besteht nicht zwischen Sicherheit und Unsicherheit. Sie besteht zwischen eingestandener und versteckter Unsicherheit. Das eine führt zu robusten Systemen. Das andere führt zu Überraschungen.
Eventual Consistency ist keine Einschränkung, die es zu überwinden gilt. Sie ist eine Realität, für die es zu entwerfen gilt. Ihre Systeme sind bereits eventually consistent. Die Frage ist, ob Sie für diese Realität entwerfen oder so tun, als existiere sie nicht. Und diese Frage ist keine, die ein Engineering-Team allein beantworten sollte. Sie ist eine fachliche Entscheidung. Das war sie schon immer.
URL dieses Artikels:
https://www.heise.de/-11229014
Links in diesem Artikel:
[1] mailto:rme@ix.de
Copyright © 2026 Heise Medien
(Bild: Fransizka Panter)
Der Blog beschäftigt sich mit einem der größten Fallstricke von C++: reinterpret_cast kann zweckentfremdet undefiniertes Verhalten auslösen.
Im heutigen Beitrag werde ich eine der größten Fallstricke von C++ erläutern: reinterpret_cast. Ein anderer Titel für diesen Beitrag könnte lauten: „Das ist nicht der Cast, den du suchst!“
Meine Motivation für diesen Blogbeitrag stammt aus mehreren Schulungen und einigen Vorträgen, die ich gehalten habe. Seit C++23 gibt es in der Standardbibliothek eine neue Funktion: std::start_lifetime_as. Wenn ich Kurse mit Schwerpunkt auf eingebetteten Umgebungen unterrichte oder Vorträge mit diesem Schwerpunkt halte, habe ich begonnen, std::start_lifetime_as in das Material aufzunehmen. Mit einem interessanten Ergebnis.
Das Feedback, das ich bekomme, lautet in etwa:
FreshRSS std::start_lifetime_as, ich habe doch schon reinterpret_cast?reinterpret_cast nicht verwenden?Wer noch nie von start_lifetime_as gehört hat, findet weitere Informationen in meinem englischen Artikel „The correct way to do type punning in C++ - The second act“ [1]. Ich verwende folgendes Beispiel daraus:
struct ConfigValues {
uint32_t chksum;
std::array<uint32_t, 128> values;
};
bool ProcessData(std::span<unsigned char> bytes)
{
if(bytes.size() < sizeof(ConfigValues)) { return false; }
// #A
ConfigValues* cfgValues = reinterpret_cast<ConfigValues*>(bytes.data());
return HandleConfigValues(cfgValues);
}Die Idee hier ist, eine Reihe von rohen Bytes in eine bekannte Struktur umzuwandeln – hier mit dem Namen ConfigValues. Zusammen mit start_lifetime_as gerate ich immer öfter in Gespräche, in denen mir Leute sagen, dass der Name reinterpret impliziert, dass solcher Code wie erwartet funktionieren sollte. Die Erwartung ist, dass solcher Code frei von undefiniertem Verhalten ist und tatsächlich einen Zeiger auf ein ConfigValues-Objekt zurückgibt.
Zwar kann ich einer solchen Erwartung aufgrund des Wortlauts des Standards und des C++-Objektmodells nicht widersprechen, doch eine solche Erwartung führt zu undefiniertem Verhalten. In einer typsicheren Sprache kann ein Objekt nicht in ein anderes, nicht verwandtes Objekt konvertiert werden.
Der wichtigste Wortlaut ist [expr.reinterpret.cast § 7] [2], der besagt:
An object pointer can be explicitly converted to an object pointer of a different type. When a prvalue v of object pointer type is converted to the object pointer type “pointer to cv T”, the result is static_cast<cv T*>(static_cast<cv void*>(v)). [Note 5: Converting a pointer of type “pointer to T1” that points to an object of type T1 to the type “pointer to T2” (where T2 is an object type and the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value. — end note]
Zunächst einmal handelt dieser ganze Absatz von Zeigern auf Objekte und nicht von Objekten selbst. Es heißt, dass du ein ConfigValues in einen void* oder einen beliebigen anderen Datentyp konvertieren kannst, der ein Objekttyp ist. Ein Objekttyp ist alles außer einem Funktionstyp, einem Referenztyp und void.
Weiter unten in der Anmerkung bestätigt der Standard ausdrücklich, dass du einen Rundlauf durchführen kannst. Zum Beispiel:
ConfigValues cfg{};
ConfigValues* val{&cfg};
void* typeErased = reinterpret_cast<void*>(val);
ConfigValues* roundTripBackToVal = reinterpret_cast<ConfigValues*>(typeErased);Dies ermöglicht Konstrukte, die sogenannte Typlöschung (Type Erasure) nutzen, wie std::any. Du kannst einen Alias eines anderen Zeigertyps erhalten.
In diesem Absatz ist von einer Konvertierung des Objekts selbst keine Rede. Nur den Zeiger kann man konvertieren.
Im Sinne des C++-Objektmodells muss eine Anwendung ein gültiges Objekt erstellen (und später zerstören). Aber alles, was jemals erstellt wurde, ist ein ConfigValues-Objekt. reinterpret_cast ist ein Werkzeug, das es ermöglicht, einen Zeiger eines anderen Typs zu speichern. Sobald du ihn verwenden möchtest, musst du den Zeiger wieder in seinen ursprünglichen Typ zurückkonvertieren.
Nehmen wir einmal an, reinterpret_cast würde so funktionieren, wie manche Leute es erwarten:
struct Apple {
int x;
};
struct Orange {
int y;
};
Apple* grannySmith{new Apple{4}};
Orange* bali{reinterpret_cast<Orange*>(grannySmith)}; // #A
int y = bali->y;
int x = grannySmith->x;Nach den Regeln von C++ muss ein Objekt erstellt und zerstört werden. Wenn #A ein Objekt erstellen würde, müsste es das grannySmith-Objekt zerstören. Was überraschend wäre. Dann hättest du keine Möglichkeit, eine Typlöschung wie std::any zu implementieren, da das Speichern eines gelöschten Typs void* das ursprüngliche Objekt aus Sicht der abstrakten Maschinerie von C++ zerstören würde. Das würde dem Compiler ermöglichen, verschiedene andere Optimierungen vorzunehmen, die das Programm zum Absturz bringen würden.
Mit reinterpret_cast hast du eine Möglichkeit, ein Objekt A als einen anderen Typ B zu aliasieren, jedoch ohne das Recht, jemals über diesen Zeiger auf ein B-Objekt zuzugreifen. Andererseits erstellt start_lifetime_as implizit ein B-Objekt am Zielort des Zeigers A, während gleichzeitig die Lebensdauer von A beendet wird.
Meist will man in diesen Situationen ein Objekt eines anderen Typs zum Leben erwecken. Und genau dafür ist std::start_lifetime_as gedacht.
Wenn du std::start_lifetime_as auf einen Zeiger anwendest, versteht die abstrakte Maschine, dass du ein neues Objekt dieses Typs erstellst. Im Gegensatz zu einem Aufruf von new oder einem Stack-Objekt wird kein Konstruktor ausgeführt. Alles geschieht nur innerhalb des C++-Objektmodells.
Es gibt noch eine weitere Funktion von std::start_lifetime_as: Wenn es die Lebensdauer eines neuen Objekts startet, wird die Lebensdauer der Quelle automatisch beendet, wiederum ohne einen tatsächlichen Destruktor aufzurufen. Das ist hier entscheidend.
Wenn ich std::start_lifetime_as auf mein vorheriges Beispiel anwende, sieht die korrekte Implementierung wie folgt aus:
struct Apple {
int x;
};
struct Orange {
int y;
};
Apple* grannySmith{new Apple{4}};
Orange* bali{std::start_lifetime_as<Orange>(grannySmith)}; // #A
int y = bali->y;
grannySmith = std::start_lifetime_as<Apple>(bali); // #B
int x = grannySmith->x;Der Code in #B startet die Lebensdauer des Zeigers erneut als Apple-Objekt.
Mit reinterpret_cast erhältst du nur eine Zeigerkonvertierung. Du darfst diesen neuen Zeiger nicht verwenden, um auf ein Objekt des Typs zuzugreifen.
Wenn du die Lebensdauer eines Objekts starten möchtest, um auf Daten als neuen Typ zuzugreifen, benötigst du std::start_lifetime_as.
URL dieses Artikels:
https://www.heise.de/-11225887
Links in diesem Artikel:
[1] https://andreasfertig.com/blog/2025/04/the-correct-way-to-do-type-punning-in-cpp-the-second-act/
[2] https://eel.is/c++draft/expr.reinterpret.cast#7
[3] mailto:rme@ix.de
Copyright © 2026 Heise Medien
Chiphersteller verdienen prächtig, aber superteure Speicherchips werden die Nachfrage nach Hardware außerhalb der KI „bis 2028 vernichten oder verzögern“.
Für den weltweiten Umsatz mit Halbleiterbauelementen im Jahr 2026 prognostizieren Marktforscher von Gartner ein Wachstum von 64 Prozent auf 1,3 Billionen US-Dollar. Im Jahr 2025 lag er demnach bei 805 Milliarden US-Dollar.
Ein erheblicher Teil des Umsatzwachstums resultiere aber nicht mehr produzierten Stückzahlen, sondern aus den stark gestiegenen Preisen für DRAM- und NAND-Flash-Chips. DRAM (für Arbeitsspeicher) werde im laufenden Jahr 125 Prozent teurer. Bei NAND-Flash (für SSDs und Speicherkarten) erwartet Gartner sogar 234 Prozent Preisanstieg.
30 Prozent aller 2026 verkauften Bauelemente werden KI-Chips sein, sagt Gartner weiter voraus. Damit bleibt KI der größte Treiber der Halbleiter-Nachfrage. KI-Beschleuniger für große Modelle benötigen aber viel DRAM und KI-Rechenzentren wiederum viel Flash-Speicher. Daher drosseln die rasant steigenden Preise für Speicherchips auch die Nachfrage nach manchen KI-Chips.
Vor allem erwartet Rajeev Rajput, Senior Principal Analyst bei Gartner, dass die sogenannte „Memflation“ alle Märkte schwächt, die nichts mit KI zu tun haben: „Die Memflation wird die Nachfrage außerhalb des KI-Bereichs bis ins Jahr 2028 hinein zunichte machen oder zumindest verzögern, wobei das Ausmaß je nach Anwendungsbereich variieren wird.“ In den kommenden Monaten sollen die Preise für RAM und Flash besonders stark zulegen, dann schwäche sich die Teuerungsrate wohl ab. Doch erst spät im Jahr 2027 sei mit „nennenswerten“ Rückgängen der Preise zu rechnen.
| Prognose: Weltweiter Umsatz mit Halbleiterbauelementen | |||
| Marktsegment | 2025 | 2026 | 2027 |
| [Mrd. US-$] | [Mrd. US-$] | [Mrd. US-$] | |
| Speicher (RAM, Flash) | 216,3 | 633,3 | 748,1 |
| alle anderen | 589,0 | 686,9 | 806,4 |
| gesamter Markt: | 805,3 | 1.320,2 | 1.554,5 |
| Quelle: Gartner, April 2026 | |||
Der Markt der Halbleiterbauelemente ist unübersichtlich, weil es viele verschiedene gibt. Die größten Umsätze entfallen auf sogenannte Logikchips, beispielsweise Prozessoren, Mikrocontroller, Grafikprozessoren, KI-Beschleuniger, FPGAs, Netzwerk- und Soundchips sowie spezialisierte Controller (USB, PCIe, SATA, I/O) und ASICs. Es folgen die erwähnten Speicherchips.
Aber es gibt noch viele andere Typen wie Sensoren, mikromechanische Systeme (MEMS), Analog-ICs, LEDs und andere optoelektronische Chips oder auch Leistungshalbleiter.
URL dieses Artikels:
https://www.heise.de/-11249507
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] https://www.heise.de/ct
[3] mailto:ciw@ct.de
Copyright © 2026 Heise Medien
Die Deutsche Telekom vermarktet Satelliteninternet des US-Konkurrenten Starlink. Wie der deutsche Marktführer am 8. April 2026 bekannt gab , richtet sich das Angebot Satellite Internet Access by Starlink (SIA) an Großkunden und Organisationen des öffentlichen Sektors.
"Das Angebot sichert Erreichbarkeit genau dort, wo sie für den Betrieb unerlässlich ist: auf Großbaustellen, in abgelegenen Regionen oder im Krisenfall" , sagte Klaus Werner, Geschäftsführer Geschäftskunden Telekom Deutschland.
Nun kann natürlich jedes Unternehmen oder Organisation in Deutschland Starlink-Satellitenschüssel bestellen und das Satelliteninternet in unter eine Stunde installieren.
Eine Telekom-Sprecherin sagte Golem: "Im Gegensatz zum Eigenerwerb bietet die Telekom mit SIA ein vollständig schlüsselfertiges Gesamtpaket aus einer Hand. Als zentraler Ansprechpartner übernimmt sie Montage, Netzanbindung und Service. Priorisierte Businesskapazitäten gewährleisten eine stabile Verbindung – auch bei hoher Auslastung." Priorisierte Daten sind allerdings Teil jedes Businesszugangs bei Starlink.
Auf Wunsch begleiteten Systemspezialisten der Telekom den laufenden Betrieb und stünden bei Bedarf vor Ort zur Verfügung, hieß es weiter. Die Abrechnung laufe über die Telekom-Rechnung.
Eine Brauereikette binde mit SIA einen neuen Standort in Ostdeutschland an, während der Glasfaserausbau dort noch laufe.
Geboten werden den Angaben zufolge bis zu 400 MBit/s im Download und 40 MBit/s im Upload bei einer Latenz von 20 bis 60 Millisekunden. Anders als bei Privatkunden gibt es keine Datenflatrate, sondern es müssen Datenpakete von 50 GByte bis 10 TByte erworben werden.
Privatkunden haben unbegrenztes Volumen. Wenn das Netzwerk extrem ausgelastet ist, etwa abends in dicht besiedelten Gebieten, kann die Übertragungsrate jedoch zugunsten von Businesskunden, die für priorisierte Daten bezahlen, leicht gedrosselt werden.
Wenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Die Star-Wars-Reihe gehört seit Jahrzehnten zu den erfolgreichsten Marken im Unterhaltungs- und Spielwarenbereich. Die Animationsserie The Clone Wars erfreut sich dabei nicht nur bei einem jungen Publikum großer Beliebtheit, da sie ikonische Schlachten, markante Figuren und spannende Gut-gegen-Böse-Szenarien bietet.
Lego greift die Serie regelmäßig auf und übersetzt sie in kompakte Sets, die sich sowohl zum Spielen als auch zum Sammeln eignen.
Das Set Belagerung von Mandalore Battle Pack greift eine zentrale Szene aus der Clone-Wars-Ära auf, die Fans von Ahsoka und Der Mandalorianer gleichermaßen anspricht. Enthalten sind vier Minifiguren: zwei mandalorianische Superkommandos sowie zwei Klontruppler der 501. Legion in der Ahsoka-Version. Alle Figuren sind mit Blastern ausgestattet.
Zum Set gehören außerdem ein kleines Speederbike für dynamische Angriffe sowie eine Barrikade, die sich im Spiel umklappen lässt und zusätzliche Deckung bietet. Beide Elemente verfügen über Stud Shooter, wodurch sich direkte Duelle zwischen den Fraktionen umsetzen lassen sollen.
Mit einer unverbindlichen Preisempfehlung von 19,99 Euro ist es bereits im Lego-Store eines der günstigeren Lego-Star-Wars-Sets. Aktuell liegt der Amazon-Preis bei 12,99 Euro, was einem Rabatt von 35 Prozent entspricht. Dabei handelt es sich um den aktuell besten Preis unter den im Golem-Preisvergleich (powered by Geizhals) gelisteten Shops. Das Set ist laut Keepa-Preistracker erst seit 97 Tagen bei Amazon zu haben. Es war zwischen dem 9. Februar und dem 18. März mit Verkauf und Versand via Amazon ausverkauft. Kein Wunder: Es hat sich allein im letzten Monat laut Produktseite
LEGO Star Wars 75449 Belagerung von Mandalore Battle Pack
Zum AngebotWenn Sie auf diesen Link klicken und darüber einkaufen, erhält Golem eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Nicht spannend genug? Weitere Lego-Sets findet man bei Amazon in der Übersicht
Der Berliner Glasfasernetzbetreiber Eurofiber Netz hat potenzielle Käufer, die aber kein Open Access-Modell verfolgen. Das sagte Unternehmenssprecherin Katrin Löwendorf Golem am 8. April 2026 auf Anfrage. "Aktuell zeichnet sich dabei die Option des Netzverkaufs ab" , erklärte sie. "Da potenzielle neue Eigentümer aktuell keine offene Netzphilosophie verfolgen, können wir den Weiterbetrieb der Eurofiber Netz in ihrem heutigen Umfang nicht sicherstellen."
Das Unternehmen erwartet das Ergebnis des Verkaufsprozesses schon im zweiten Quartal 2026.
Eurofiber wendet sich selbst nicht an Endkunden, sondern bietet sein Netz im Open Access anderen zur Vermarktung an. Das Unternehmen hat bestehende Open-Access-Verträge mit Netzbetreibern wie Tele Columbus, Telefónica, DNS:Net oder Bahnhof aus Schweden. Dazu kommen viele weitere Partnerschaften aus den vergangenen Jahren.
"Da der Verkaufsprozess noch offen ist, kann mit den Verträgen noch alles passieren. Grundsätzlich haben diese auch bei Verkauf weiterhin Bestand. Wir sehen die Verträge als Asset an, das mit einem Netzverkauf zusammenfallen kann oder auch nicht. Wir bereiten uns auf alle Szenarien vor" , sagte Löwendorf.
Das damalige Vattenfall Eurofiber nahm im April 2022 seine ersten beiden Standorte mit XGS-PON-OLTs in Betrieb. Das Unternehmen nutzt in seinem gesamten Netz den Standard XGS-PON. Damit sind bei FTTH-Topologie symmetrische Datenraten von 10 Gigabit pro Sekunde möglich. Eurofiber baut aber auch Fiber To The Building (FTTB) aus.
Von den geplanten 500.000 Haushalten sind bereits 150.000 angeschlossen. Weitere sind den Angaben zufolge in Arbeit.
Dass die niederländische Konzernmutter Eurofiber in Berlin zum Verkauf stellt, wurde bereits im Mai 2025 bekannt . Offenbar gelang es Eurofiber nicht, nennenswerte Umsätze auf dem hart umkämpften Glasfasermarkt zu generieren, wo auch die Deutsche Telekom, Vodafone, Tele Columbus und DNS:Net aktiv sind.
Auf der Mac-Tastatur gibt es Sondertasten für Audiovolumen und Bildschirmhelligkeit. So funktionieren die auch bei Drittanbieter-Displays.
Mein älteres Apple-Display habe ich durch einen anderen externen Monitor mit eingebauten Lautsprechern ersetzt. Bei meinem alten Bildschirm konnte ich Helligkeit und Lautstärke über die Tastatur verändern, beim neuen geht das nicht. Wieso?
Tatsächlich funktioniert das unter macOS mit den Bordmitteln nur mit den wenigsten Monitoren, etwa Apples Studio und Pro Display sowie dem eingestellten LG Ultrafine 5K.
Viele Hersteller nutzen die Kommunikationsschnittstelle Display Data Channel/Command Interface (DDC/CI). Apple unterstützt zwar grundsätzlich DDC/CI, hat diesen Standard aber nicht vollständig in macOS implementiert.
Ihr Mac schickt zwar ein digitales Signal an den Bildschirm, die Regelung von Helligkeit oder Lautstärkepegel bleibt aber dem Endgerät überlassen, ähnlich wie bei einem Digitalverstärker.
Daher lassen sich bei den meisten Monitoren weder die Helligkeit noch die Lautstärke mit Bordmitteln über Tastatur und Maus oder die Systemeinstellungen von macOS regeln. Stattdessen muss man auf das mehr oder weniger bequeme Bildschirmmenü und die Bedienelemente des Monitors zurückgreifen.
Wenn Ihr Monitor DDC/CI unterstützt, geht es auch per Zusatzsoftware. Manche Hersteller bieten für bestimmte Monitormodelle eigene Mac-Apps an, über die sich die Helligkeit unter macOS einstellen lässt.
Dazu gehören etwa BenQ mit dem DisplayPilot oder der Dell Display and Peripheral Manager (kurz DDPM). Hier funktioniert die Helligkeitseinstellung meist nach Installation und Start der Software. Eventuell müssen Sie den Mac noch einmal neu starten.
Wenn der Hersteller Ihres Monitors keine solche App anbietet, greifen Sie zur Open-Source-Software MonitorControl.
Auch kommerzielle Lösungen wie BetterDisplay, Lunar Pro oder DisplayBuddy können Lautstärke und Helligkeit steuern. Idealerweise schließen Sie den Mac per DisplayPort oder USB-C / Thunderbolt an. Über HDMI funktionierte DDC/CI laut Nutzerberichten an einigen ARM-Macs wie dem Mac mini nicht.
Suchen Sie zunächst im Menü Ihres Bildschirms, ob sich dort eine Einstellung namens „DDC/CI“ oder „DDC“ finden lässt, und aktivieren Sie diese gegebenenfalls.
Mitunter ist der Punkt auch tief in einem Untermenü versteckt. Anschließend installieren Sie MonitorControl und öffnen die App. In der Menüleiste finden Sie zwei Regler, mit denen Sie Helligkeit und Lautstärke verändern können. Im Reiter „Tastatur“ in den Einstellungen von MonitorControl lässt sich zudem die Tastensteuerung aktivieren oder mit anderen Tasten belegen.
Falls die Lautsprecher Ihres Monitors stumm bleiben, stellen Sie sicher, dass Sie die eingebauten Boxen als Ausgabegerät in macOS ausgewählt haben. Möglicherweise müssen Sie die Lautstärke Ihres Monitors zunächst über das Bildschirmmenü erhöhen, bevor die Regelung über die Software klappt.
URL dieses Artikels:
https://www.heise.de/-11246261
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] https://www.heise.de/mac-and-i
[3] mailto:hze@heise.de
Copyright © 2026 Heise Medien
