Anmelden
Meta-Brille: Bald „First class“ auf dem iPhone dank EU?
(Bild: JLStock/Shutterstock.com)
Ähnlich wie AirPods und andere Apple-Produkte sollen auch Zubehöranbieter mit dem iPhone kommunizieren. Zu Metas Brillen und VR-Headsets gibt es nun neue Infos.
Auf einer nur für Entwickler zugänglichen Seite stellt Apple Informationen zur Verfügung, wie Hardware von Meta künftig mit iPhone und iPad interagieren sollen. Apple ist aufgrund der Regulierung durch den Digital Markets Act (DMA) [1] gezwungen, Third-Party-Geräte ähnlich gut an seine zwei regulierten Gerätefamilien anzubinden, wie dies bereits bei eigenen Produkten wie AirPods, Airtags oder der Apple Watch der Fall ist. Die Pläne dürften bis zum kommenden Jahr umgesetzt werden. Explizit benannt sind die VR-Headset-Serie Meta Quest sowie die Brillen der Meta-Ray-Ban-Glasses-Serie. Die Seite „Interoperability Requests in the EU“ für Entwickler ist nur mit einem Developer-Account zugänglich.
Meta wünscht sich [2] (Developer-Account erforderlich) explizit, dass User Meta-Hardware direkt pairen und dieses Pairing dann auch auf anderen im Besitz befindlichen iPhones und iPads automatisch nutzen kann – und zwar durch „die Koordination über Metas eigene Cloud-Dienste“. Die Bitte der Facebook-Mutterfirma kam Ende Oktober 2025, Apple reagierte einige Tage später mit einem „Eligibility Review“.
Aktueller Stand der Dinge ist, dass die Entwicklungsarbeiten bei Apple noch bis iOS 27 und iPadOS 27 dauern. Allerdings noch nicht in den ersten, ab Herbst zur Verfügung stehenden Versionen. Stattdessen nennt Apple einen Zeitraum im Frühjahr 2027 – mit welcher Version ist noch unklar. Dann sollen Third-Party-Anwendungen Zugriff auf das notwendige kryptografische Material erhalten, um ein Pairing abzusichern. „Apple entwickelt derzeit ein Protokoll, mit dem ein Apple-Gerät einen sicheren Sitzungsschlüssel ableiten kann, der zur Authentifizierung und Verschlüsselung der Übertragungsverbindung zwischen dem Apple-Gerät und einem Zubehörteil eines Drittanbieters dient.“
Die Synchronisation mit anderen Apple-Geräten ist dabei vorgesehen – ob tatsächlich über die Cloud des jeweiligen Herstellers, bleibt offenbar abzuwarten. Meta meldete sich zuletzt im März bei Apples Entwicklerteam. Dabei ging es um die Frage, ob das notwendige AccessorySetupKit (ASK) von Apple den ganzen Bildschirm übernehmen muss oder nicht. Meta hätte hier gerne eine einfachere Lösung – den direkten Start der eigenen App.
Unterdessen gibt es Neuigkeiten in Sachen DMA-Öffnung von KI-Systemen: Google wird von der EU nun gezwungen, sein Android-Betriebssystem vollständig für Assistenten eigener Hersteller zugänglich [3] zu machen. Apple versucht derzeit, genau dies zu verhindern und hat deshalb auch Siri AI zunächst nicht in die EU [4] gebracht.
URL dieses Artikels:
https://www.heise.de/-11367394
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Tap-to-Pay-Funktion mit dem iPhone.
(Bild: Apple)
Lange setzte Apple sogar bei Apple Pay in seinen Stores auf Bezahlterminals. Nun wechselt das Unternehmen auf interne Technik.
Dogfooding nennt man es, wenn ein Unternehmen Technik, die man seiner Kundschaft anbietet, auch selbst einsetzt. Apple versucht das nun bei seinem Tap-to-Pay-Bezahlsystem [1], das schon seit mehreren Jahren auf iPhones ab dem Modell X zur Verfügung steht. Laut einem Bericht werden bisherige Bluetooth-Terminals und andere Sonderlocken-Hardware innerhalb der Ladenkette des Konzerns aussortiert. Kunden sollen direkt im Apple Retail Store am Handy des Mitarbeiters via NFC-Kreditkarte sowie anderen NFC-Verfahren wie Apple Pay bezahlen können. Teilweise ist das bereits umgesetzt, nun erfolgt ein flächendeckender Rollout, schreibt die Finanznachrichtenagentur Bloomberg.
Tap-to-Pay gibt es in Deutschland bereits seit 2024 [2]. Apple arbeitet dazu mit verschiedenen Bezahldiensten zusammen. Der in iPhones integrierte NFC-Kartenchip wird dabei zum Auslesen von Karten genutzt, die Buchung direkt über eine Zahlungsanbieter-App abgewickelt. Unternehmen, die das anbieten [3], sind SumUp, viva.com, die Sparkassen oder MyPOS. Händler müssen mit diesen einen Vertrag schließen und zahlen dann prozentuale Gebühren, teilweise auch Monatstarife.
Für Endkunden ohne geschäftliche Basis ist die Funktion allerdings nicht gedacht, man kann also nicht einfach ein Konto eröffnen, um dann von Freunden Kreditkartenzahlungen zu akzeptieren. Dennoch ist die Funktion nützlich, da man zuvor stets ein angebundenes Kartenterminal eines externen Anbieters benötigt hatte, wie es auch Apple einsetzte.
Zwar begann die Umstellung auf Tap-to-Pay in Apples Ladengeschäften [4] bereits vor einigen Jahren, doch das dabei verwendete iPhone 14 machte manchmal Probleme, so dass die Terminals weiterhin mitgeführt wurden. Der Grund: Die Geräte sollen Probleme mit Kreditkarten aus Metall gehabt haben, beispielsweise die Platin-Karten von American Express. Diese waren teilweise gar nicht lesbar.
Hinzu kam, dass man die Stelle des NFC-Lesers genau treffen musste, ein Problem, das Nutzer etwa auch von Tools wie der AusweisApp [5] (und dem oben angebrachten RFID-Leser) kennen. Neuere Modelle wie das iPhone 16 lesen allerdings zuverlässiger und sollen auch mit Metallkarten zurechtkommen. Das sei der Grund, warum Apple nun die externen Terminals ausrangiere, schreibt Bloomberg [6].
URL dieses Artikels:
https://www.heise.de/-11367380
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Manuel Masiero / KI / iX)
100 Prozent Code Coverage und alle Tests grün geben kein verlässliches Korrektheitsurteil. Hinter dieser Beobachtung steckt mehr als nur Pech.
Geht es um Codequalität, ist die Code Coverage eine besonders verführerische Metrik. Sie ist leicht zu erheben, in Pipelines durchzusetzen und scheint auf den ersten Blick eine objektive Aussage darüber zu treffen, wie gründlich ein System getestet ist. Bei näherer Betrachtung zeigt sich aber, dass das Testen selbst an fundamentale Grenzen stößt, an denen auch die ausgefeilteste Coverage-Messung nichts ändern kann. Das Halteproblem aus Teil 2 [1] spielt dabei eine neue Rolle und wie wir in Teil 3 [2] gesehen haben, lässt sich Codequalität ohnehin nicht in eine einzige Zahl pressen.
Vor einigen Jahren entwickelte ein Entwicklungsteam meines Unternehmens eine Implementierung des Chord-Algorithmus [3], eines klassischen Verfahrens für strukturierte Peer-to-Peer-Netzwerke. Chord organisiert die teilnehmenden Knoten in einem virtuellen Ring und erlaubt es, Key-Value-Paare effizient zu speichern und wiederzufinden, auch wenn Knoten kommen und gehen. Das Team arbeitete sorgfältig: Alle Unit-Tests waren grün, die Code Coverage lag bei 100 Prozent.
Trotzdem hatte die Implementierung einen Bug. Wurde ein Knoten im laufenden Netzwerk abgeschossen, stürzten die übrigen Knoten dominoartig ab. Das Problem lag nicht im Code eines einzelnen Knotens, sondern im Zusammenspiel mehrerer Knoten. Bestimmte Konstellationen, in denen Nachrichten zwischen Knoten in einer ungünstigen Reihenfolge eintrafen, führten zu logischen Widersprüchen, die beim Betrachten eines einzelnen Knotens nicht erkennbar waren. Die Tests deckten jede einzelne Funktion vollständig ab, aber sie testeten nicht das, was am Ende den Ausfall verursachte.
Diese Erfahrung steht stellvertretend für ein viel allgemeineres Phänomen. Tests können viele Bugs finden, aber sie können nicht garantieren, dass keine mehr da sind. Und das ist nicht nur eine pragmatische Einschränkung, sondern hat tiefer liegende Ursachen.
Code Coverage misst, wie viel Prozent des Codes durch Tests ausgeführt werden. Eine Zeile, die mindestens einmal im Rahmen eines Tests durchlaufen wird, gilt als abgedeckt. Das klingt zunächst sinnvoll, denn nicht ausgeführter Code ist mit Sicherheit nicht getestet. Die Umkehrung gilt aber nicht: Ausgeführter Code ist nicht automatisch geprüfter Code.
Ein einfaches Beispiel zeigt das Problem. Eine Funktion gibt eine Liste sortiert zurück. Ein Test ruft diese Funktion mit einer beliebigen Liste auf, prüft aber nicht das Ergebnis. Die Coverage-Messung stellt fest, dass alle Zeilen der Funktion durchlaufen wurden, und meldet 100 Prozent Abdeckung. Trotzdem hätte die Funktion auch eine zufällige Permutation zurückgeben können, ohne dass der Test es bemerkt hätte. Coverage misst Ausführung, nicht Verifikation.
Doch selbst wenn die Tests ihre Ausgaben gewissenhaft prüfen, bleibt eine zweite Lücke. Coverage misst die Strukturen des Codes, nicht die Interaktionen zwischen Komponenten. Im Chord-Beispiel waren die einzelnen Funktionen jedes Knotens vollständig abgedeckt, aber das Zusammenspiel mehrerer Knoten in spezifischen zeitlichen Konstellationen war es nicht. Was Coverage nicht erfasst, ist die kombinatorische Explosion der möglichen Reihenfolgen, in denen Nachrichten ausgetauscht werden, in denen Threads parallel laufen, in denen Knoten verbunden oder getrennt sind. Eine Coverage von 100 Prozent ist deshalb keine Aussage über die Korrektheit des Systems, sondern eine Aussage darüber, dass kein Code übersehen wurde.
Diese strukturelle Asymmetrie zwischen Tests und Korrektheit hat Edsger Dijkstra bereits 1969 auf einer NATO-Konferenz zur Softwaretechnik in einem inzwischen berühmten Satz auf den Punkt gebracht: Testing shows the presence, not the absence of bugs [9]. Wenig später formulierte er die ausführlichere Variante in seinen „Notes on Structured Programming“: Programmtests können benutzt werden, um die Anwesenheit von Fehlern zu zeigen, niemals aber deren Abwesenheit.
Die Aussage klingt banal, hat aber weitreichende Konsequenzen. Ein Test, der einen Bug findet, beweist die Existenz dieses Bugs. Ein Test, der keinen Bug findet, beweist nichts darüber, ob weitere Bugs existieren. Die übliche Beweisstruktur in den Naturwissenschaften, dass das Ausbleiben eines Gegenbeispiels die Hypothese stützt, gilt hier nur in sehr eingeschränktem Sinne. Solange nicht alle möglichen Eingaben und Zustände durchgetestet wurden, bleibt jeder Bereich eine potenzielle Fehlerquelle. Und alle möglichen Eingaben und Zustände durchzutesten, ist in praktisch jedem nicht-trivialen Programm aussichtslos.
Schon einfache Funktionen haben mehr mögliche Eingabekombinationen, als sich vollständig durchprobieren lassen. Eine Funktion, die drei Ganzzahlen mit jeweils 32 Bit entgegennimmt, hat 2 hoch 96 mögliche Eingabekombinationen, ungefähr 80 Quadrillionen. Selbst bei einer Milliarde Tests pro Sekunde würde es mehr als zwei Billionen Jahre dauern, alle Kombinationen zu testen, ein Vielfaches des Alters des Universums. Und das ist eine triviale Funktion. Sobald Strings, Listen oder beliebige Objekte als Eingaben hinzukommen, wird der Eingaberaum buchstäblich unendlich groß.
Dieses Phänomen wird als Zustandsraumexplosion bezeichnet. Bei zustandsbehafteten Programmen, also fast jedem realen System, kommt eine weitere Dimension hinzu: Das Verhalten hängt nicht nur von der aktuellen Eingabe ab, sondern auch vom internen Zustand, der wiederum durch frühere Eingaben geprägt ist. Eine Webanwendung mit zwanzig Sessions, jeweils mit unterschiedlich gesetzten Variablen, hat einen Zustandsraum, der sich nicht mehr sinnvoll überschauen lässt. Bei verteilten Systemen wie im Chord-Beispiel multipliziert sich der Zustandsraum eines einzelnen Knotens mit der Anzahl der Knoten und ihrer möglichen Kommunikationsmuster. Was beim Einzelknoten noch handhabbar wirkte, wird im Verbund unbeherrschbar.
Die übliche Antwort auf dieses Problem heißt Äquivalenzklassen. Statt jede Eingabe einzeln zu testen, werden Eingaben in Klassen zusammengefasst, die aus Sicht des Programms gleich behandelt werden sollten. Statt alle ganzen Zahlen zu testen, reichen ein typischer positiver Wert, ein typischer negativer Wert, die Null und die Grenzwerte. Das ist pragmatisch und meistens ausreichend, aber es setzt voraus, dass die Klassenbildung korrekt ist, dass also alle relevanten Fälle erkannt wurden. Genau hier liegen viele Bugs verborgen: in den Fällen, deren Eigenständigkeit niemand erkannt hat.
Selbst wenn sich der Eingaberaum vollständig durchprobieren ließe, bliebe eine zweite, oft übersehene Frage. Woher weiß ein Test, was die richtige Ausgabe ist? Diese Frage ist als Orakel-Problem in der Testtheorie bekannt. Ein Test besteht im Kern aus zwei Teilen: einer Eingabe und einer Erwartung an die Ausgabe. Die Eingabe lässt sich automatisch generieren, die Erwartung im Allgemeinen nicht.
Bei mathematischen Funktionen mag das Orakel offensichtlich sein. Eine Sortierfunktion soll eine sortierte Liste liefern, das lässt sich prüfen. Eine Quadratwurzel soll eine Zahl liefern, die mit sich selbst multipliziert die Eingabe ergibt. Bei realen Anwendungen ist die Lage komplizierter. Was ist die richtige Antwort einer Suchmaschine auf eine bestimmte Anfrage? Was ist die richtige Reihenfolge in einem Newsfeed? Was ist die richtige Empfehlung in einem Webshop? In all diesen Fällen gibt es kein objektives Orakel, sondern nur Heuristiken, Spezifikationen, Geschäftsregeln, manchmal nur menschliches Urteil. Tests können diese Orakel approximieren, aber sie sind selbst eine Quelle möglicher Fehler.
Im Chord-Beispiel zeigt sich das Orakel-Problem in einer besonders perfiden Variante. Die einzelnen Funktionen jedes Knotens hatten klar definierte Erwartungen, und die Tests prüften diese Erwartungen korrekt. Aber das richtige Verhalten des Systems beim Ausfall eines Knotens war nirgendwo als Orakel formuliert, weil niemand explizit darüber nachgedacht hatte. Tests können nur prüfen, was jemand vorher als Erwartung formuliert hat. Was niemand erwartet, kann auch niemand testen.
Aus Teil 2 dieser Serie [12] ist das Halteproblem [13] bereits bekannt: Alan Turing hat 1936 bewiesen, dass es kein allgemeines Verfahren geben kann, das für ein beliebiges Programm und eine beliebige Eingabe entscheidet, ob das Programm terminiert oder in eine Endlosschleife gerät. Im Kontext des Testens taucht dieses Resultat in einer subtileren Variante auf.
Wenn ein Test einen Code aufruft, dann muss die Test-Infrastruktur entscheiden, wann sie diesen Aufruf abbricht. Bleibt das Programm einfach hängen, läuft auch der Test ewig. Das übliche Mittel ist ein Timeout: Nach einer bestimmten Zeit gilt der Test als fehlgeschlagen. Dieses Vorgehen ist eine Heuristik, kein Beweis. Ein Test mit Timeout kann nicht zwischen einem Programm, das in einer Endlosschleife steckt, und einem Programm, das einfach nur sehr lange braucht, unterscheiden. Beide werden gleichermaßen als Fehler gemeldet, oder beide als Erfolg, je nach Konfiguration. Die fundamentale Unentscheidbarkeit des Halteproblems schlägt hier auf eine ganz praktische Frage durch: Wie lange darf ein Test laufen, bevor er als gescheitert gilt?
Eine verwandte Konsequenz betrifft die Generierung von Tests. Werkzeuge, die Tests automatisch erzeugen wollen, müssen entscheiden, welche Pfade durch den Code überhaupt erreichbar sind. Diese Entscheidung ist im Allgemeinen ebenfalls unentscheidbar, was aus Rice’s Theorem [14] folgt, das bereits in Teil 2 eine Rolle spielte. Praktische Werkzeuge nähern sich dem mit Heuristiken an, aber sie können nicht garantieren, alle relevanten Pfade zu finden.
Trotz dieser fundamentalen Grenzen gibt es Verfahren, die deutlich mehr leisten als klassisches Beispiel-basiertes Unit-Testing. Sie verfolgen unterschiedliche Strategien, um den Eingaberaum strukturiert zu erschließen, auch wenn er sich nicht vollständig durchprobieren lässt.
Beim Property-based Testing [15] werden nicht einzelne Beispiele getestet, sondern Eigenschaften, die für alle Eingaben gelten sollen. Statt zu prüfen, dass das Sortieren der Liste [3, 1, 2] das Ergebnis [1, 2, 3] liefert, wird die Eigenschaft formuliert, dass das Ergebnis einer Sortierung dieselben Elemente enthält wie die Eingabe und in aufsteigender Reihenfolge vorliegt. Das System generiert dann automatisch eine große Zahl zufälliger Eingaben und prüft die Eigenschaft. Wird ein Gegenbeispiel gefunden, versucht das Werkzeug, es zu einem minimalen Fall zu reduzieren, der den Bug noch zeigt. Property-based Testing wurde mit dem Werkzeug QuickCheck für Haskell [16] populär und ist inzwischen für viele Programmiersprachen verfügbar.
Beim Fuzzing [17] wird das System mit zufällig generierten oder mutierten Eingaben bombardiert, oft mit dem Ziel, Abstürze, Sicherheitslücken oder unerwartete Zustände zu finden. Moderne Fuzzer nutzen Coverage-Informationen, um Eingaben zu bevorzugen, die neue Codepfade auslösen, und arbeiten sich auf dem Weg systematisch in den Eingaberaum vor. Fuzzing hat zahlreiche schwerwiegende Bugs in weitverbreiteten Bibliotheken aufgedeckt, etwa in Browsern, Bildverarbeitungs-Bibliotheken und Kryptographie-Implementierungen.
Beim Mutation Testing [18] schließlich werden nicht die Programme, sondern die Tests selbst getestet. Das Werkzeug nimmt kleine Änderungen am Quellcode vor, etwa wird ein Plus zu einem Minus, ein Größer-als zu einem Kleiner-als, eine Bedingung negiert. Anschließend werden die Tests gegen den derart mutierten Code laufen gelassen. Wenn die Tests die Mutation nicht bemerken, ist das ein Hinweis darauf, dass die Tests die betroffene Stelle nicht wirklich prüfen, sondern den Code nur durchlaufen lassen. Mutation Testing schließt damit genau die Lücke, die Coverage offenlässt: Es misst nicht, ob Code ausgeführt wurde, sondern ob seine Korrektheit tatsächlich überprüft wird.
All diese Verfahren erweitern die Möglichkeiten des Testens erheblich. Aber keines von ihnen löst das fundamentale Problem. Property-based Testing kann unendlich viele Eingaben nicht in endlicher Zeit prüfen, sondern nur stichprobenartig. Fuzzing findet viele Bugs, aber nicht alle. Mutation Testing prüft die Tests, aber das Orakel-Problem bleibt. Die Verfahren machen Tests besser, aber sie heben die Grenzen nicht auf.
Der Weg vom Chord-Beispiel über Code Coverage, Dijkstras Bonmot, Zustandsraumexplosion, Orakel-Problem und Halteproblem zeigt eine durchgängige Linie. Tests können niemals beweisen, dass ein Programm korrekt ist. Sie können nur Vertrauen aufbauen. Dieses Vertrauen ist nicht wertlos, im Gegenteil: Es ist der pragmatische Ausweg aus einer Reihe theoretischer Unmöglichkeiten. Aber es darf nicht mit einem Beweis verwechselt werden.
Was diese Einsicht in der Praxis bedeutet, lässt sich in wenige Punkte fassen. Tests sollten so geschrieben werden, dass sie aussagekräftige Eigenschaften prüfen, nicht nur Code zur Ausführung bringen. Eine hohe Coverage ist ein notwendiges, aber kein hinreichendes Kriterium für gute Tests. Verschiedene Testarten ergänzen sich, denn Unit-Tests, Integrationstests, End-to-End-Tests, Property-based Tests und Fuzzing decken jeweils unterschiedliche Klassen von Fehlern ab. Und vor allem: Wenn ein System produktiv geht, sollte das Vertrauen in die Tests durch Mechanismen ergänzt werden, die mit den verbleibenden Fehlern umgehen können. Monitoring, Observability, Circuit Breaker, Rollback-Strategien und Chaos Engineering sind keine Eingeständnisse mangelnder Testqualität, sondern Ausdruck der Einsicht, dass Tests allein nicht reichen können.
Im Chord-Beispiel war die Lehre genau diese: Die Tests selbst waren nicht falsch, sie hatten nur einen anderen Geltungsbereich als das Team angenommen hatte. Erst der Betrieb mit mehreren Knoten und gezielt herbeigeführten Ausfällen brachte das Problem zutage. Das ist kein Versagen des Testens, sondern eine Konsequenz seiner prinzipiellen Grenzen.
Eine andere Klasse von Grenzen, die in dieser Serie noch nicht behandelt wurde, betrifft nicht die Entscheidbarkeit, sondern die Effizienz. Es gibt Probleme, die theoretisch lösbar sind, für die aber kein praktikabler Algorithmus bekannt ist. Im nächsten Teil geht es um eine der wichtigsten offenen Fragen der theoretischen Informatik, die zugleich eine sehr konkrete Bedeutung für den Alltag von Entwicklerinnen und Entwicklern hat: P versus NP.
URL dieses Artikels:
https://www.heise.de/-11355919
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Pincasso / Shutterstock.com)
Die neue Methode FindByThumbprint() sucht ein digitales Zertifikat anhand des SHA-Fingerabdrucks.
In der Klasse X509Certificate2Collection existiert eine neue Methode FindByThumbprint(), um ein digitales Zertifikat anhand des SHA-Fingerabdrucks mit einem bestimmten SHA-Algorithmus zu finden.
Bisher gab es zur Suche nach Zertifikatsfingerabdrücken die Methode Find():
FreshRSS X509Certificate2Collection coll =
store.Certificates.Find(X509FindType.FindByThumbprint, thumbprint, false);Diese Methode hat immer nach Fingerabdrücken mit dem SHA-1-Algorithmus gesucht. Da SHA-2-256 (SHA256) und SHA-3-256 die gleiche Länge haben, bestand Verwechselungsgefahr. Das löst nun die neue Methode FindByThumbprint(), in der man den SHA-Algorithmus angeben kann.
Folgender Beispielcode zeigt den Einsatz von FindByThumbprint():
public void SearchCertificateByFingerprint()
{
CUI.Demo(nameof(SearchCertificateByFingerprint));
CUI.H2("Zertifikat suchen im Store");
string thumbprint = "B9749C08E0D33C5643B7DE067A0B365870B9A9A9";
X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly);
// Alt: Sucht immer nach SHA1-Thumbprint
//X509Certificate2Collection coll = store.Certificates.Find(X509FindType.FindByThumbprint, thumbprint, false);
// neu: Auswahl des Hash-Algorithmus
X509Certificate2Collection coll = store.Certificates.FindByThumbprint(HashAlgorithmName.SHA256, thumbprint);
if (coll.Count == 0)
{
CUI.Warning($"Zertifikat mit Thumbprint {thumbprint} nicht gefunden.");
}
foreach (var item in coll)
{
Console.WriteLine(item.IssuerName.Name + ": " + item.Thumbprint + " -> " + item.SignatureAlgorithm.FriendlyName);
}
}
URL dieses Artikels:
https://www.heise.de/-11368310
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Christian Horz/ Shutterstock.com)
Trügerische Wahlfreiheit: Das GModG streicht Vorgaben, baut aber eine potenzielle Kostenfalle auf. Was die Gasheizung in den kommenden Jahren teuer macht.
Nach monatelangem Hickhack haben Bundestag und Bundesrat das Gebäudemodernisierungsgesetz (GModG) Anfang Juli 2026 verabschiedet. Die verpflichtende 65-Prozent-Vorgabe für erneuerbare Energien entfällt – künftig darf man also auch wieder klassische Gas- und Ölheizungen einbauen.
Ganz ohne Vorgaben kommen aber auch die nicht davon: Über die sogenannte Biotreppe muss dem Gas ab 2029 schrittweise ein steigender Anteil Biokraftstoffe beigemischt werden. Für Hauseigentümer klingt das zunächst nach einem pragmatischen Mittelweg zwischen Klimaschutz und Wahlfreiheit – oder wie die Bundesregierung es nennt – Technologieoffenheit.
Wie teuer dieser „Pragmatismus“ über 20 Jahre werden könnte – im Vergleich zu Wärmepumpe und Fernwärme – und welche Entwicklungen die Kosten einer fossilen Heizung künftig noch stärker beeinflussen könnten, zeigt dieser Artikel anhand der Gasheizung und Biomethan.
URL dieses Artikels:
https://www.heise.de/-11348650
Links in diesem Artikel:
Copyright © 2026 Heise Medien
TSMCs Komplex im US-amerikanischen Arizona. Drumherum ist reichlich Platz für weitere Werke vorhanden.
(Bild: Taiwan Semiconductor Manufacturing Co., Ltd.)
Der Weltmarktführer TSMC will weitere Halbleiterwerke in den USA bauen. Dafür stehen weitere 100 Milliarden US-Dollar bereit.
Der weltweit größte Chipauftragsfertiger TSMC erhöht die Investitionen in den USA ein weiteres Mal: von zuletzt geplanten 165 Milliarden US-Dollar auf nunmehr bis zu 265 Milliarden. Dafür will das Unternehmen mehrere Halbleiterwerke zur Herstellung von Chips sowie Packaging-Werke zur weiteren Verarbeitung bauen.
Die Ankündigung erfolgte im Rahmen der Analystenkonferenz zu den jüngsten Geschäftszahlen (Transkript bei Seeking Alpha [1]). TSMC-Chef C.C. Wei hielt sich zum genauen Umfang und dem Zeitrahmen aber bedeckt. Denkbar wären etwa vier weitere Werke, sagte er.
Ein Blick auf TSMCs Kapitalausgaben (Capital Expenditures, Capex) zeigt, wie lange sich die Investitionen hinziehen können: Jüngst hat die Firma das Capex-Budget fürs Jahr 2026 auf 60 Milliarden bis 64 Milliarden US-Dollar erhöht. Neben den US-Werken entstehen aber auch 13 neue in Taiwan, ein neues in Japan und auch das ESMC-Werk in Deutschland [2] ist noch nicht fertiggestellt, ebenso laufen noch andere Bauprojekte in den USA.
Bisher hat TSMC ein erstes Halbleiterwerk in Phoenix, Arizona, fertiggestellt, in dem Chips aus der 4-Nanometer-Generation vom Band laufen. AMD etwa lässt dort Epyc-Serverprozessoren herstellen [3] und Nvidia Blackwell-Beschleuniger. Für Apple ist dieses Werk wenig geeignet; in Taiwan produziert TSMC für Apple dieses Jahr bereits Prozessoren mit 2-nm-Technik.
Ein zweites Halbleiterwerk für 3- und 2-nm-Chips [4] befindet sich derzeit am selben Standort im Bau und soll ab 2028 den Betrieb aufnehmen. Im April 2024 kündigte TSMC drei weitere Halbleiterwerke [5] für Arizona an. Im März 2025 folgte eine weitere Ankündigung mit zusätzlichen Halbleiterwerken [6], ersten eigenen US-Packaging-Standorten und einem Forschungszentrum.
TSMC plant sogenanntes Advanced Packaging in den USA, bei dem mehrere Chiplets und Speicherstapel auf einem gemeinsamen Träger verheiratet werden. Bisher hat TSMC diese Weiterverarbeitung in den USA lokalen Partnern wie Amkor überlassen.
Die neu angekündigten Halbleiterwerke dürften für 2030 oder später gedacht sein. Vermutlich wird TSMC auch da nicht seine modernste Fertigungstechnik in die USA bringen. Wei ließ sich nur auf „2 Nanometer oder besser“ festnageln, nicht aber auf eine feste Zusage neuerer Technik. In Taiwan will TSMC 2029 mit A13 und A12 mehr als eine Fertigungsgeneration weiter sein.
„Ich gehe davon aus, dass die Nachfrage von heute an – wahrscheinlich bis 2029 oder 2030 – sehr stark sein wird“, sagte Wei. „Ob es zwischendurch zu einem Rückgang kommen wird oder nicht, weiß ich nicht so genau. Aber der Trend deutet meiner Meinung nach darauf hin, dass wir Zeugen einer Art neuer Industrie werden, einer neuen KI-Industrie.“
URL dieses Artikels:
https://www.heise.de/-11367592
Links in diesem Artikel:
Copyright © 2026 Heise Medien
iOS 27: Viele kleine nützliche Neuerungen.
(Bild: Apple)
iOS 27, iPadOS 27, macOS 27 und Co. stehen zum Download bereit, wenn auch nur als öffentliche Beta. Ein Überblick der verwendbaren Geräte – und wichtige Tipps.
Die seit dieser Woche verfügbaren Public Betas von iOS 27, iPadOS 27, macOS 27, watchOS 27, tvOS 27, visionOS 27 sowie der neuen HomePod Software 27 [1] (plus Beta-Firmware für AirPods) verlocken zahlreiche Interessierte, Apples Vorabversionen zu installieren. Einen Hands-on-Bericht dazu lesen Sie hier. [2] Doch bevor man damit loslegt, sollte man sich sein Vorgehen gut überlegen. Läuft die Beta überhaupt auf meinem Gerät? Habe ich eine Test-Hardware, die ich verwenden kann? Mit welchen Daten sollte ich testen? Und wie werde ich die Beta später gegebenenfalls wieder los? Ein Überblick zu den wichtigsten Fragen.
Beim iPhone geht es bei Generation 11 beziehungsweise SE der dritten Generation los. Beim iPad Pro sind es alle 11-Zoll-Modelle ab der 2. Generation, alle 12,9-Zoll-Modelle ab der 4. Generation, alle iPad-Air-Geräte ab Generation 4, das Standard-iPad ab Generation 9 und das iPad mini ab Generation 6. Beim Mac muss es eine Maschine mit Apple Silicon [3] sein, Intel-Macs sind raus. Die Apple Watch benötigt mindestens Series 9, SE 3 oder Ultra 2 [4], beim Apple TV geht es ab der zweiten Version des 4K-Modells (von 2021) los. visionOS-Geräte werden vollständig unterstützt (M2 und M5).
Grundsätzlich gilt, dass man keinesfalls Produktivgeräte nutzen sollte, so verlockend das auch erscheinen mag. Betas können Datenverluste erzeugen [5] und andere Probleme bereiten, die man auf der täglich in Verwendung befindlichen Hardware nicht sehen möchte. Am sichersten ist es daher, ein eigenes Betagerät aufzusetzen, etwa ein älteres iPhone oder einen älteren Mac. Wer gänzlich auf Nummer sicher gehen will, nutzt für die Beta einen eigenen Apple-Account, um iCloud-Probleme [6] zu vermeiden. Ein Nachteil ist bei alledem, dass man Siri AI [7] dann nicht mit Echtdaten ausprobieren kann. Es ist aber leicht, sich Informationen von seinem Produktivgerät auf die Test-Hardware zu kopieren.
Vor jeglicher Installation eines neuen Betriebssystems sollte stets ein aktuelles Backup angelegt werden, auf dem iPhone am besten verschlüsselt [8] über den Mac, auf dem Mac etwa via Time Machine oder Werkzeuge wie Carbon Copy Cloner [9]. Setzen Sie für die Public Beta ein Testgerät neu auf, was Sie, wie erwähnt, tun sollten, ist das nicht unbedingt notwendig, kann aber dennoch sinnvoll sein.
Wenn Sie, wie oben empfohlen, mit einem Testgerät arbeiten, müssen Sie die Beta nicht löschen. Sie können einfach den gesamten Betazyklus durchlaufen, bis dann (wahrscheinlich) im September die jeweilige Finalversion vorliegt, die auch auf Produktivhardware landen darf. Sobald sich die Finalversion ankündigt, schalten Sie den Bezug der Betaversion in den Systemeinstellungen einfach ab. Sollten Sie wirklich ein Downgrade vornehmen wollen, lässt sich dafür auf iPhone und iPad der Wiederherstellungsmodus über einen Mac oder PC mit anschließendem Einspielen des Backups [10] verwenden. Ähnlich läuft es am Mac [11], hier gibt es einen eigenen Wiederherstellungsmodus auf dem Gerät selbst. Eine Apple Watch wird über die Apple-Watch-App auf dem iPhone wiederhergestellt, Hinweise zur Wiederherstellung von Apple-TV-Geräten listet Apple hier [12]. Der Prozess ist jeweils langwierig – nicht nur die Wiederherstellung, sondern auch das Einspielen des Backups. Das führt uns erneut zur Empfehlung, für Public Betas ein eigenes Testgerät zu verwenden.
URL dieses Artikels:
https://www.heise.de/-11364187
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Pincasso / Shutterstock.com)
Neben mehr Einsatzgebieten für Discriminated Unions bietet die Preview weitere Möglichkeiten zur asynchronen Validierung und Neues für die Prozessverwaltung.
Union Types, die C#-Implementierung von Discriminated Unions mit dem neuen Schlüsselwort union, hat Microsoft in .NET 11.0 Preview 3 [1] eingeführt. Mit der neu erschienenen Preview 6 [2] können Entwicklerinnen und Entwickler Union Types nun an verschiedenen Stellen in .NET-Bibliotheken nutzen:
anyOf zum Einsatz (siehe Abbildung). Community-Bibliotheken für OpenAPI wie Swashbuckle und NSwag können damit aber noch nicht umgehen.
Die in C# 14.0 eingeführten Erweiterungsblöcke [5] mit dem Schlüsselwort extension für bestehende Klassen, die bisher nur Methoden, Properties und Operatoren ergänzen konnten, können nun in C# 15.0 auch Indexer zu bestehenden Klassen hinzufügen.
Das folgende Listing zeigt einen Erweiterungsblock in der Klasse ListExtensions, die zum generischen Typ List<T> einen Indexer hinzufügt, der Zeichenketten als Parameter entgegennimmt. Im Standard gibt es dort nur einen Indexer für Ganzzahlen.
using System;
using System.Collections.Generic;
using System.Text;
namespace NET11_Console.C_;
extension<T>(List<T> list)
{
public T this[string index]
{
get
{
// Prüfe, ob der Index ein gültiger Integer ist
if (!Int32.TryParse(index, out int i)) return default(T);
// Prüfe, ob der Index innerhalb der Grenzen der Liste liegt
if (i > list.Count - 1) return default(T);
// liefere den Wert aus der Liste
return list[i];
}
}
}
}Listing 1: Extension für List<T>, die einen Indexer mit einem Zeichenkettenparameter ergänzt
So verwendet man den neuen Indexer:
List<string> Prio = ["A", "B", "C"];
Console.WriteLine(Prio["1"]); // B
Console.WriteLine(Prio["42"]); // NULL
Console.WriteLine(Prio["unsinn"] == null); // trueMicrosoft hatte bereits in .NET 11.0 Preview 5 [6] asynchrone Validierung in Blazor eingebaut. Nun in Preview 6 lässt sich die asynchrone Validierung auch außerhalb von Blazor in anderen Anwendungsarten nutzen. Dazu hat Microsoft die Klasse System.ComponentModel.DataAnnotations.Validator um die vier Methoden ValidateObjectAsync(), TryValidateObjectAsync(), ValidatePropertyAsync() und ValidateValueAsync() erweitert. Zuvor gab es nur Pendants ohne Async im Namen [7].
Zudem gibt es für asynchrone Validierungsregeln eine neue Basisklasse AsyncValidationAttribute in Ergänzung zur bestehenden Basisklasse ValidationAttribute. Das Listing zeigt einen aussagekräftigen Ausschnitt aus einem Beispiel:
using System.ComponentModel.DataAnnotations;
namespace NET11_Console.FCL;
/// <summary>
/// Datenklasse
/// </summary>
public class Rechnung
{
[Required]
public int ID { get; set; }
[Range(0.01, double.MaxValue, ErrorMessage = "Betrag muss größer als 0 sein.")]
public double Betrag { get; set; }
[Required]
[StringLength(14, MinimumLength = 8)]
[RegularExpression(@"^[A-Z]{2}[A-Z0-9]+$")]
[ValidVatNumber] // asynchrone Validierungsregel!
public string SteuerNummer { get; set; } = "";
}
/// <summary>
/// Asynchrone Validierungsregel
/// </summary>
public sealed class ValidVatNumberAttribute : AsyncValidationAttribute
{
// Synchronous IsValid. This attribute validates asynchronously only.
protected override ValidationResult? IsValid(object? value, ValidationContext context) =>
throw new InvalidOperationException("Validate this attribute with IsValidAsync.");
protected override async Task<ValidationResult?> IsValidAsync(
object? value, ValidationContext context, CancellationToken cancellationToken)
{
var ok = await new TaxBL().ValidateVatID(value.ToString());
if (ok)
{
return ValidationResult.Success;
}
else
{
return new ValidationResult("Unbekannte Steuernummer.");
}
}
}
public class FCL11_AsyncValidation
{
public async Task Run()
{
CUI.Demo(nameof(FCL11_AsyncValidation));
var re = new Rechnung() { ID = 123, SteuerNummer = "DE12345678", Betrag = 0.0d };
var context = new ValidationContext(re);
var results = new List<ValidationResult>();
// Asynchrone Validierung
await Validator.TryValidateObjectAsync(re, context, results, validateAllProperties: true);
if (results.Count > 0)
{
CUI.Error("Gefundene Fehler: " + results.Count);
foreach (var result in results)
{
CUI.LI(result.ErrorMessage, ConsoleColor.Red);
}
}
else
{
CUI.Success("Rechnungsobjekt ist einwandfrei!");
}
}
}Listing 2: Asynchrone Validierung
Das Listing gibt aus:
Gefundene Fehler: 2
Auch in ASP.NET Core Minimal Web-APIs ist nun asynchrone Validierung möglich. Dazu muss man, wie in .NET 10.0 eingeführt, im Startcode builder.Services.AddValidation() aufrufen. Danach können Entwicklerinnen und Entwickler Objekte mit asynchronen Validatoren verwenden, zum Beispiel die oben schon verwendete Klasse Rechnung:
app.MapPost("/CheckInvoice", (Rechnung re) =>
{
new TaxBL().Process(re);
return Results.Ok(re);
});Dieser HTTP-Request
POST {{NET10_WebAPIMinimal_HostAddress}}/CheckInvoice
Content-Type: application/json
{
"ID": 123,
"SteuerNummer": "DE12345678"
}führt dann zur Antwort:
{
"title": "One or more validation errors occurred.",
"status": 400,
"errors": {
"Betrag": [
"Betrag muss größer als 0 sein."
],
"SteuerNummer": [
"Unbekannte Steuernummer."
]
}
}Wenn der Aufruf AddValidation() vergessen wird, findet keine Validierung statt und es gibt für den Aufrufer auch keinen Laufzeitfehler, der auf die fehlende Validierung hinweist.
In den Release Notes [8] werden die klassischen Controller-basierten Web-APIs nicht erwähnt. Ein Schnelltest ergab, dass dort in Preview 6 die Übergabe eines Objekts mit asynchroner Validierung zu einem Laufzeitfehler führt: „System.InvalidOperationException: Validate this attribute with IsValidAsync.“ Ebenso wenig funktionieren bislang Union Types in Operationen in Controller-basierten Web-APIs.
Seit .NET 8.0 können Entwicklerinnen und Entwickler mit ShortCircuit() beziehungsweise MapShortCircuit() bereits bei Web-APIs deklarieren, dass ein Endpunkt zur Leistungsoptimierung ohne Verwendung aller genutzten Middleware-Komponenten (etwa Authentifizierung, CORS, Protokollierung, Komprimierung oder Durchsatzbegrenzung) direkt aufgerufen werden soll. In .NET 11.0 kann man dies nun auch deklarativ mit der neuen Annotation [ShortCircuit] erreichen.
Das geht in Minimal Web-APIs
app.MapGet("/Info",
[ShortCircuit] () => "ASP.NET Core WebAPI Controller in .NET " +
System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription);und ebenso in Controller-basierten Web-APIs:
public class PersonController : ControllerBase
{
[HttpGet]
[Route("/Info")]
[ShortCircuit]
public IActionResult Get()
{
return Content("ASP.NET Core WebAPI Controller in .NET " + System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription, "text/plain");
}
}ASP.NET-Core-basierte Web-APIs unterstützen seit .NET 11.0 Preview 2 [9] die OpenAPI Specification in der Version 3.2. In .NET 10.0 war es Version 3.1. Vor Preview 6 war Version 3.2 nicht im Standard aktiv, sondern musste im Startcode aktiviert werden:
builder.Services.AddOpenApi(options =>
{
options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_2;
});Am 16.6.2026 hat Microsoft bekanntgegeben, dass ab Preview 6 die Version 3.2 der Standard ist [10].
Eine Rückstufung auf Version 3.1 ist möglich:
builder.Services.AddOpenApi(options =>
{
options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_1;
});Bei ASP.NET Core SignalR können Clients nun eine Verbindung abbrechen, auch wenn diese kein Streaming verwendet:
public class WorkHub : Hub
{
public async Task NameDerOperation(CancellationToken cancellationToken)
{
await Task.Delay(TimeSpan.FromMinutes(5), cancellationToken);
}
}
…
using var cts = new CancellationTokenSource();
var ergebnis = connection.InvokeAsync("NameDerOperation", cts.Token);
…
cts.Cancel();{
"title": "One or more validation errors occurred.",
"status": 400,
"errors": {
"Betrag": [
"Betrag muss größer als 0 sein."
],
"SteuerNummer": [
"Unbekannte Steuernummer."
]
}
}Microsoft hat bereits in Preview 4 [11] und Preview 5 [12] Erweiterungen für die Prozessverwaltung gebracht. Auch Preview 6 bietet hier Neuerungen: Entwicklerinnen und Entwickler können Prozesse nun direkt im Zustand „Suspended“ starten. Dafür gibt es in der Klasse ProcessStartInfo die neue Boolean-Eigenschaft StartSuspended und in der Klasse SafeProcessHandle die Methode Resume(), siehe Listing.
public async Task StartSuspended()
{
CUI.Demo(nameof(StartSuspended));
var startInfo = new ProcessStartInfo("notepad.exe") { StartSuspended = true };
using var process = Process.Start(startInfo)!;
CUI.Print(DateTime.Now.ToLongTimeString() + ": Neuer Prozess mit ID #" + process.Id + " ist gestartet!");
CUI.Print(IsProcessSuspended(process) ? "Prozess ist ausgesetzt." : "Prozess läuft!");
await Task.Delay(2000);
process.SafeHandle.Resume();
CUI.Print(IsProcessSuspended(process) ? "Prozess ist ausgesetzt." : "Prozess läuft!");
}Listing 3: Einen Prozess ausgesetzt starten
Die Klasse SafeProcessHandle bietet außerdem die neuen Methoden Open() und TryOpen(), um einen Prozess anhand der ID direkt anzusprechen. In der Klasse Process gibt es die neue Methode TryGetProcessById(), die im Gegensatz zur bestehenden ProcessById() den Wert false liefert, anstatt eine Ausnahme auszulösen, wenn kein Prozess mit der angegebenen ID existiert.
In Blazor können Developer in der eingebauten Komponente <Virtualize> den Nutzerinnen und Nutzern einer Webanwendung nun ermöglichen, leicht zu bestimmten Elementen in der Liste zu scrollen. Dafür gibt es die neue Eigenschaft InitialIndex für die Startposition und die neue Methode ScrollToIndexAsync() für eine Bewegung zur Laufzeit, siehe Listing.
@page "/VirtualizeScrolling"
@inject NavigationManager nav
@inject ITVisions.Blazor.BlazorUtil util
@rendermode InteractiveServer
<Headline BlazorType="@this.RendererInfo.Name">
Scrolling bei <Virtualize>
</Headline>
<input type="number" min="0" max="1000" @bind="Index" />
<button @onclick='GoToIndex'>GoToIndex</button>
<button @onclick='GoToTop'>GoToTop</button>
<hr />
<div class="row">
<div class="col">
<div class="table table-striped sticky-grid">
<Virtualize TItem="IndexedFlight" Items="IndexedFlights" InitialIndex="100" @ref="list" Context="item">
<div>
Flug #@(item.Index + 1):
#@item.Flight.FlightNo:
@item.Flight.Departure → @item.Flight.Destination
</div>
</Virtualize>
</div>
</div>
</div>
@code {
public sealed record IndexedFlight(
int Index,
BO.WWWings.Flight Flight);
private List<BO.WWWings.Flight> FlightSet;
private List<IndexedFlight> IndexedFlights = [];
private Virtualize<IndexedFlight> list = default!;
public int Index { get; set; }
protected override void OnInitialized()
{
DA.WWWings.WwwingsV1EnContext ctx = new();
FlightSet = ctx.Flights.ToList();
IndexedFlights = FlightSet
.Select((flight, index) => new IndexedFlight(index, flight))
.ToList();
}
private async Task GoToTop() => await list.ScrollToIndexAsync(0);
private async Task GoToIndex() => await list.ScrollToIndexAsync(Index);
}Listing 4: InitialIndex und ScrollToIndexAsync() bei <Virtualize>
Entwicklerinnen und Entwickler können in Blazor nun Client-Einstellungen, die bisher per JavaScript erfolgen mussten, im C#-Startcode der Anwendung vornehmen. Dazu gibt es eine neue Methode WithBrowserOptions(), die man nach dem Hinzufügen der gewünschten Render-Modi (zum Beispiel AddInteractiveServerRenderMode()) aufruft. Als Parameter gibt man ein Objekt des Typs BrowserOptions mit. In BrowserOptions gibt es die Unterobjekte Ssr (für statisches serverseitiges Rendering), Server (für Blazor Server) und WebAssembly (für Blazor WebAssembly):
app.MapRazorComponents<App>()
.AddInteractiveServerRenderMode()
.AddInteractiveWebAssemblyRenderMode()
.AddAdditionalAssemblies(typeof(Client._Imports).Assembly)
// Neu in .NET 11.0: Client-Einstellungen können in der Program.cs-Datei konfiguriert werden.
.WithBrowserOptions(options =>
{
options.LogLevel = LogLevel.Warning;
options.Ssr.PreserveDom = true;
options.Server.ReconnectionMaxRetries = 10;
options.Server.ReconnectionRetryInterval = TimeSpan.FromSeconds(1.5);
options.Server.ReconnectionDialogId = "components-reconnect-modal";
options.WebAssembly.ApplicationCulture = "de-de";
options.WebAssembly.EnvironmentName = "Staging";
options.WebAssembly.EnvironmentVariables["Version"] = "1.2";
});
app.Run();Alternativ können Entwicklerinnen und Entwickler diese Einstellungen per Komponente <ConfigureBrowser> in App.razor setzen:
<!DOCTYPE html>
<html lang="en">
…
<body>
<Routes @rendermode="InteractiveServer" />
<ReconnectModal />
<ConfigureBrowser Options="bo">
</ConfigureBrowser>
<script src="@Assets["_framework/blazor.web.js"]"></script>
</body>
</html>
@code
{
BrowserOptions bo = new()
{
LogLevel = LogLevel.Warning,
Ssr =
{
PreserveDom = true
},
Server =
{
ReconnectionMaxRetries = 10,
ReconnectionRetryInterval = TimeSpan.FromSeconds(1.5),
ReconnectionDialogId = "components-reconnect-modal"
},
WebAssembly =
{
ApplicationCulture = "de-DE",
EnvironmentName = "Staging",
EnvironmentVariables =
{
["Version"] = "1.2"
}
}
};
}In Blazor wurde außerdem das in .NET 11.0 Preview 1 [13] eingeführte Steuerelement <EnvironmentBoundary> in <EnvironmentView> umbenannt. Ebenso umbenannt hat Microsoft die Methode GetUriWithHash() in der Klasse NavigationManager: Sie heißt nun GetUriWithFragment().
Der in .NET 11.0 Preview 5 [14] eingeführte neue LINQ-Operator FullJoin() besitzt nun auch eine Implementierung in Entity Framework Core, sodass eine direkte Umsetzung in SQL möglich ist.
Aus diesem LINQ-Befehl mit FullJoin() zwischen Flügen und Piloten
var fluegeUndPiloten = ctx.Flights.IgnoreQueryFilters()
.FullJoin(
ctx.Pilots,
f => f.PilotPersonId,
p => p.PersonId,
(f, p) => new
{
FlightNo = f != null ? f.FlightNo : 0,
Departure = f != null ? f.Departure : "n/a",
Destination = f != null ? f.Destination : "n/a",
FlightDate = f != null ? f.FlightDate : DateTime.MinValue,
PilotId = f != null && f.PilotPersonId != null ? f.PilotPersonId.ToString() : "n/a",
GivenName = p != null ? p.Employee.Person.GivenName : "n/a",
p.Employee.Person.Surname,
}).Where(x => x.Surname == null)
.Take(20)
.ToList();erzeugt Entity Framework Core dann diesen SQL-Befehl:
SELECT TOP(@p) CASE
WHEN [f].[FlightNo] IS NOT NULL THEN [f].[FlightNo]
ELSE 0
END AS [FlightNo], CASE
WHEN [f].[FlightNo] IS NOT NULL THEN [f].[Departure]
ELSE N'n/a'
END AS [Departure], CASE
WHEN [f].[FlightNo] IS NOT NULL THEN [f].[Destination]
ELSE N'n/a'
END AS [Destination], CASE
WHEN [f].[FlightNo] IS NOT NULL THEN [f].[FlightDate]
ELSE '0001-01-01T00:00:00.000'
END AS [FlightDate], CASE
WHEN [f].[FlightNo] IS NOT NULL AND [f].[Pilot_PersonID] IS NOT NULL THEN CONVERT(varchar(11), [f].[Pilot_PersonID])
ELSE 'n/a'
END AS [PilotId], CASE
WHEN [p].[PersonID] IS NOT NULL THEN [p0].[GivenName]
ELSE N'n/a'
END AS [GivenName], [p0].[Surname]
FROM [Operation].[Flight] AS [f]
FULL JOIN [People].[Pilot] AS [p] ON [f].[Pilot_PersonID] = [p].[PersonID]
LEFT JOIN [People].[Employee] AS [e] ON [p].[PersonID] = [e].[PersonID]
LEFT JOIN [People].[Person] AS [p0] ON [e].[PersonID] = [p0].[PersonID]
WHERE [p0].[Surname] IS NULLSeit Entity Framework Core 10.0 konnte man einen Full Join erreichen, indem man LeftJoin() und RightJoin() kombiniert hat. Vor Version 10.0 musste man noch umständlicher GroupJoin() und SelectMany() verwenden.
Einige der Kommandozeilenbefehle des .NET SDK laufen nun nicht mehr auf Basis des Just-in-Time-Compilers, sondern mit Native AOT:
dotnet --versiondotnet --infodotnet --helpdotnet (Befehl) --helpdotnet --cli-schemadotnet sln listdotnet sln migratedotnet sln removeBei dotnet test gibt es nun den Parameter --no-dependencies zum Vermeiden der Übersetzung von Projektreferenzen, analog zu dotnet build --no-dependencies. Analog gibt es bei dotnet test nun auch --use-current-runtime (abgekürzt --ucr).
Zur Auswahl des Test-Runners können Entwicklerinnen und Entwickler nun eine Umgebungsvariable setzen, statt eines Eintrags in der global.json-Datei, zum Beispiel
export DOTNET_TEST_RUNNER=Microsoft.Testing.Platform
dotnet testDer Standard-Test-Runner ist weiterhin der ältere VSTest-Runner. Die Umgebungsvariable hat höhere Priorität [15] als ein Eintrag in der global.json-Datei.
Die mitgelieferte Projektvorlage für xUnit-basierte Tests besitzt nun einen Parameter --xunit-version, um die Version 3 von xUnit zu wählen. Hier ist dann die Microsoft Testing Platform der Standard.
dotnet new xunit --xunit-version v3Alternativ können Entwicklerinnen und Entwickler noch das ältere VSTest erzwingen:
dotnet new xunit --xunit-version v3 --test-runner VSTest
Für NUnit-basierte Tests gibt es nun ebenfalls die Projektvorlagenoption --test-runner.
Bei File-based Apps (C#-Scripting ohne Projektdatei) funktioniert die in Preview 3 eingeführte Direktive [16] #:include nun auch ohne diese Einstellung:
#:property ExperimentalFileBasedProgramEnableIncludeDirective=trueZudem können Entwicklerinnen und Entwickler #:include nicht nur für C#-Quellcodedateien, sondern auch für kompilierte DLLs verwenden:
#:include ./Bibliothek.dllFür das in Preview 5 eingeführte #:ref ist aber noch diese Zeile in File-based Apps notwendig:
#:property ExperimentalFileBasedProgramEnableRefDirective=trueDie sechste Vorschauversion von .NET 11.0 gibt es kostenlos zum Download [17]. .NET 11.0 soll am 10. November 2026 erscheinen und einen Standard-Term Support von zwei Jahren erhalten.
Die iX und der dpunkt.verlag werden in Kooperation mit den bekannten .NET-Experten von www.IT-Visions.de [18] die fertige Version am 17. November in einem ganztägigen Online-Event präsentieren: betterCode() .NET 11.0 [19].
URL dieses Artikels:
https://www.heise.de/-11366944
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Die Fleißner-Schablone und der IRA-Code sind zwei Transpositionschiffren, die von der Kreativität ihrer Erfinder zeugen.
Sehr viele clevere Methoden zum Verschlüsseln von Texten gerieten im Laufe der Jahre zu Unrecht in Vergessenheit. Deshalb zeigen wir Ihnen einige der Schätze aus der Geschichte der Kryptografie, die es wert sind, genauer betrachtet zu werden. Einerseits, um zu verstehen, warum sie sich als unsicher erwiesen, aber auch, um die hübschen Ideen hinter den Verfahren zu würdigen.
Bisher haben wir uns in dieser Artikelserie mit Pigpen, Playfair, Chaocipher [1] [1], Nyctografie, Büchercodes und der Kryha-Maschine [2] [2] beschäftigt sowie im letzten Teil der Reihe mit der Barbier-Nachtschrift, den Codebüchern und abschließend dem ADFGX-Code [3] [3]. Dieses Mal behandeln wir die Fleißner-Schablone, die ab 1881 in vielen Armeen als Verschlüsselungstechnik zum Einsatz kam, und den IRA-Code von 1925. Damit ist ein System gemeint, das die paramilitärische Irisch-Republikanische Armee verwendet hat, um sicher zu kommunizieren, und das erst Anfang der 2000er vom Kryptologen James Gillogly geknackt wurde.
Beide Verfahren eint, dass es sich bei ihnen um Transpositionschiffren handelt. Das bedeutet, die Buchstaben des Klartextes bleiben erhalten, sie tauschen jedoch ihre Plätze – als würde man ein kompliziertes unleserliches Anagramm des gesamten Textes anfertigen. Solche Verfahren sind zwar schon lange bekannt, kamen jedoch in der frühen Neuzeit selten vor. Der Gedanke liegt nicht fern, dass man lieber ein Verfahren nutzt, das die originalen Buchstaben des Klartextes stärker verschleiert und sie zum Beispiel durch völlig andere Symbole ersetzt (Substitution). Solche Verfahren hielt man lange für sicherer, als den Klartext durcheinanderzubringen. Schließlich sind bei einer Transposition die Buchstaben der Nachricht ja noch da, auch wenn in anderer Reihenfolge. Dass der IRA-Code und die Fleißner-Schablone dennoch breit eingesetzt wurden, macht die Chiffren besonders und ist Grund genug, sie unter die Lupe zu nehmen.
URL dieses Artikels:
https://www.heise.de/-11346251
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise online / dmk)
Das Have-I-Been-Pwned-Projekt hat 821.100 Kontodaten des Messgeräteherstellers Fluke zur Datenhalde hinzugefügt.
Der Messgeräte- und Testequipment-Hersteller Fluke gehört zu den Opfern des jüngsten Beutezugs der Cybergang ShinyHunters. Die Daten haben die Kriminellen Anfang Juli dieses Jahres angeblich aus dem Salesforce-Zugang von Fluke entwendet und sollen insgesamt 21 Millionen Datensätze umfassen, einschließlich einiger sensibler persönlicher Informationen. Das Have-I-Been-Pwned-Projekt (HIBP) hat die Datenbank in die Finger bekommen und die sensiblen Datensätze herausdestilliert sowie zur Datenhalde hinzugefügt.
Der Beitrag bei HIBP [1] führt aus, dass es sich am Ende um 821.100 Kundendatensätze handelt. Insgesamt haben die Täter mehr als 100 GByte an Daten veröffentlicht, die angeblich von Fluke stammen. Laut Troy Hunt, dem Betreiber von Have I Been Pwned, besteht der Datensatz größtenteils aus Kontaktinformationen des Unternehmens. Dazu gehören aber auch mehr als 800.000 eindeutige E-Mail-Adressen, Namen, Telefonnummern sowie Anschriften. Zudem handele es sich um eine große Sammlung an Supportfällen – was zu einem Datendiebstahl bei Salesforce passt.
Wer mit dem Support von Fluke in Kontakt stand, kann auf der Hauptseite von Have I Been Pwned prüfen [2], ob die E-Mail-Adresse und die weiteren persönlichen Informationen dadurch nun in unbefugte Hände gefallen sind. Diese Informationen können Cyberkriminelle etwa nutzen, um gezielte und glaubwürdigere Phishing-Kampagnen aufzusetzen, die sich gegen Fluke-Kunden richten. Wenn die eigene E-Mail-Adresse also bei Have I Been Pwned auftaucht, sollte man daher erhöhte Vorsicht bei Nachrichten walten lassen, die Fluke betreffen. Insbesondere Passwort-Anfragen oder Mails, die zeitlichen Druck aufbauen, sollten nicht beantwortet werden. Gegebenenfalls sind dann Rückfragen direkt bei Fluke über die bekannten Kanäle sinnvoll.
Es handelt sich nicht um das erste Datenleck bei Fluke. Mitte vergangenen November hat etwa die kriminelle Cyberbande cl0p behauptet, Daten bei Fluke [3] abgezogen zu haben. Das geschah mutmaßlich über Sicherheitslücken in Oracles E-Business-Suite (EBS).
URL dieses Artikels:
https://www.heise.de/-11367041
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Apple-Laden in Shanghai: Genug Geld in der Kasse auch für größere Aufkäufe.
(Bild: gob_cu / Shutterstock)
Spezialisierte Prozessoren für Training und Inferenz müssen nicht von Nvidia kommen. Davon ist man offenbar bei Apple überzeugt und streckt die Fühler aus.
Apple soll derzeit aktiv versuchen, interessante KI-Chip-Unternehmen aufzukaufen, um sich von Lieferanten wie Nvidia unabhängiger zu machen. Laut einem Bericht des IT-Fachdienstes The Information geht es spezifisch um Technik für Rechenzentren, also Training und Inferenz. Nachdem Apple für seine Cloud-KI zunächst eigene Private-Cloud-Compute-Server mit Apple-Silicon-Technik [1] (wohl M2 Ultra [2]) verwendet hatte, nutzt Apple mit Siri AI [3] künftig verstärkt Nvidia-Hardware, die bei Google Cloud gehostet wird. Als Basis dienen dabei eigens angepasste Gemini-Modelle. Offenbar kommen außerdem Googles hauseigene TPUs [4] zum Einsatz.
Nach The Information gab es in den vergangenen Monaten unter anderem Gespräche mit Banken [5], die als Broker für Halbleiter-Start-ups tätig sind. Weiterhin gab es offenbar auch schon direkte Gespräche mit solchen Firmen. Apple scheint dabei bereit, höhere Beträge in die Hand zu nehmen – möglicherweise im Milliardenbereich. Die Kriegskasse des iPhone-Konzerns gilt als gut gefüllt.
Dass Apple unter dem ab September antretenden neuen Chef John Ternus [6] bereit ist, größere Akquisitionen zu tätigen, lässt sich schon daran ablesen, dass vor Kurzem für 2 Milliarden US-Dollar das israelische KI-Startup Q.ai [7] übernommen worden war. Die Firma hat ein Prinzip entwickelt, mit dem man „sprachlos“ mit KI-Assistenten kommunizieren kann, indem Mikroausdrücke im Gesicht ausgelesen werden können. Die Kaufsumme ist die zweitgrößte, die Apple jemals für eine Übernahme aufgebracht hat, nur der Kopfhörerhersteller Beats [8] war dem Konzern mit 3 Milliarden Dollar mehr wert.
In welche Richtung Apple tendiert, ist noch unklar. Der iPhone-Hersteller gilt allerdings als sehr erfolgreich, was die Integration von Aufkäufen betrifft. So stellte die Übernahme der Chipfirma PA Semi [9] im Jahr 2008 die Basis für die Apple-Silicon-Chips dar [10], die Apples Hardware-Produkte revolutioniert haben. Die Kaufsumme war mit 278 Millionen Dollar klein.
Apple soll intern versucht haben, Gemini-Modelle auch auf eigenen Servern laufen zu lassen. Das sei aber gescheitert. Ein Vorteil für Apple beim Kauf von KI-Chip-Firmen könnte sein, dass der Konzern Spezialtechnik kauft – es gibt durchaus innovative Ansätze, die über das hinaus gehen, was Nvidia mit Weiterentwicklungen klassischer GPUs leistet. Allerdings ist die Technik nicht marktreif. Eine Integration bei Apple könnte zudem Jahre dauern. Intern soll der Konzern allerdings bereits damit planen, Googles Gemini-Modelle eines Tages doch wieder durch Apple-Technik zu ersetzen.
URL dieses Artikels:
https://www.heise.de/-11366368
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: LCV/Shutterstock.com)
IBM Bob 2.0 soll auch Jahrzehnte alten Code verstehen und modernisieren können – mit KI-Agenten und Premium-Paketen für Z, i und Java.
Mit Bob 2.0 erweitert IBM die KI-gestützte Software-Entwicklung, die den gesamten Software-Lebenszyklus im Enterprise-Bereich abdecken soll. Bob unterstützt Entwickler bei Planung, Code-Generierung, Validierung, Refactoring und Modernisierung.
Ursprünglich im Oktober 2025, als Project Bob eingeführt wurde [1], handelte es sich um den agentenbasierten Nachfolger von Watsonx Code Assistant. Das ist ein KI-gestütztes Entwicklungs-Tool, das tief in die jeweilige Entwicklungsumgebung (IDE) integriert werden kann und Programmieraufgaben nicht nur vorschlägt, sondern proaktiv ausführt. Hierbei kommen eigenständige Premium-Pakete mit getesteten Workflows für ganz spezifische Einsatzfelder ins Spiel: das Bob Premium Package for Java Modernization [2], das Premium Package für IBM i [3] und das Premium Package für IBM Z [4].
Aktuell sind nur Workflows verfügbar, die mit Bob und diesen drei Paketen ausgeliefert werden; mehr Möglichkeiten für die Programmierer soll es erst geben, sobald die neue API-Oberfläche sich bei den bisherigen Anwendern eingespielt hat. Für klassische AIX- und Linux-basierte Systeme auf Power-Servern agiert Bob als intelligenter Partner in der Entwicklungsumgebung (IDE, oft Visual Studio Code), der folgende Stärken ausspielen soll:
Zu den angekündigten Neuerungen der agentenbasierten Software-Entwicklungsplattform [5] gehören Multi-Agenten-Funktionen, integrierte KI-Analysen zu Kosten und Nutzung sowie vorgefertigte, spezialisierte Workflows zur Modernisierung von Legacy-Software, zum Beispiel COBOL- oder RPG-Programmen.
Versprochen wird ein Tool, das die Absichten, die spezifische Codebasis und die eigenen Standards desjenigen Unternehmens „versteht“, in dem es zum Einsatz kommen soll. Dazu kann man in den „Architekten-Modus“ wechseln, wenn es darum geht, komplexe Software-Systeme zu entwerfen, oder aber auch im „Code-Modus“ mit dem KI-System arbeiten, um schneller beim Codieren voranzukommen oder effizient Entwicklungsschritte zu iterieren.
Bob kann laut Hersteller die Codebasis „lesen“ und „verstehen“, Frameworks modernisieren, Refactorings in großem Maßstab durchführen und Software unter Berücksichtigung des gesamten Kontexts auf neue Plattformen migrieren. Mit eingebautem Fachwissen zu Standards wie FedRAMP, HIPAA oder PCI kann die Bereitstellung von sicherem, produktionsreifem Code schneller erfolgen, so das Versprechen.
Die neue Version bringt aber auch erhebliche Änderungen am bisherigen Produkt mit sich, sowohl hinsichtlich der architektonischen Grundlagen, als auch der Funktionen, die den Anwendern zur Verfügung stehen. Bob 2.0 basiert nunmehr auf einer dreistufigen Architektur: den Agenten, dem sogenannten „Harness“ und den Clients.
Ein Agent bietet Funktionen zur Schlussfolgerung und Codegenerierung, während der „Harness“ zusätzlich Aufgaben wie Authentifizierung, Protokollierung und Telemetrie übernimmt. In der KI-Welt liefert ein Harness die Software-Infrastruktur [6], die ein Sprachmodell (wie etwa ein LLM) umgibt und es diesem ermöglicht, eigenständig Aufgaben auszuführen, anstatt nur Fragen zu beantworten. Bei einem Harness wird auch gern die Analogie zum vom Reiten bekannten Zaumzeug bemüht. Er soll dem KI-Modell Leitplanken, Tools und Kontrollmechanismen wie menschliche Freigaben zur Verfügung stellen, damit die KI sicher und fokussiert arbeiten kann.
Diese einheitliche Basis ist eine große Veränderung gegenüber Bob 1.0, bei dem dafür jeweils unterschiedliche Technologien verwendet wurden. Deshalb konnte IBM die erste Version des Produktes zwar schneller auf den Markt bringen, doch wäre der Aufwand für die Weiterentwicklung viel größer gewesen, da jede Änderung mehrmals umgesetzt werden musste.
Nun gibt es auch vorgefertigte Workflows, die Teams an ihre eigenen Umgebungen anpassen und erweitern können, um sicherzustellen, dass die Ergebnisse konsistent und überprüfbar sind – und zwar unabhängig davon, wer sie ausführt. Nutzer können nun auf „Bobalytics“ zugreifen, eine neue Funktion, mit der sie den Verbrauch überwachen, Ressourcen zuweisen und den Überblick behalten können, um die KI entsprechend ihren internen Vorgaben zu skalieren. Außerdem ist es nun für Modelle möglich, mehrere Tools in einem Durchgang anzufordern und gemeinsam auszuführen.
Zudem verwalten Subagenten den Kontext in großem Maßstab. Das ist wichtig, denn jeder explorative Schritt einer KI – sei es das Lesen von Dateien, Suchvorgänge oder Funktionsverfolgungen – kann das Kontextfenster überladen und die Kosten in die Höhe treiben. Jetzt wickeln Bob-Subagenten komplexe Aufgaben in einem isolierten Kontext ab, um schnelle Antworten zu liefern und gleichzeitig die Kosten zu kontrollieren.
Ebenfalls neu sind drei Premium-Pakete für KI-native Workflows, die strukturiert, wiederholbar, auditierbar und speziell für Umgebungen entwickelt wurden, für die andere Werkzeuge nicht ausgelegt sind.
Das Tool wird über ein eigenes Preismodell [7] abgerechnet; statt einer Token-Abrechnungen wird ein Credit-basiertes System namens Bobcoins (Preisübersicht) [8] genutzt. Ein Bobcoin entspricht 0,50 US-Dollar (bzw. rund 0,45 Euro) und wird gemäß der jeweiligen Aufgabenkomplexität abgerechnet. Der Einstiegspreis für Bob Pro liegt bei 20 US-Dollar (40 Bobcoins) pro Monat.
URL dieses Artikels:
https://www.heise.de/-11367017
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: software-architektur.tv)
In der Episode diskutiert Eberhard Wolff mit Dr. Felix Sühlmann-Faul über digitale Souveränität und die Bedeutung des PRIVA SCORE für Architekturentscheidungen.
Digitale Souveränität und Datenschutz gelten vielen Entwicklern als lästige Pflicht, als Hemmschuh für schnelle Umsetzung. Der Techniksoziologe Dr. Felix Sühlmann-Faul sieht das anders: Für ihn sind beide Themen eine Voraussetzung für demokratische Handlungsfähigkeit – und ganz praktisch für die Software-Architektur. In dieser Episode spricht Eberhard Wolff mit Sühlmann-Faul über die Auswirkungen dieses Themenkomplexes und über den von ihm entwickelten PRIVA SCORE.
Felix Sühlmann-Fauls [1] Verständnis von digitaler Souveränität ist stark praxis- und organisationsorientiert. In einem Blogbeitrag beschreibt er sie als die Kontrolle über eigene Daten und digitale Prozesse. Datensouveränität überschneidet sich für ihn eng mit dem Konzept der informationellen Selbstbestimmung: Die Einzelperson müsse entscheiden können, wem sie Daten übergebe, was die empfangende Institution damit mache und zu welchem Zweck. Open-Source-Software bezeichnet er dabei nicht nur als Mittel zum Zweck, sondern als effektivsten Weg zu mehr Souveränität – und skizziert einen phasenweisen Migrationsansatz, der mit einer Bestandsaufnahme beginnt und über Pilotprojekte bis zur Umstellung geschäftskritischer Systeme reicht.
Kern des Gesprächs ist der PRIVA SCORE, den Sühlmann-Faul unter anderem im Rahmen seiner Dissertation entwickelt hat. Das Projekt beschreibt sich selbst als „Datenschutz-Ampel für Digitales“ und als Entscheidungshilfe für die Auswahl datenschutzfreundlicher Apps und digitaler Dienste. Für die Software-Architektur wird das Ampelsystem interessant, wenn es um die Auswahl von Werkzeugen geht: Externe Dienste wie Cloud-Speicher, Messaging, Videokonferenzen oder CRM-Systeme sind heute typische Architekturbausteine.
Eine Ampelbewertung kann Dienste mit schwacher Datenschutzbilanz faktisch disqualifizieren und Alternativen mit besserer Einstufung in den Vordergrund rücken – und damit Sourcing-Strategien beeinflussen, etwa zugunsten EU-basierter Cloud-Angebote gegenüber US-Hyperscalern oder zugunsten DSGVO-konformer Messenger. In der Governance von Softwareprojekten ließe sich ein solches Rating zudem als verbindliches Kriterium einsetzen, etwa als Mindestscore im Freigabeprozess für neue SaaS-Dienste.
Wer sich über das Livestream-Gespräch hinaus für das Thema interessiert: Sühlmann-Faul spricht bei den IT-Tagen 2026, die vom 7. bis 10. Dezember 2026 in Frankfurt stattfinden (Mit dem Code ITT26-SIS-352 erhalten Interessierte 100 Euro Rabatt auf ein Ticket).
Die Ausstrahlung findet am Freitag, 17. Juli 2026, live ab 13:00 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite [3] einbringen.
software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger und bekannter Softwarearchitekt [4], der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer [5] (Socreatory) und Ralf D. Müller [6] (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren berichtet heise Developer über die Episoden.
URL dieses Artikels:
https://www.heise.de/-11364666
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: yu_photo / Shutterstock)
Das aktuelle Perl geht einen weiteren Schritt in Richtung moderner Objektorientierung. Außerdem schließt Perl 5.44 drei Sicherheitslücken.
Das aktuelle Perl 5.44 erlaubt es, innerhalb von Signaturen benannte Parameter mit zugehörigen Default-Werten zu deklarieren:
sub make_colour ( :$red = 0, :$green = 0, :$blue = 0 ) { ... }
make_colour( red => 1.0, blue => 0.5 );
Wie in Raku [1] (ehemals Perl 6) werden sie mit dem Präfix : vor der Sigil gekennzeichnet. Dieser Doppelpunkt ist nicht Teil des Variablennamens, und beim Aufruf muss man die Sigil weglassen.
Benannte Parameter müssen keinen Default-Wert erhalten und sind immer optional. Das ermöglicht die Kombination mit positionalen Parametern. In diesem Fall müssen beim Methodenaufruf immer zuerst die Positionsargumente stehen. Benannte Parameter werden bis mindestens Perl 5.46 experimentell bleiben und erfordern deshalb diesen Zusatz:
use v5.44;
use experimental 'signature_named_parameters';
Neben einer langen Liste an behobenen Fehlern und einigen Performanceverbesserungen wurden auch drei Sicherheitslücken geschlossen, die einen Pufferüberlauf auslösen konnten.
Die Lücke CVE-2026-8376 [2] betrifft reguläre Ausdrücke, die aus alternativen Unicode-Zeichenketten bestehen. Mit CVE-2026-13221 [3] war das Verhalten der Befehle pack und unpack betroffen. CVE-2026-57432 [4] schlug nur bei äußerst großen regulären Ausdrücken zu, die aus mehr als 65.000 alternativen Teilausdrücken bestehen.
Bemerkenswert ist das endgültige Abschalten einer Funktionsweise, die bereits seit Perl 5.12 [5] als veraltet gekennzeichnet ist. Nun ist es endlich nicht mehr gestattet, mittels goto in Schleifen, Subroutinen und ähnliche funktionstragende Blöcke hineinzuspringen.
Eine Übersicht mit allen behobenen Fehlern, Dokumentationsänderungen, Fehlermeldungen und weiteren Interna ist in der Dokumentation zum aktuellen Release [6] einsehbar.
URL dieses Artikels:
https://www.heise.de/-11366654
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Wer ein kulturstiftendes Epos verfilmt, muss mit Finten tricksen und Kompromisse eingehen. Das sorgt für Gesprächsstoff, wie unsere Filmanalyse zeigt.
Christopher Nolan ist einer der wenigen lebenden Regisseure, die sich den Regeln der Filmbranche widersetzen können und trotzdem, oder gerade deswegen, immer wieder Massen ins Kino locken. Wo andere mit computergenerierter Grafik (CGI) und digitalen Filmkameras Kosten sparen, segelt er auf echten Schiffen aus Holz und nimmt sie mit dem größten und teuersten analogen Kinoformat auf, das es gibt. Wenn ihm die Technik der Kameras nicht genügt, lässt er eben neue bauen.
Sein dreizehnter Film „Die Odyssee“, der am 16. Juli in die Kinos kommt, ist sein bisher aufwendigstes Projekt. Dabei musste Nolan, ganz wie seine Hauptfigur Odysseus, zahlreiche Strudel und Klippen umschiffen. Allein die Besetzungsliste rief Kulturkonservative und Identitäre auf die Barrikaden, bevor sie auch nur eine Minute des Films gesehen hatten. Entgegen guter alter griechischer Tradition hatte es der Regisseur nämlich gewagt, die Frauenrollen nicht mit Männern und die der Göttin Athene mit einer Sterblichen zu besetzen. Nolan hilft diese Aufmerksamkeit jedoch ungemein: Wer im aktuellen Kulturkampf mitreden will, kommt nicht umhin, sich den Film anzuschauen (und diesen Artikel zu lesen).
Wir haben den Film bereits vorab gesehen und können dringende Fragen beantworten: Wie interpretiert Nolan die Odyssee? Welche Aspekte verstärkt er, welche drängt er in den Hintergrund? Welches Vorwissen setzt er voraus? Was bringen die IMAX-Kameras tatsächlich – und in welchen Formaten lässt sich der Film sehen? Wo steht das Werk im Kanon des Regisseurs? Trägt das Ensemble? Und wie modern ist Nolans Lesart? Unsere umfangreiche Analyse lässt sich deshalb zweimal lesen: vor der Vorstellung als spoilerfreier Text über Vorgeschichte, Technik, Inszenierung und Ästhetik, danach als Untersuchung der Figuren, der Abweichungen von Homer und der abschließenden Wendung – auf die Gefahrenstellen weisen wir rechtzeitig hin.
URL dieses Artikels:
https://www.heise.de/-11353151
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Manuel Masiero / KI / iX)
Googles offizielle IDE für die Entwicklung von Android-Apps setzt verstärkt auf KI-Integration, unter anderem mit mehreren parallel laufenden Agentenchats.
Android Studio Quail 2 steht als stabiles Release bereit. Gegenüber dem Vorgänger Quail 1 zeichnet sich die Android-IDE durch drei wesentliche Neuerungen aus: eine Multitasking-Architektur für parallele Agentenchats, native LeakCanary-Integration im Profiler sowie eine jetzt vollständig mit Agent Mode integrierte agentengestützte Crash-Analyse in App Quality Insights.
Die parallelen Agentenchats von Android Studio Quail 2 [1] überwinden den bisherigen Engpass, dass sich Agenten-Tasks nur sequenziell abarbeiten ließen. Damit erlaubt es die neue Version Entwicklerinnen und Entwicklern beispielsweise, in einem Tab ein UI-Refactoring zu starten, in einem zweiten eine ProGuard-Regel neu zu definieren und in einem dritten die Dokumentation zu generieren. Jedem Tab lässt sich ein individuelles Modell zuweisen. Worktree-Support gibt es mit den parallelen Agentenchats allerdings nicht.
(Bild: Google)
LeakCanary und App Quality Insights (AQI) greifen Entwicklern unter die Arme, um Fehler aufzuspüren und zu beheben, ebenfalls KI-gestützt. Das Open-Source-Tool LeakCanary [2] steckt nativ im Profiler und spürt Speicherlecks laut Google bis zu fünfmal schneller auf als bisher, indem es die Leak-Nachverfolgung vom Testgerät auf den Entwicklungsrechner verlagert. Der Button „Go to Declaration“ springt zur entsprechenden Codestelle, während „Fix with Agent“ sie nach User-Zustimmung mittels KI-generiertem Codepflaster schließt.
AQI setzt auf den gleichen Modus Operandi. Klicken Developer im AQI-Panel auf ein Crash-Ereignis, erhalten sie eine Zusammenfassung des Problems, in einem eigenen Chat und auf Wunsch noch eine umfassende Erklärung dazu. Beides basiert auf dem jeweils ausgewählten Modell. „Fix with AI“ soll dann ebenfalls für schnelle Abhilfe sorgen.
Google bietet Android Studio Quail 2, dessen tierischer Codename Quail (Wachtel) für die 2026-Generation der IDE steht, für Windows, macOS, Linux und ChromeOS zum Download [3] an. Android Studio Quail 3 [4] ist bereits als Release Candidate verfügbar.
URL dieses Artikels:
https://www.heise.de/-11365583
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: evkaz / Shutterstock.com)
Gut 290 GitHub-Repositorys, die angeblich von Securityanbietern, Toolherstellern und weiteren Firmen sind, verteilen Schadcode zum Abgreifen von Daten.
Angreifer haben hunderte GitHub-Repositorys angelegt, die vermeintlich von bekannten Firmen stammen. Ein Link auf die „official page“ im Readme führt zu einer Seite der Angreifer, die einen Infostealer verteilt.
Die Schadsoftware greift Credentials und vertrauliche Daten von mindestens 19 Webbrowsern und zahlreichen Krypto-Wallets ab. Auch Messenger und Social-Media-Anwendungen sowie Steam-Accounts sind im Fokus der Angreifer.
Der Angriff nutzt keine Schwachstellen aus, sondern setzt auf Brandjacking und Social Engineering. Die Repositorys geben vor, von bekannten Firmen unter anderem aus den Bereichen Security, Entwicklungswerkzeuge, Krypto-Tools, Fintech und Gaming-Software zu stammen. Der Schadcode läuft ausschließlich auf Windows-Rechnern.
Sicherheitsforscher von Arctic Wolf haben den Angriff entdeckt. Der Auslöser war, dass ein Fake-Repository vorgab, von Arctic Wolf zu stammen. Bei den weiteren Untersuchungen haben die Forscher festgestellt, dass die Angreifer insgesamt 292 Repositorys erstellt hatten, von denen GitHub inzwischen die meisten entfernt hat.
Einige Repositorys sind jedoch vermutlich noch aktiv und es ist möglich, dass die Angreifer weitere Fake-Repositorys erstellen.
Der Angriffsvektor ist jedes Mal derselbe. Für das Fake-Repository zu Arctic Wolf enthielt die Markdown-Datei mit dem Readme (README.md) einen Link zur vermeintlichen „official page“ des Anbieters und der Software. Dieser Link führte zu einer Domain der Angreifer, die sich wiederum als Arctic-Wolf-Seite ausgab und ein Paket zum kostenlosen Download angeboten hat.
Der Download-Button trug die Schrift „Download Secure Content“ und zahlreiche Badges wiesen darauf hin, dass die Verbindung sicher und die Software auf Viren geprüft sei.
(Bild: Arctic Wolf)
Der Klick auf den Button löste den Download einer ZIP-Datei aus. Offenbar erzeugte der Server, der das Paket verteilte, im Minutentakt frische Pakete mit jeweils geänderten ZIP-Dateinamen und neuen Namen der Executables.
Neben dem Schadcode enthielt das Archiv viel Beifang, der nach Vermutung der Sicherheitsforscher lediglich dazu dient, die ZIP-Datei auf die erwartete Größe zu bringen. Der eigentliche Schadcode steckte in zwei Dateien: gup.exe zum Laden der Datei libcurl.dll, die wiederum den Infostealer dekodiert und im Speicher ausführt.
Der Infostealer ist laut der Analyse von Arctic Wolf eine Variante des im März von Trend Micro entdeckten BoryptGrab [2], der darauf ausgelegt ist, zahlreiche Daten und Credentials abzugreifen. Allerdings ist der für den Angriff genutzte Schadcode auf ein Minimum reduziert und lädt im Gegensatz zu BoryptGrab keine weiteren Payloads nach.
Die einzelnen Module des Infostealers zielen dabei auf unterschiedliche Browser, Messenger, Krypto-Wallets und mehr.
Die gesammelten Daten schickt die Software schließlich als ZIP-Archiv an einen russischen Server.
(Bild: Arctic Wolf)
Der Infostealer läuft nach dem Start nur einmal durch und versucht nicht, sich als automatisch gestarteter Prozess festzusetzen. Er macht auch keine Anstalten, sich auf andere Systeme zu verteilen.
Auch verzichtet der Schadcode auf Aufräumarbeiten: Alle gesammelten Daten und auch Logdateien der Software bleiben in einem temporären Verzeichnis, das die Software nach getaner Arbeit nicht löscht.
Weitere Details zu den einzelnen Modulen im Infostealer und den spezifischen IP-Adressen der Angreifer finden sich im Arctic-Wolf-Blog [3].
URL dieses Artikels:
https://www.heise.de/-11365096
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Motorola bringt mit dem Edge 70 Max ein neues Oberklasse-Smartphone mit Riesenakku und sehr hellem Display für 799 Euro auf den Markt.
Motorola erweitert seine Edge-Serie um das Edge 70 Max. Das Smartphone soll ab dem 15. Juli in ausgewählten europäischen Märkten erhältlich sein und kostet in der Variante mit 8 GByte RAM und 256 GByte UFS-4.1-Speicher 799 Euro.
Im Mittelpunkt steht der mit 7100 mAh ungewöhnlich große Akku. Motorola setzt dabei auf eine Silizium-Kohlenstoff-Chemie, die eine höhere Energiedichte als klassische Lithium-Ionen-Akkus ermöglichen soll. Geladen wird per USB-C mit bis zu 90 Watt, kabellos sind nach Qi2-Standard bis zu 25 Watt möglich. Zudem unterstützt das Gerät kabelgebundenes Reverse Charging mit 5 Watt.
Auch das Display fällt auf. Das 6,82 Zoll große AMOLED-Panel löst mit 1440 × 3168 Pixeln auf, unterstützt Bildwiederholraten bis 144 Hz und erreicht laut Motorola eine Spitzenhelligkeit von bis zu 7000 Nits. Das Display ist HDR10+-fähig und Pantone-validiert.
Für die Rechenleistung sorgt Qualcomms Snapdragon 8 Gen 5. Motorola kombiniert den SoC mit 8 GByte LPDDR5X-Arbeitsspeicher und integriert ein 5500 Quadratmillimeter großes Vapor-Chamber-Kühlsystem mit Flüssigmetall, das die Abwärme unter Last besser abführen soll. Nach Herstellerangaben steigt die CPU-Leistung gegenüber der vorherigen Snapdragon-Generation um 36 Prozent, die GPU-Leistung um 11 Prozent und die NPU-Leistung um 46 Prozent.
Bei der Kamera setzt Motorola auf einen 50-Megapixel-Sensor vom Typ Sony LYTIA 710 mit optischer Bildstabilisierung. Hinzu kommen eine 8-Megapixel-Ultraweitwinkelkamera mit Makrofunktion sowie eine 32-Megapixel-Frontkamera. Ein Tele gibt es nicht.
Das 221 Gramm schwere Smartphone besitzt einen Rahmen aus Aluminium sowie Gorilla Glass 7i auf Vorder- und Rückseite. Es erfüllt laut Hersteller die Schutzklassen IP68 und IP69 sowie den Militärstandard MIL-STD-810H. Als Betriebssystem kommt Android 16 zum Einsatz. Das Smartphone soll laut Hersteller drei große Android-Updates und bis zu fünf Jahre lang Sicherheitsupdates erhalten.
Ab dem 15. Juli soll das Motorola Edge 70 Max für 799 Euro erhältlich sein. Zum Marktstart legt Motorola nach eigenen Angaben bei Käufen über den eigenen Online-Shop unter anderem die Moto Buds Loop und ein 125-Watt-Netzteil bei.
URL dieses Artikels:
https://www.heise.de/-11364958
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Interessierte Menschen begutachten die KABINE auf einer gemeinsamen Veranstaltung der Uniklinik RWTH Aachen und dem Technischen Hilfswerk und weiteren Beteiligten.
(Bild: Uniklinik RWTH Aachen)
Eine Toilettenkabine soll die medizinische Versorgung im Ernstfall verbessern. Wie das funktioniert, erklärt Dr. Andreas Follmann von der Uniklinik RWTH Aachen.
Wenn nach einer Katastrophe Arztpraxen und Krankenhäuser nicht mehr erreichbar sind, könnte eine handelsübliche Toilettenkabine als telemedizinische Behandlungsstation aushelfen. Mit diesem ungewöhnlichen Konzept wollte ein Forschungskonsortium unter Beteiligung der Uniklinik RWTH Aachen die medizinische Versorgung im Katastrophenfall verbessern. Die mobile Einheit soll laut Uniklinik dort zum Einsatz kommen, wo „Arztpraxen, Krankenhäuser oder Verkehrswege vorübergehend nicht erreichbar oder überlastet sind" oder die Infrastruktur ausgefallen ist. Nach ersten Erprobungen, unter anderem auf dem Musikfestival Parookaville, wurde der Prototyp weiterentwickelt. Im Juli wurde das Forschungsprojekt mit einer öffentlichen Abschlussdemonstration auf dem Gelände des Technischen Hilfswerks in Aachen offiziell beendet.
(Bild: RWTH Uniklinik Aachen)
Im Gespräch erklärt Dr. Andreas Follmann von der Uniklinik RWTH Aachen, Mitglied des Projektkonsortiums, welche Erkenntnisse die Praxistests gebracht haben und warum die Kabine inzwischen rot statt grau ist.
Die Kabine sieht nicht mehr aus wie ein Dixi-Klo, sondern ist jetzt rot. Warum?
Andreas Follmann: Rot ist tatsächlich eine Signalfarbe, wenn es darum geht, gut aufzufallen. Gerade im Katastrophenfall ist das wichtig, weil dort häufig mehrere dieser Toiletten- oder Duschkabinen stehen. Das Ziel ist, dass man diejenige Kabine, die man für medizinische Zwecke aufsuchen muss, direkt findet. Außerdem gibt es Studien, die belegen, dass bei Rot und Orange am wenigsten Vandalismus zu befürchten ist. Das ist ein zusätzlicher psychologischer Effekt.
Hat sich außer der Farbe technisch etwas verändert?
Technisch hat sich kaum was geändert. Wir haben die alte Kabine in mehreren Studien getestet – unter anderem in einer Simulationsstudie, die man sich wie ein Krimi-Dinner vorstellen kann – und beim Musikfestival Parookaville. Das war für uns natürlich extrem spannend, weil es sich um echte Patienten mit echten Problemen handelte. Dort haben wir gemerkt, dass die von uns zuvor ausgewählte Technik dafür sehr gut geeignet war.
Am Anfang dachten wir, das sogenannte Dermatoskop würden wir am wenigsten brauchen. Tatsächlich gab es bei Parookaville aber extrem viele Hautveränderungen. Es war heiß und schwül, entsprechend gab es viele Insektenstiche und Allergien. Viele hatten Probleme mit Grasmilben, bei denen man sich die Hautveränderungen sehr genau ansehen musste, um dann gezielt zum Beispiel eine Salbe zu verschreiben.
Zur Ausstattung gehören neben einem EKG und einer Untersuchungskamera, die mit verschiedenen Aufsätzen etwa als Otoskop fürs Ohr oder als Dermatoskop für die Haut genutzt werden kann, auch weiterhin laientaugliche, über Bluetooth angebundene Medizingeräte.
Gab es trotzdem Anpassungen?
Ja, an der Usability hat sich einiges verändert. Das EKG war vorher eine kleine, scheckkartengroße Box, auf die man zwei Finger legen musste. Mittlerweile gibt es Haltegriffe, an denen man sich einfach festhalten kann.
Außerdem ist der Toilettensitz jetzt Gott sei Dank nicht mehr drin. Wir hatten vorher den Tank genutzt, um Technik reinzubauen. Mittlerweile ist alles etwas kleiner geworden, und es gibt einen richtigen Stuhl darin, den man auch herausstellen kann – so haben auch Menschen mit einem kleinen Rollstuhl die Möglichkeit, sich dort reinzusetzen.
Wir haben zudem Erwachsene mit Kindern hineingesetzt, um zu prüfen, ob die Kameraposition auch für Kinder passt und ob die Begleitperson zumindest teilweise mit hineinkommt. Deshalb haben wir auch einen Stuhl genommen, der höhenverstellbar ist.
Welche Grenzen sind bei der Evaluierung deutlich geworden?
Generell ist der Betrieb noch nicht ganz klar. Wer bevorratet das System? Ist das die Hilfsorganisation oder ein Land oder eine Kommune? Zwischendurch muss vielleicht auch mal gereinigt oder desinfiziert werden. Deshalb ist unsere klare Empfehlung, die Kabinen an sogenannten Katastrophenschutz-Leuchttürmen aufzustellen. Das sind vorab festgelegte Standorte, meist bei der Freiwilligen Feuerwehr oder der Verwaltung, an denen Internet und Strom auch über Notstromaggregate zur Verfügung stehen sollen. Zwar ist die Kabine dank der Solarpaneele und der Satellitenkommunikation für eine gewisse Zeit autark. Trotzdem wünschen wir uns natürlich, dass auch Personal bereitsteht, um Betreuung zur Verfügung zu stellen und vielleicht auch mal Verbrauchsmaterial nachzufüllen.
Ein weiterer Punkt ist die Logistik. Die Toilettenkabinen lassen sich laut Hersteller innerhalb von 30 Minuten aufbauen. Deshalb ist die Frage, ob künftig vielleicht nur noch die Technik eingelagert werden muss, weil die Kabinen ohnehin schnell lieferbar wären. Baut man die Technik zum Beispiel in eine Box, braucht man natürlich viel weniger Lagerkapazität und Wartungsaufwand. Das wäre dann ein modulares Konzept: Die Kabinen kommen separat, und die Box wird einfach an die Wand gehängt.
Die neue Kabine sieht nach der Überarbeitung recht massiv aus. Kann sie noch einfach transportiert werden?
Ja. Es ist eine ganz normale Toilettenkabine aus Kunststoff, die von uns lediglich innen ausgestattet wurde. Nur der Tank wurde entfernt, und es ist ein gerader Boden eingebaut. Die kann man mit zwei Personen problemlos versetzen. Zusätzlich hat sie oben auch eine Kranhalterung. Wir haben sie inzwischen auch schon an einen Kran gehängt, zum Beispiel vom THW. Damit kann man sie sehr schnell positionieren.
Es gibt bereits viele fertige Logistikkonzepte für diese Toilettenkabinen. Toilettenkabinen werden oft auch mit Spülflüssigkeit angeliefert und haben dann ein ähnliches Gewicht. Sie können zum Beispiel über einen Tieflader mit Kran angeliefert und leicht versetzt werden.
Haben Sie versucht, die Kabine günstig zu entwickeln?
Ja. Unser Ziel war immer, sie so günstig wie möglich zu machen. Wir wollten, dass sie unter 5000 Euro kostet.
Die enthaltenen Geräte sollen möglichst einfach funktionieren. Außerdem sollen Teile, auch wenn die Kabine Schaden nimmt, wiederverwendet werden können. Es kann auch sein, dass die gesamte Kabine, ohne Inhalt, entsorgt werden oder ihrem ursprünglichen Zweck zugeführt werden muss. Denkbar wäre auch, dass sich das System ganz ohne die Kabine nutzen lässt – also nur die Technik allein.
Das Konzept ließe sich doch auch außerhalb des Katastrophenschutzes einsetzen?
Ja, deshalb glaube ich auch an diesen modularen Ansatz mit einer Box. Die kann ich natürlich genauso in eine Apotheke hängen. Es kann ja auch mal sein, dass zum Beispiel in einem Gemeindehaus noch ein Raum zur Verfügung steht. Dann brauche ich vielleicht die Kabine gar nicht. Dann würde ich diese Box einfach in einen Raum hängen.
Die Toilettenkabine ist für uns insofern praktisch, da sie kostengünstig ist und weit unter 1000 Euro kostet. Sie kann sogar per Boot transportiert werden, weil sie schwimmfähig ist, oder alternativ auf einem Tieflader. Mit diesem Kranhaken kann man sie theoretisch sogar an einen Helikopter hängen, um sie in ein Dorf zu fliegen, das etwa durch einen Brückeneinsturz von der Außenwelt abgeschnitten ist.
Wie geht es nach dem Forschungsprojekt weiter?
Das Projekt wird vom Bundesministerium für Forschung, Technologie und Raumfahrt gefördert. Das Bundesamt für Bevölkerungsschutz und Katastrophenhilfe ist als assoziierter Partner beteiligt, ebenso das Generalsekretariat des Deutschen Roten Kreuzes in Berlin. Das Forschungsprojekt wurde inzwischen erfolgreich abgeschlossen und live demonstriert [1].
Das DRK ist tatsächlich sehr daran interessiert, mit uns weiterzudenken, welche Ebene für die Bevorratung zuständig sein sollte. Sollte jedes Bundesland zehn Kabinen haben oder jede Kommune, jeder Katastrophenschutz-Leuchtturm eine? Das betrifft auch das Thema Wartung. Die Medizingeräte sind mit Sicherheit in fünf Jahren überholt und müssen erneuert werden.
Es bringt nichts, wenn das Ergebnis, wie so oft bei Forschungsprojekten, am Ende nur in irgendeiner Schublade landet. Man muss im Endeffekt genau diesen Zwischenschritt schaffen: Dass jemand sagt, wir brauchen jetzt 20 Stück davon, und ein Unternehmen bereit ist, sie zu verkaufen.
Gibt es bereits weitere Einsatzideen?
Eine große Überlegung ist, ob man das System nicht auch für Routinezwecke einbinden kann. Wir denken da zum Beispiel an Sanitätswachdienste auf Großveranstaltungen oder daran, im Rahmen der Flüchtlingsversorgung medizinische Hilfe auch im fremdsprachigen Bereich zu gewährleisten. Bis hin zu der Überlegung, ob man eine solche Kabine dort aufstellen könnte, wenn in einem Dorf plötzlich kein Hausarzt mehr verfügbar ist – um zumindest stundenweise an manchen Tagen eine hausärztliche Grundversorgung durch einen anderen Arzt zu gewährleisten.
Welche Software kommt zum Einsatz?
Als Basis für die Software nutzen wir „TeleDoc“, eine zertifizierte Videosprechstunde der Docs in Clouds TeleCare GmbH. Die medizinischen Geräte sind alle in die Software integriert und übertragen ihre Daten per Bluetooth. Im Use Case Parookaville und bei den Simulationsstudien war das sehr stabil. Es ist alles kabelgebunden oder per Bluetooth angeschlossen.
Das Ganze funktioniert als Webplattform. Ich kann es quasi überall auf der Welt nutzen und der Arzt kann sich dank Satellitenkommunikation aus der Ferne zuschalten. Zusätzlich habe ich die Möglichkeit, extern auch LAN anzuschließen – steht die Kabine beispielsweise an einem Katastrophenschutz-Leuchtturm, kann ich gegebenenfalls das lokale Internet nutzen.
URL dieses Artikels:
https://www.heise.de/-11359097
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Die Samsung SSD 980 bekommt eine Nachfolgerin. Die 990 ist rund doppelt so schnell, verwendet allerdings QLC-Speicher.
Samsung stellt die SSD 990 als neues Einstiegsmodell vor. Wie schon die 980er-Vorgängerin fehlt ein Anhängsel wie Pro oder Evo. Unter der Haube hat sich einiges getan: Der Controller wechselt von PCI Express (PCIe) 3.0 auf 4.0, was in etwa mit einer Geschwindigkeitsverdoppelung einhergeht. Vierstellige Modellnummern bleiben bei Samsung bis auf Weiteres PCIe-5.0-Topmodellen vorbehalten.
Auf dem Papier weniger erfreulich ist der Wechsel der NAND-Flash-Speicherbausteine. Kamen bisher Typen zum Einsatz, die drei Bit pro Zelle speichern (Triple Level Cells, TLC), sind es jetzt vier Bit pro Zelle (Quadruple Level Cells, QLC [1] [1]). Das senkt die Schreibleistung beim Kopieren großer Dateien, dürfte sich im alltäglichen Gebrauch bei den meisten aber nur selten bemerkbar machen.
Auf Seiten der Kapazität fallen die Varianten unter einem Terabyte weg. Stattdessen bietet Samsung die SSD 990 neben der 1-TByte-Version jetzt auch eine mit 2 TByte an.
URL dieses Artikels:
https://www.heise.de/-11364577
Links in diesem Artikel:
Copyright © 2026 Heise Medien
