Anmelden
(Bild: heise medien)
Google Cloud verschiebt seine gesamte technische Dokumentation auf eine neue Domain und setzt dabei verstärkt auf KI-gestützte Erstellung und Übersetzung.
Google Cloud hat seine gesamte technische Dokumentation auf die neue Domain docs.cloud.google.com [1] verlagert. Die Umstellung ist Teil einer umfassenden KI-Transformation der Dokumentationserstellung und -bereitstellung.
Die neue Plattform setzt auf eine vereinheitlichte technische Basis, die als Fundament für KI-gestützte Funktionen dient. Google nutzt dabei sein hauseigenes KI-Modell Gemini beim Schreiben der Dokumentation. Auch die Übersetzung erfolgt KI-gestützt, wodurch das Unternehmen die Dokumentation für die meisten Produkte in zwölf Sprachen, unter anderem Deutsch, verfügbar macht – deutlich mehr als zuvor.
Die Autoren bei Google Cloud setzen Gemini direkt in ihrer Schreibumgebung ein, was als "Produktivitätsmultiplikator" fungieren soll. Um die neue Plattform schneller und responsiver zu machen, hat Google zudem den Code optimiert und die Backend-Komplexität reduziert.
Für die Migration hat Google die bestehende URL-Struktur beibehalten. Aus cloud.google.com/compute/docs/instances wird künftig docs.cloud.google.com/compute/docs/instances. In den kommenden Wochen werden Besucher automatisch von den alten URLs zur neuen Domain weitergeleitet. Alte Links sollen auf absehbare Zeit weiterhin funktionieren.
Die bisherige Domain cloud.google.com bleibt für andere Inhalte bestehen: Blog-Beiträge, Produktübersichten und Preisinformationen bleiben dort verfügbar. Nur die technische Dokumentation wechselt vollständig auf die neue Subdomain. Weitere Details zur Umstellung finden sich im Google-Blog [2].
URL dieses Artikels:
https://www.heise.de/-10964046
Links in diesem Artikel:
[1] https://docs.cloud.google.com
[2] https://cloud.google.com/blog/topics/developers-practitioners/announcing-docscloudgooglecom-the-new-home-for-google-cloud-documentation/?hl=en
[3] https://www.heise.de/ix
[4] mailto:fo@heise.de
Copyright © 2025 Heise Medien
(Bild: Andrey_Popov/Shutterstock.com)
Cursor 2.0 führt mit Composer ein eigenes KI-Coding-Modell und ein neues Interface für paralleles Arbeiten mit mehreren Agenten ein.
Mit Version 2.0 erweitert die KI-gestützte Entwicklungsumgebung Cursor ihr Funktionsspektrum deutlich. Die IDE setzt auf sogenannte agentische Entwicklung, bei der mehrere spezialisierte KI-Agenten gemeinsam Code schreiben, prüfen und testen. Neben einem neuen Interface für die parallele Arbeit mit solchen Agenten stellt das Unternehmen mit Composer auch sein erstes eigenes Coding-Modell vor.
Composer ist laut Cursor [1] rund viermal schneller als Modelle mit vergleichbarer künstlicher Intelligenz und auf geringe Latenzzeiten bei codierenden Agenten optimiert. Die meisten Anfragen beantwortet das Modell offenbar in unter 30 Sekunden. Testnutzer hätten vor allem die schnelle Interaktion und die Zuverlässigkeit bei mehrstufigen Aufgaben hervorgehoben.
Das Modell nutzt Werkzeuge wie semantische Codebase-Suche, um größere Codebasen besser zu verstehen und darin zielgerichtet zu arbeiten – eine Stärke, die besonders bei der Integration verschiedener Agenten zum Tragen kommen soll.
Das neue Interface stellt Agenten ins Zentrum des Workflows. Entwicklerinnen und Entwickler sollen damit stärker ergebnisorientiert arbeiten können, während die Agenten die Umsetzung übernehmen. Wer dennoch direkt im Code arbeiten will, kann jederzeit zu einer klassischeren IDE-Ansicht wechseln.
Cursor 2.0 erlaubt es außerdem, mehrere Agenten parallel auf separaten Git-Worktrees oder entfernten Maschinen laufen zu lassen. Dadurch können mehrere Modelle unabhängig an derselben Aufgabe arbeiten – das beste Ergebnis wird dann ausgewählt. Laut Cursor führt dieses Verfahren bei komplexeren Aufgaben zu einer spürbaren Qualitätssteigerung.
(Bild: Cursor [2])
Das Entwicklerteam hinter Cursor adressiert mit dem Update auch zwei Engpässe aus der bisherigen Nutzung von KI-Agenten: Code-Reviews und Tests. Version 2.0 soll das Überprüfen von Änderungen durch neue Vergleichsansichten und ein integriertes Browser-Tool zum Testen des generierten Codes optimieren. Damit soll die KI ihre Ergebnisse automatisch validieren und verbessern können.
Cursor 2.0 steht ab sofort über die Download-Seite [3] zum Herunterladen zur Verfügung. Eine vollständige Liste aller Neuerungen findet sich im Changelog [4].
URL dieses Artikels:
https://www.heise.de/-10964084
Links in diesem Artikel:
[1] https://cursor.com/blog/2-0
[2] https://cursor.com/blog/2-0
[3] https://cursor.com/download
[4] https://cursor.com/changelog/2-0
[5] mailto:mdo@ix.de
Copyright © 2025 Heise Medien
(Bild: evkaz/Shutterstock.com)
Die npm-Pakete waren seit Juli verfügbar, haben die Schadroutinen aufwendig verschleiert und setzen auf ein Fake-CAPTCHA, um authentisch zu erscheinen.
Im JavaScript-Paketmanager npm waren seit Anfang Juli Pakete mit gut verstecktem Schadcode verfügbar. Das auf Software-Supply-Chain-Security spezialisierte Unternehmen Socket hat zehn Pakete gefunden, die zusammen auf 9900 Downloads kommen. Laut dem Socket-Blog waren sie am 28. Oktober noch auf npm verfügbar, sind dort inzwischen aber nicht mehr zu finden.
Die Pakete laden einen für das Betriebssystem passenden Infostealer nach, der unter Windows, macOS und Linux Zugangsdaten abgreift. Der Angriff ist mehrfach verschleiert.
Die Angreifer setzen bei der Verteilung des Schadcodes auf Typosquatting: Die npm-Pakete tragen ähnliche Namen wie legitime Packages, darunter typescriptjs statt TypeScript und dizcordjs statt discord.js. Socket hat folgende Pakete mit Schadcode gefunden: typescriptjs, deezcord.js, dizcordjs ,dezcord.js, etherdjs, ethesjs, ethetsjs, nodemonjs, react-router-dom.js und zustand.js.
Die Installationsroutine, die sich im "postinstall" der Konfiguration in package.json befindet, öffnet betriebssystemabhängig ein neues Terminalfenster, in dem sie dann mittels Node die Anwendung app.js startet. Auf die Weise bleibt die Ausführung im Hauptfenster verborgen.
Die Datei app.js verschleiert den Schadcode mit unterschiedlichen Methoden, darunter URL-Encoding und Switch-Anweisungen mit hexadezimalen und oktale Berechnungen:
FreshRSS // Control flow obfuscation makes it difficult to follow execution path
var kMvc = (0x75bcd15-0O726746425); // Evaluates to 0
while(kMvc < (0o1000247%0x10023)) { // Loop condition with mixed bases
switch(kMvc) {
case (0x75bcd15-0O726746425): // Case 0
kMvc = condition ? (262270%0o200031) : (0o204576-67939);
break;
case (0o203030-67070): // Case 1
// Actual logic here
break;
}
}Die Kommentare im Codeausschnitt stammen von Socket. Um authentisch zu wirken, zeigt die Malware schließlich vor dem Start ein CAPTCHA als ASCII Art an.
(Bild: Socket)
Nach der Eingabe einer beliebigen Zeichensequenz – das CAPTCHA ist eine reine Ablenkungsmaßnahme – sendet der Schadcode die IP-Adresse des Zielsystems an einen Server der Angreifer und lädt ein Binary herunter, das zum zuvor ermittelten Betriebssystem passt.
Dafür wechselt die Schadsoftware die Programmiersprache auf Python: Der Schadcode findet sich in dem PyInstaller-Paket mit dem in keinster Weise verschleierten Namen "data_extracter". PyInstaller verpackt eine Python-Anwendungen [1] mit allen Dependencies in ein Paket und führt es auf dem Zielsystem aus. PyInstaller ist für Linux, Windows und macOS verfügbar und benötigt keine Python-Installation.
data_extracter sucht in zahlreichen Verzeichnissen und Dateien nach Zugangsdaten, darunter Firefox- und Chromium-Datenverzeichnisse, Directories für SSH-Schlüssel und Konfigurationsverzeichnisse wie ~/.aws/credentials. Das Programm durchsucht unter anderem SQLite-Datenbankdateien und JSON-Konfigrautionsdateien auf API-Keys und andere Credentials.
Die Anwendung greift zudem Cookie-Daten aus dem Browser ab und untersucht betriebssystemabhängig die Keyrings. Außerdem versucht sie Authentifizierungs-Token abzugreifen. Die gesammelten Credentials verpackt der data_extracter in eine Zip-Datei, die er schließlich an einen Server der Angreifer sendet.
Wer eins der genannten Pakete installiert hat, muss davon ausgehen, dass die Angreifer Daten abgegriffen haben. Auch wenn die gefundenen Pakete inzwischen nicht mehr zu finden sind, waren sie über drei Monate im Umlauf, und schon aufgrund der ausgefeilten Verschleierungstechniken könnten andere Pakete mit einer Variante des Angriffs betroffen sein.
Weitere Details zu den betroffenen Paketen, der Netzwerkinfrastruktur und den verwendeten MITRE ATT&CK-Techniken finden sich im Socket-Blog [2].
Der Vorfall ist ein erneutes Indiz, dass npm für Supply-Chain-Angrffe anfällig bleibt. Entwickler können jedoch einige Schutzmaßnahmen [3] ergreifen.
URL dieses Artikels:
https://www.heise.de/-10963994
Links in diesem Artikel:
[1] https://pyinstaller.org/en/stable/
[2] https://socket.dev/blog/10-npm-typosquatted-packages-deploy-credential-harvester
[3] https://www.heise.de/blog/npm-als-Sicherheitsrisiko-Warum-Angriffe-zunehmen-und-wie-man-vorbeugen-kann-10590859.html
[4] mailto:rme@ix.de
Copyright © 2025 Heise Medien
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Ein schwerwiegender Ausfall der Microsoft-Cloud-Plattform Azure hat am 29. Oktober 2025 kurz vor 17:00 Uhr (MEZ) begonnen und betrifft weltweit zahlreiche Dienste – nur eine Woche nachdem bereits AWS-Probleme weite Teile des Internets lahmlegen. Die Störung beeinträchtigt sämtliche auf Azure basierende Microsoft-Dienste, darunter Microsoft 365, Xbox und sogar Minecraft, so The Verge .
Auf der Azure-Statusseite führt Microsoft den Ausfall auf eine "unbeabsichtigte Konfigurationsänderung" zurück. Gegen 20:20 Uhr (MEZ) teilte das Unternehmen mit, die letzte funktionierende Konfiguration wieder eingespielt zu haben. Die vollständige Wiederherstellung werde innerhalb der nächsten vier Stunden erwartet.
In einer Mitteilung hieß es: "Seit etwa 16:00 UTC können Kunden und Microsoft-Dienste, die Azure Front Door (AFD) nutzen, Probleme mit Latenzzeiten, Zeitüberschreitungen und Fehlern haben. Wir bestätigen, dass eine unbeabsichtigte Konfigurationsänderung der Auslöser für dieses Problem war."
Um 17:25 Uhr meldete der Microsoft-365-Statusaccount auf X , man untersuche Berichte über "Probleme beim Zugriff auf Microsoft-365-Dienste und das Microsoft-365-Admincenter" . Ein Update eine halbe Stunde später besagte, dass "Teile der internen Infrastruktur Verbindungsprobleme" aufweisen. Die Xbox-Statusseite lässt sich zeitweise gar nicht aufrufen.
Der Ausfall beschränkt sich nicht auf Microsoft-eigene Dienste. Alaska Airlines und Hawaiian Airlines berichten von "Störungen kritischer Systeme, einschließlich unserer Websites" aufgrund von Azure-Problemen. Die Fluggesellschaften raten Passagieren, sich für den Check-in direkt an Mitarbeiter am Flughafen zu wenden, falls das Online-Einchecken nicht funktioniert.
Der britische Internetanbieter Community Fibre bestätigte ebenfalls, dass einige Kunden aufgrund des Microsoft-Ausfalls Probleme erleben könnten. Auch die Supermarktkette Kroger meldet eine "unerwartete Störung" ihrer Website und mobilen Apps. Die Websites von Starbucks und Costco sind nicht erreichbar und auch zahlreiche andere, namhafte Sites waren nicht erreichbar.
Der Ausfall ereignet sich nur wenige Stunden bevor Microsoft seine Quartalszahlen präsentieren will.
(Bild: aapsky/Shutterstock.com)
Durch mangelhaften Zugriffsschutz bei Collins Aerospace ließen sich Nachrichten an Flugzeug-Cockpits schicken.
Bei Collins Aerospace ist ein weiteres schwerwiegendes IT-Sicherheitsproblem aufgetreten. Ende September kam es bei dem Dienstleister für diverse Flughäfen weltweit zu einem Datenabzug, bei dem das Unternehmen von Ransomware sprach, die Boarding- und Check-in-Systeme offline nahm und in der Folge der Flugbetrieb an den Flughäfen Berlin oder Brüssel beeinträchtigt wurde. Nun hat der Chaos Computer Club (CCC) herausgefunden, dass auch weitere Systeme schlecht gesichert waren und es etwa möglich war, Nachrichten in Flugzeug-Cockpits zu senden.
Das kürzliche Datenleck ging auf Zugangsdaten aus dem Jahr 2022 [1] zurück, die seitdem nicht geändert wurden und aufgrund eines Infostealers ins Internet gelangten. Etwas mehr Kopfschütteln verursacht der nun vom CCC gefundene [2], mit trivialen Zugangsdaten "geschützte" Zugang. Collins Aerospace betreibt das ARINC Opcenter, mit dem Nachrichten von und zu Flugzeugen verteilt und aufbereitet werden, etwa von Betriebsdaten. Dazu gehören auch ACARS-Nachrichten (Aircraft Communications Addressing and Reporting System), die technische Zustandsdaten, Flugpläne oder auch Verspätungen umfassen.
Der CCC konnte sich mit Benutzername "test" – und IT-Experten vermuten es bestimmt schon – Passwort "test" in das ARINC OpCenter einloggen und dort in den Message Browser gelangen. Ein Eintrag in der Wayback-Machine [3] (PDF) zeigt die Benutzeroberfläche und die Abfrage von Nachrichten zu einem bestimmten Flugzeug. Der Zugang wies die IT-Forscher als "US Navy Fleet Logistics Support Wing" aus.
Mit dem Zugang ließen sich versendete Nachrichten einsehen. Das Portal ermöglicht auch das Senden von Nachrichten ins Flugzeug-Cockpit – was der CCC jedoch ausdrücklich nicht ausprobiert hat.
Die CCC-Analysten haben sowohl die Muttergesellschaft RTX Corporation von Collins Aerospace, als auch das Department of Defense Cyber Crime Center der USA kontaktiert und über die Schwachstelle informiert. Rückmeldungen gab es keine. Jedoch wurde der Zugang inzwischen deaktiviert.
Die mangelnde Passwort-Hygiene und Zugangssicherung bei Collins Aerospace scheint ein weiterreichendes Problem zu sein, als der Cyberangriff im September vermuten ließ. Das ist umso schwerwiegender, da die Firma ein System betreibt, das global so weit eingesetzt wird und bis in die Flugzeug-Cockpits reicht, wie ARINC.
URL dieses Artikels:
https://www.heise.de/-10963151
Links in diesem Artikel:
[1] https://www.heise.de/news/Collins-Aerospace-Alte-Passwoerter-und-verzoegerte-Reaktion-ermoeglichen-Datenklau-10900172.html
[2] https://www.ccc.de/de/disclosure/collins-aerospace-mit-test-test-textnachrichten-bis-ins-cockpit-senden
[3] https://data.ntsb.gov/Docket/Document/docBLOB?ID=40312110&FileExtension=.PDF&FileName=Operations%202V%20-%20ACARS%20Report-Master.PDF
[4] https://aktionen.heise.de/heise-security-pro?LPID=39555_HS1L0001_27416_999_0&wt_mc=disp.fd.security-pro.security_pro24.disp.disp.disp
[5] mailto:dmk@heise.de
Copyright © 2025 Heise Medien
Die US-Firma Bolt Graphics führt ihre GPU Zeus mit Path-Tracing-Technik und bis zu 160 GByte RAM vor. Zeus nutzt RISC-V-Kerne.
Eine große Stärke der offenen Befehlssatzarchitektur RISC-V ist ihre Flexibilität. Die nutzt das kalifornische Unternehmen Bolt Graphics für ihre Graphics Processing Unit (GPU) Zeus. Allerdings zielt Zeus nicht auf Gaming-PCs oder KI-Rechenzentren, sondern zunächst auf Einsatzbereiche wie 3D-Rendering mit Programmen wie Blender, Autodesk Maya oder der Unreal Engine.
Für solche Anwendungszwecke eignet sich Zeus laut Bolt Graphics besser als gewöhnliche PC- und Workstation-Grafikkarten, etwa von Nvidia. Denn erstens steuert Zeus viel lokalen Speicher an und nutzt zweitens die Berechnungstechnik Pathtracing [1]. Die soll Vorteile im Vergleich zum etablierten Raytracing bieten.
Als weiteren Einsatzbereich für Zeus sieht Bolt Graphics auch wissenschaftliche und technische Simulationsprogramme. Denn die Gleitkommarechenwerke der in Zeus eingebauten RISC-V-Prozessorkerne nach RVA23-Spezifikation [2] liefern hohe Leistung auch bei doppelt genauen Werten, also Double Precision (DP) alias FP64.
Zeus hat nicht nur RISC-V-Kerne, sondern auch sonst ungewöhnliche Eigenschaften für eine GPU. Ein Zeus-Chip hat 128 MByte eingebauten Cache und steuert 32 GByte LPDDR5X-RAM an – also nicht etwa schnelleres, aber auch teureres und stromdurstigeres GDDR7-RAM oder HBM. Außerdem stecken in Zeus auch DDR5-Speichercontroller für bis zu 128 GByte (2 × 64 GByte) Erweiterungsspeicher in Form von (SO-)DIMMs.
(Bild: Bolt Graphics)
Eine Chiplet-zu-Chiplet-Schnittstelle mit bis zu 768 GByte/s verbindet zwei oder vier Zeus-Chiplets. Zudem bindet Zeus ein I/O-Chiplet mit 256 GByte/s an, das wiederum zwei PCIe-5.0-x16-Ports bereitstellen kann sowie auch Ethernet mit 400 Gbit/s und einen Netzwerkport für die Fernverwaltung (BMC).
Über die schnellen Ethernetports – Produktvarianten sollen 800GbE bringen – lassen sich mehrere Zeus-Systeme zu Clustern koppeln. Ein zusätzlicher Allzweckprozessor (CPU) zum Booten eines Betriebssystems ist überflüssig, weil die RVA23-Kerne auch selbst Linux ausführen können. Zeus gehört also wie Nvidia Grace Hopper/Grace Blackwell und der AMD Instinct MI300A zur Klasse der Server-APUs.
Die einfachste Zeus-GPU heißt 1c26-032. Sie hat ein einziges Zeus-Chiplet und soll als PCIe-x16-Karte mit 120 Watt TDP auskommen.
Bolt Graphics verspricht für Zeus [3] 1c26-032 eine maximale FP64-Rechenleistung von 5 TFlops sowie 614 Tops für Integer-Matrixberechnungen (Int8). Bestimmte Rechenaufgaben und vor allem Path Tracing soll eine Zeus 1c26-032 mit 120 Watt deutlich schneller erledigen als eine Nvidia GeForce RTX 5080 [4] mit 360 Watt, die auch nur 16 GByte (schnelleres) RAM besitzt.
Bolt Graphics führte Zeus-Prototypen kürzlich auf dem OCP Global Summit des Open Compute Project vor. Die Serienproduktion soll erst 2027 laufen, aber Entwickler sollen bereits im ersten Halbjahr 2026 auf Demosysteme zugreifen können.
URL dieses Artikels:
https://www.heise.de/-10963652
Links in diesem Artikel:
[1] https://www.heise.de/news/Cyberpunk-2077-Grafikmodus-Raytracing-Overdrive-auf-PC-verfuegbar-8936546.html
[2] https://www.heise.de/news/RISC-V-CPUs-mit-RVA23-Mehr-Leistung-und-bessere-Linux-Unterstuetzung-9993260.html
[3] https://bolt.graphics/how-it-works/
[4] https://www.heise.de/tests/High-End-Grafikkarten-mit-Nvidia-GeForce-RTX-5080-und-5090-im-Test-10290707.html
[5] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[6] https://www.heise.de/ct
[7] mailto:ciw@ct.de
Copyright © 2025 Heise Medien
(Bild: Elecrow)
Elecrow stellt ein 7-Zoll-Display mit ESP32-P4 und Wi-Fi 6 vor – gedacht für interaktive IoT- und KI-Projekte im Maker-Umfeld.
Mit dem CrowPanel Advanced 7inch bringt Elecrow ein neues Smart-Display auf Basis des ESP32-P4-SoC auf den Markt. Die Bildschirm-ESP-Combo ist für Maker interessant, die interaktive Steuerpanels oder KI-gestützte Anwendungen mit grafischer Aus- oder Eingabe umsetzen wollen. Das System kombiniert zwei Mikrocontroller und bietet damit deutlich mehr Rechenleistung und Flexibilität als frühere ESP32-Generationen.
Im Zentrum steht der RISC-V-basierte ESP32-P4, der mit bis zu 400 MHz taktet. Er verfügt über einen Hochleistungs- und einen stromsparenden Kern und ist mit 16 MB Flash und 32 MB PSRAM gepaart. Ein zusätzliches ESP32-C6-MINI-1-Modul kümmert sich um drahtlose Verbindungen. Es unterstützt Wi-Fi 6 (2,4 GHz) sowie Bluetooth 5.3. Dafür ist es für IoT-Anwendungen gerüstet.
Das 7-Zoll-Display bietet eine Auflösung von 1024 × 600 Pixeln auf einem IPS-Panel mit 178 Grad Blickwinkel. Es reagiert über kapazitiven Touch auf Eingaben. Optional lässt sich eine 2-Megapixel-Kamera anschließen, die über MIPI-CSI angebunden wird. Sie kann für KI-Funktionen wie Gesichtserkennung oder Objektverfolgung genutzt werden.
Audioseitig ist das Board mit einem NS4168-Codec, zwei Lautsprechern und einem Mikrofon-Array ausgestattet. Damit lassen sich Sprachsteuerungen oder einfache Assistenten umsetzen. Der integrierte Verstärker erlaubt zudem Sprachfeedback oder andere akustische Signale, was bei Steuerpulten oder smarten Displays nützlich ist.
Für Maker vorteilhaft ist die Vielzahl an Schnittstellen: Neben einem 40-Pin-GPIO-Header stehen zwei USB-C-Anschlüsse (UART und OTG), Crowtail-Ports (kompatibel zu I²C und UART) sowie ein Steckplatz für wechselbare Funkmodule zur Verfügung. Damit lässt sich das Board etwa auf Zigbee, Thread oder LoRaWAN erweitern – nützlich für Projekte, die unterschiedliche IoT-Protokolle erfordern.
Entwickelt wird mit bekannten Tools: Elecrow unterstützt die Arduino IDE, LVGL und MicroPython, zusätzlich auch ESP-IDF und Rust. Dadurch lassen sich bestehende Projekte mit ESP32 direkt übernehmen.
Mit einer Größe von 180 × 105 mm und M3-Montagebohrungen lässt sich das Modul in Gehäuse oder Bedienpanels einbauen. Die Stromversorgung erfolgt über USB oder eine externe 5V/2A-Quelle. Das Gerät ist zwischen -20 und +70 °C einsatzfähig und hält damit einiges aus.
Das CrowPanel Advanced 7inch ist über den Elecrow-Shop [1] erhältlich. Der Preis liegt – je nach Ausstattung und optionalen Funkmodulen – zwischen 45,90 US-Dollar und 60,60 US-Dollar. Für den Einstieg findet man auf der Herstellerseite [2] einen Quick-Start-Guide. Auf GitHub [3] ist auch der Sourcecode der Standardfirmware bereitgestellt.
Wer kein HD-IPS-Display braucht, aber trotzdem mit einem Display arbeiten will, findet in unserem Artikel zum Tibber Rahmen mit E-Ink-Display [4] neues Maker-Futter.
URL dieses Artikels:
https://www.heise.de/-10963297
Links in diesem Artikel:
[1] https://www.elecrow.com/crowpanel-advanced-7inch-esp32-p4-hmi-ai-display-1024x600-ips-touch-screen-with-wifi-6-compatible-with-arduino-lvgl-micropython.html?srsltid=AfmBOoqRIY0kY0ru7nP-YPpIBiO8RGI5nCQU7Vry7u0tOBhAe3DnQn5W
[2] https://www.elecrow.com/wiki/CrowPanel_Advanced_7inch_ESP32-P4_HMI_AI_Display_1024x600_IPS_Touch_Screen_with_WiFi6_Compatible_with_ArduinoLVGL.html
[3] https://github.com/Elecrow-RD/CrowPanel-Advanced-7inch-ESP32-P4-HMI-AI-Display-1024x600-IPS-Touch-Screen
[4] https://www.heise.de/ratgeber/Selbstgebauter-Preismonitor-zur-Ueberwachung-von-dynamischen-Strompreisen-9804052.html
[5] https://www.heise.de/make
[6] mailto:das@make-magazin.de
Copyright © 2025 Heise Medien
(Bild: Apple)
Apple verklagt Oppo und einen Ex-Mitarbeiter wegen Diebstahls von Geschäftsgeheimnissen. Der Mitarbeiter soll Interna zur Apple Watch an Oppo gegeben haben.
Apple hat seinen chinesischen Mitbewerber Oppo, die mit Oppo verbundene Firma Innopeak und einen ehemaligen Angestellten wegen mutmaßlichen Diebstahls von Geschäftsgeheimnissen verklagt. Der frühere Mitarbeiter Dr. Chen S. soll interne Informationen über die Apple Watch entwendet und in einem Vortrag vor hunderten Oppo-Mitarbeitern preisgegeben haben. Doch seit Einreichen der Klage im August [1] habe sich wenig getan, heißt es jetzt in einem Schreiben an den United States District Court für den nördlichen Bezirk Kaliforniens (Case No. 5:25-CV-7105).
Apple fordert Maßnahmen, um die Informationsweitergabe bei Oppo zu stoppen. Auch sollen Produkte, die Apple-Technologie enthalten könnten, untersagt werden, und Mitarbeiter, die Apple-Wissen erlangt haben, von wettbewerbsrelevanten Projekten ausgeschlossen werden.
Der frühere Apple-Mitarbeiter soll vor seinem Weggang bei Apple 63 vertrauliche Dateien aus Apples internen Systemen auf einen privaten USB-Speicher kopiert haben. Dies geht aus der Klageschrift Apples hervor. Die internen Ermittlungen des iPhone-Herstellers hätten zudem ergeben, dass der Beklagte unter falschem Vorwand in Einzelgesprächen mit anderen Mitarbeitern an weitere technische Details gelangt sei. Dabei sei es um existierende und künftige Wearables gegangen, speziell mit Blick auf optische und Temperatursensoren sowie EKG-Funktionen.
Aus diesen Erkenntnissen soll der frühere Apple-Mitarbeiter in zwei internen Oppo-Veranstaltungen vor einer dreistelligen Zahl von Oppo-Ingenieuren berichtet haben. Apple legte in der Klageschrift Bildschirmfotos vor, aus denen hervorgeht, dass diese "Talks" zielgerichtet auch so beworben wurden, dass der Beklagte über Apples Vorgehensweise berichtet. Die interne Präsentation wurde als "Apples Sensor Hardware-Entwicklungsphilosophie und -Methodik" beworben mit dem Aufhänger "Sind Sie neugierig, wie Apples Sensoren entwickelt werden?" Zudem sei in Fragerunden auf Details aus der Entwicklungsarbeit Apples eingegangen worden. Der Beklagte habe sogar Apple-Folien wiederverwendet.
Während der frühere Mitarbeiter gegenüber Apple kooperativ gewesen sei, weist Oppo laut des gemeinsamen Status-Berichts der Anwälte [2] alle Vorwürfe zurück. Auch habe das chinesische Unternehmen bislang keinen Beitrag dazu geleistet, zur weiteren Aufklärung beizutragen. Apple wirft Oppo sogar vor, den angeworbenen früheren Mitarbeiter gezielt dazu gebracht zu haben, Geschäftsgeheimnisse zu entwenden. So habe der Leiter des Bereichs Gesundheit bei Oppo das Verhalten des früheren Apple-Mitarbeiters ausdrücklich gebilligt. Das Gericht hat Oppo angewiesen, bis Ende Oktober alle angeforderten Dokumente herauszugeben. Der Ex-Mitarbeiter, der von Januar 2020 bis Juni 2025 bei Apple tätig war, hat indessen aus gesundheitlichen Gründen um Aufschub gebeten.
URL dieses Artikels:
https://www.heise.de/-10963515
Links in diesem Artikel:
[1] https://www.heise.de/news/Apple-verklagt-Ex-Mitarbeiter-Apple-Watch-Geschaeftsgeheimnisse-an-Oppo-gegeben-10590559.html
[2] https://de.scribd.com/document/939716293/Apple-v-Shi-Status-Report
[3] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[4] mailto:mki@heise.de
Copyright © 2025 Heise Medien
Apple TV 4K mit HomePod mini.
(Bild: Apple)
Eigentlich ist Apples Pipeline für 2025 bereits gut gefüllt. Doch Zubehörartikel könnte es noch geben – etwa ein neues Apple TV 4K. Was könnte kommen?
Nach vier neuen iPhones [1], drei neuen Apple-Watch-Modellen [2], den AirPods Pro 3 [3], dem MacBook Pro M5 [4], dem iPad Pro M5 [5] sowie der Vision Pro M5 [6] scheint Apple für das anstehende Weihnachtsgeschäft gut ausgestattet zu sein. Dennoch glauben Beobachter, dass zumindest noch kleinere Produkte im November an den Start gebracht werden könnten – oder sogar kurz vor Geschenkeschluss im Dezember. Neben den lange erwarteten AirTags der zweiten Generation [7] könnte dies insbesondere eine Neuauflage der Multimediabox Apple TV 4K sein.
Zur Erinnerung: Die dritte Generation der 4K-Hardware ist bereits seit Herbst 2022 auf dem Markt und verfügt daher nur über ein angestaubtes Innenleben. Der darin verbaute A15 Bionic erschien im September 2021 zusammen mit dem iPhone 13. Das SoC verfügt über nur fünf CPU-Kerne (ein Hochleistungskern wurde von Apple deaktiviert) plus fünf GPU-Kerne. Möglich sind unter anderem HDR10+, HDMI 2.1 mit QMS und maximal 128 GByte Speicherplatz (Modell mit Ethernet und Thread statt nur WLAN). Die mitgelieferte Siri Remote wurde auf USB-C umgestellt (statt Lightning).
Ein neues Modell hat also eine Reihe von Verbesserungspotenzialen. Das beginnt beim SoC. Entfleuchter Apple-Code [8] besagt, dass Apple hier auf den A17 Pro aus dem iPhone 15 Pro (von 2023) upgraden könnte. In Sachen Funktechnik wird auf Apples hauseigenen N1 gehofft, der Wi-Fi 7 beherrscht, wenn auch nicht mit maximaler Bandbreite [9]. Auch in Sachen Bluetooth/Thread wären Verbesserungen denkbar. In vielen Haushalten dient die Apple-TV-4K-Box auch als Home Hub (Steuerzentrale) [10] für Apple Home. Weiterhin könnte Apple mehr Speicher verbauen, etwa auf 256 GByte gehen – das hilft etwa, wenn man (viele) größere Spiele auf dem Gerät verwendet.
Schließlich könnte ein neues Apple TV 4K – am Namen wird sich wohl nichts ändern – erstmals Apple-Intelligence-Features bieten, die Apple im kommenden Jahr seiner Sprachassistentin Siri verpassen [11] will. Der A17 Pro beherrscht das KI-System zumindest grundsätzlich. Schließlich gab es zuletzt auch Gerüchte, dass Apple am Formfaktor des Apple TV 4K schrauben könnte – etwa erstmals eine Kamera integrieren [12].
Derzeit ist für FaceTime-Videochats, die tvOS mittlerweile beherrscht, ein via WLAN eingebundene iPhone oder iPad [13] notwendig. Die Frage ist allerdings, wo konkret die Kamera in der Multimediabox sitzen müsste, damit sie die Fläche vor dem Fernseher ausreichend erfasst – und in korrekter Benutzerhöhe.
URL dieses Artikels:
https://www.heise.de/-10961315
Links in diesem Artikel:
[1] https://www.heise.de/tests/iPhone-17-17-Pro-17-Pro-Max-und-Air-im-Test-10663319.html
[2] https://www.heise.de/news/Apple-Watch-Series-11-SE-3-und-Ultra-3-Mehr-Gesundheit-besserer-Mobilfunk-10638405.html
[3] https://www.heise.de/tests/AirPods-Pro-3-im-Test-Mit-frischem-Klang-und-ANC-10663123.html
[4] https://www.heise.de/tests/Staubsaugen-im-Apple-Home-Diese-Haushaltsroboter-lohnen-sich-10751677.html
[5] https://www.heise.de/tests/Flach-und-flott-Das-neue-iPad-Pro-M5-im-Test-10792884.html
[6] https://www.heise.de/tests/Apple-Vision-Pro-M5-im-Test-Doppelt-haelt-besser-10793698.html
[7] https://www.heise.de/news/Warten-auf-neue-AirTags-Was-die-neuen-koennen-sollen-aktuelle-verbilligt-10515823.html
[8] https://www.heise.de/news/Prozessor-Leaks-Diese-SoCs-und-SiPs-plant-Apple-in-den-kommenden-Geraeten-10522553.html
[9] https://www.heise.de/news/Bericht-Apples-neuer-N1-Chip-auf-Broadcom-Niveau-kein-320-MHz-10643833.html
[10] https://support.apple.com/de-de/102557
[11] https://www.heise.de/news/Apple-Softwarechef-Kontextsensitive-Siri-war-keine-Vaporware-10440967.html
[12] https://www.heise.de/news/Apple-TV-Neues-Modell-noch-in-diesem-Jahr-10485518.html
[13] https://support.apple.com/de-de/guide/tv/atvb45658929/tvos
[14] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[15] https://www.heise.de/mac-and-i
[16] mailto:bsc@heise.de
Copyright © 2025 Heise Medien
Apps im Flekst0re: Teils dubioses Material.
(Bild: Screenshot Flekst0re)
Apple muss in der EU Konkurrenten zum iOS App Store zulassen. Flekst0re ist eines der Angebote, wobei es Sonderwege beschreitet. Das reißt Sicherheitslücken.
In der EU – und bald auch in weiteren Regionen – ist Apple dazu verpflichtet, alternative App-Marktplätze [1] zuzulassen. Der übliche Weg ist komplex und setzt aktuell sechs Schritte voraus [2], bis der User etwa den Epic Games Store auf seinem Gerät hat. Es gibt aber auch noch andere Wege, die nun die Security-Research-Abteilung des Mobile-Device-Management-Anbieters Jamf untersucht hat: Dienste, die verschiedene Tricks verwenden, um neue App-Quellen zu erschließen. Dabei kann es – wovor auch Apple stets intensiv warnt [3] – zum Reißen von schwerwiegenden Sicherheitslücken kommen.
Der sogenannte Flekst0re [4], der mit dem Slogal "Jailbreak ohne Jailbreak" wirbt, nutzt Apples reguläre Wege für alternative App-Marktplätze [5] nicht, sondern operiert mithilfe eines manuell zu installierenden Zertifikatsprofils [6]. Das macht die Sache nochmals unsicherer, zumal Apple hier dann für die derart vertriebenen Apps keinerlei auch nur rudimentäre Sicherheitsüberprüfung vornimmt.
Laut Jamf nutzen die Flekst0re-Server dann auch noch Enterprise-Distribution-Zertifikate, um die Apps auf die Geräte zu bekommen – auch das ein Hack. Damit werden alle Apple-Sicherheitsmerkmale ausgehebelt, obwohl die Anwendungen auf den Geräten selbst wie "normale" Apps aussehen. Auch das Angebot im Flekst0re wirkt dubios: Hier werden – mit Original-Icons versehene – "Sonderversionen" bekannter Apps wie YouTube, Instagram, WhatsApp oder TIkTok vertrieben, genauso wie bekannte Spiele, darunter sogar das für iOS gar nicht offiziell verfügbare "Cuphead".
Jamf zufolge können über den Vertriebsweg aufs Gerät gelangte Apps letztlich alles. Belegt wurde dies mit einer eigens manipulierten WhatsApp-Variante, die Chats mitschneiden und weiterversenden kann. Der Proof of Concept wurde über Flekst0re vertrieben, dann aber wieder gelöscht. Jamf rät, keinesfalls wichtige Accountdaten in solche Apps einzugeben und zudem auf die Quellen (Repositories, Repos) zu achten. Man dürfe zudem nicht annehmen, dass der nicht notwendige Jailbreak das Gerät sicher halte. "Unbekannten Code laufen zu lassen, der von unbekannten Parteien signiert wurde, könnte genauso oder noch gefährlicher sein."
FlekSt0re selbst gab gegenüber Jamf an, man teste alle Apps vorher "um sicherzustellen, dass sie laufen". Alle Apps seien zudem "sicher" und übertrugen "keine Daten oder andere Informationen", denn das sei "technisch schwierig". FlekSt0re sieht sich selbst nur als "bequemer Dienst für das Signieren von Anwendungen". Die Macher räumen allerdings ein, auch mindestens drei weitere Repositories eingebunden zu haben, die sie nicht selbst kontrolieren. "Wir sind mit den Machern im Kontakt, um sicherzustellen, dass die Apps genauso sicher sind." Allerdings sei man für die dort vertriebenen Anwendungen nicht verantwortlich, schließlich stünden sie auch für weitere Nutzer offen.
URL dieses Artikels:
https://www.heise.de/-10961981
Links in diesem Artikel:
[1] https://www.heise.de/news/App-Store-Alternative-AltStore-will-in-mehr-Laender-kommen-10733838.html
[2] https://www.heise.de/news/Sechs-Schritte-Epic-Games-zeigt-Apples-neuen-App-Marketplace-Installer-10699238.html
[3] https://www.heise.de/news/Apple-Digitalgesetz-DMA-der-EU-gehoert-abgeschafft-10670105.html
[4] https://www.jamf.com/blog/jtl-flekst0re-third-party-app-store-security-evaluation/
[5] https://support.apple.com/de-de/118110
[6] https://support.apple.com/de-de/102390
[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 © 2025 Heise Medien
Wie sieht die Perspektive für Frieden in der Ukraine aus?
(Bild: Anelo/Shutterstock.com )
John Mearsheimer erläutert, warum im Ukraine-Krieg die Chance auf Frieden vorerst vertan ist, der Westen daran mitschuldig ist und wie es weitergehen kann.
In einem am vergangenen Freitag erschienenen Video-Beitrag [1] räumt Professor John Mearsheimer, Politikwissenschaftler der University of Chicago und geopolitischer Analyst der realistischen Schule, mit zu Glaubenssätzen geronnenen Überzeugungen der westlichen politischen Klassen auf.
Seine Kernaussagen: EU-Politiker trügen eine Mitschuld am Scheitern der bisherigen Friedensbemühungen in der Ukraine. Reale Chancen auf Frieden seien verspielt worden und die Risiken, inklusive einer nuklearen Option, seien enorm. Mearsheimers Thesen, im deutschsprachigen Diskurs selten, sind erfrischend-kontrovers, scharf und unaufgeregt.
Sei es das Narrativ der neuen Suche Trumps nach Frieden [2] oder die Empörung Lawrows [3] über den "Sinneswandel" – entgegen aller emotional-medialer Wendungen argumentiert Mearsheimer nie moralisch.
Im Gespräch mit dem New Yorker sagte [4] der Absolvent der West-Point Militärakademie: "Wovor Putin sich fürchtet, ist, dass die Ukraine Teil der Nato wird." Später fügte er hinzu: "Hätte sich die Nato nicht ausgedehnt, (...) gäbe es diesen Krieg nicht."
Mearsheimers Interventionen [5], eine wiederkehrende Instanz mit zunehmender Kriegsdauer, entstammen der Theorie des "Offensiven Realismus" und basieren auf stringenten Grundfesten: In einem anarchischen, von Unsicherheiten zwischen den Staaten geprägten internationalen System entscheiden offensiv-militärische Fähigkeiten.
Seine 2001 im Werk "The Tragedy of Great Power Politics [6]" dargelegte Theorie gipfelt in der zentralen These, dass unter der staatlicherseits zur Handlungsmaxime erhobenen Doktrin des eigenen Überlebens der Zustand maximaler Sicherheit durch eigene Hegemonie erreicht werden könne.
Aus dieser Logik folgt für Mearsheimer [7] im Gegensatz zu diversen Theorien der Internationalen Beziehungen, dass Russland die Annäherung der Ukraine an den Nato-Westen als existenzielle Bedrohung wahrnehmen musste und werden die obigen Aussagen verständlich.
In seinem neuesten Beitrag kenntnisreich erläutert, dass es im frühen Stadium des Ukraine-Krieges reale Chancen auf Frieden gegeben habe.
Wie Mearsheimer in einem Interview zum zweijährigen Kriegsjubiläum erläuterte [8], beginnt der Konflikt für ihn schon in den 1990er Jahren.
"Die Gegner der Nato-Erweiterung, die im Grunde Realisten waren", so Mearsheimer im Jahr 2024, "argumentierten, dass eine Osterweiterung der Nato irgendwann zu einem ernsthaften Konflikt führen würde. Ihnen stand eine einflussreiche Gruppe liberaler Außenpolitiker gegenüber, die glaubten, die Nato könne nach Osten in Richtung Russland ausgedehnt werden, ohne dass dies zu Problemen führen würde."
Dieses liberale Überlegenheitsgefühl einer unipolar-westlichen Hegemonie dürfte maßgeblich zum Scheitern der Verhandlungen von 2022 beigetragen haben. Während Mearsheimer davon ausgeht, dass Russland damals zu einem gewissen Kompromissfrieden bereit gewesen wäre [9], habe der Westen diesen aktiv hintertrieben.
Er argumentiert aus der Perspektive der realistischen Sicherheitslogik heraus, dass Russland reale, schriftlich fixierte Sicherheitsgarantien wollte, deren Kern die ukrainische Neutralität gewesen wäre.
Es ist belegt [10], dass 2022 in Istanbul über die Neutralität der Ukraine verhandelt wurde. Letztlich setzen sich, wie den Nuland-Aussagen [11] zu entnehmen ist, London, Washington und Brüssel durch. Der Deal platzte: Zentraler Knackpunkt war dabei die Frage einer neutralen Ukraine [12] und weitreichender (primär ukrainischer) Entwaffnungen als Sicherheitsgarantien [13].
Mearsheimer zufolge ist ein dauerhafter Frieden, wie 2022 greifbar, heute in weiter Ferne. Er sieht zumindest kurz- bis mittelfristig [14] nur einen temporären Waffenstillstand oder das "Einfrieren des Konflikts" (Waffenstillstand + eingefrorene Front) als realistisch an. Die Chance auf echten Frieden sei demnach "klein".
Interessanterweise korreliert jene Einordnung mit dem Aufkommen der Äußerungen Trumps nach einem "Einfrieren der Front als erster Schritt [15]" hin zu einem Frieden.
Mearsheimer würde dieser Zielrichtung eines dauerhaften Friedens widersprechen. Der Grund: Alle beteiligten Seiten sehen sich in einer existentiellen Bedrohung, was Kompromisse erschwert. Gleichzeitig ist abseits einer diplomatischen Lösung auch kein militärtechnischer Durchbruch einer der beiden Seiten zu erwarten.
Zwar ist die Ukraine am Rande ihrer Kapazitäten, doch spricht aktuell viel dafür das Blutvergießen durch europäische Hilfe künstlich zu verlängern. Damit hat sich die Lage dramatisch negativ adaptiert: eine permanente Eskalationsgefahr, massive politische Unsicherheit und das ständige Risiko erneuter Wortbrüche unterminieren die ohnehin geringen Chancen auf ein totales Ende der Feindseligkeiten.
Unter der Annahme, dass sich die USA – arbeitsteilig mit Kontinentaleuropa – zunehmend aus dem Ukraine-Konflikt herauszulösen versuchen, um sich Asien zuzuwenden, wird die These einer europäischen Rollenübernahme diskutiert. Mearsheimer warnt vor einem Alleingang, da die EU ohne starke amerikanische Beteiligung nicht über die nötigen Mittel und die strategische Tiefe verfüge.
Dabei ist der US-Querulant nicht alleine: Ausgerechnet von Wolfgang Ischinger, ehemaliger Diplomat und langjähriger Leiter der Münchner Sicherheitskonferenz (MSC), einem weltpolitischen Forum für Geopolitik und Sicherheitsfragen, gibt es Schützenhilfe. Ein europäischer Alleingang könnte "das Ende der Nato, wie wir sie kennen [16]", bedeuten, so Ischinger gegenüber Politico.
Am Ende gelingt Mearsheimer ein bemerkenswert-wichtiger Übertrag: Nicht nur Russland wird sich mit zunehmender Konfliktdauer verändern, sondern auch der Westen läuft Gefahr.
Die Eskalations- und Risikodimensionen sind immens – nicht nur militärisch konventionell, sondern auch nuklear. Die deutsche Bevölkerung ist von dem betroffen, was fragmentarisch angedeutet bleibt: Sicherheits- und Rüstungsfragen, aber insbesondere auch massive potenzielle Wirtschaftsfolgen.
Über Mearsheimer hinaus lassen sich auf Basis einer realistischen Analyse-Theorie folgende Szenarien annehmen: Statt eines raschen Friedensschlusses wird mittelfristig ein eingefrorener Status quo das Maß der Dinge sein. Mit den Nachwehen ist die Post-Kalter-Krieg-Ordnung an ihr endgültiges Ende gekommen.
Es wird eine fundamentale Neuordnung der Sicherheitsarchitektur brauchen. Mit dem Aufbau neuer Energielieferketten durch Moskau wird es einen bedeutenden Umbau der Energie- und Wirtschaftsbeziehungen innerhalb der EU geben müssen, dessen Ende – insbesondere im Hinblick auf die Konfrontation zwischen Washington und Peking – bei weitem nicht erreicht scheint.
Die Ukraine dürfte neben wirtschaftlichem Niedergang, Infrastruktur- und Personenschäden auch einen massiven Rückgang des BIP zu schultern haben. Durch die eingefrorene Struktur wird Wiederaufbau ausgebremst. Russland bleibt sanktioniert und in westlich isoliert – es mag sich eine weltweite Blockbildung abzeichnen.
Unter Einbezug einer massiven Ausweitung militärischer Risiken kann es zu einer Neubewertung der Nato, der EU und des Sicherheitsbegriffs auf dem europäischen Kontinent kommen.
Aus den Illusionen strategischer Autonomie und militaristischer Kraftmeierei könnten zeitnah Realitäten geopolitischer Rivalitäten werden, aus deren Gewaltspirale ein Entrinnen kompliziert ist. Der Nothalt der Istanbul-Verhandlungen 2022 wurde westlich vertan.
URL dieses Artikels:https://www.heise.de/-10962832
Links in diesem Artikel:[1] https://www.youtube.com/watch?v=gliR5OKPbG0&feature=youtu.be[2] https://www.berliner-zeitung.de/politik-gesellschaft/geopolitik/trump-sucht-wege-zum-ukraine-frieden-und-chinas-hilfe-im-umgang-mit-russland-li.10002765[3] https://www.n-tv.de/politik/Lawrow-wirft-Trump-Sinneswandel-im-Ukraine-Krieg-vor-article26122633.html[4] https://www.newyorker.com/news/q-and-a/john-mearsheimer-on-putins-ambitions-after-nine-months-of-war[5] https://political-science.uchicago.edu/directory/John-Mearsheimer[6] https://en.wikipedia.org/wiki/The_Tragedy_of_Great_Power_Politics[7] https://bxscience.edu/ourpages/auto/2015/12/17/46553148/Mearsheimer%20-%20Tragedy%20of%20Great%20Power%20Politics.pdf[8] https://www.globaltimes.cn/page/202402/1307492.shtml[9] https://www.dailymotion.com/video/x9jztxa[10] https://www.reuters.com/world/europe/what-happened-last-time-russia-ukraine-held-peace-talks-2025-05-12/[11] https://responsiblestatecraft.org/ukraine-russia-2669196351/[12] https://www.aljazeera.com/news/2022/3/16/russia-says-parts-of-a-ukraine-compromise-deal-are-close[13] https://www.cfr.org/report/ukraine-nato-and-war-termination[14] https://organicconsumers.org/ukraine-war-what-happens-next/[15] https://www.tagesschau.de/ausland/europa/ukraine-front-einfrieren-100.html[16] https://www.politico.com/news/2025/05/05/ischinger-europe-us-nato-ukraine-00326316
Copyright © 2025 Heise Medien
Bild: Shutterstock.com
Noch nie war Wissen so leicht zugänglich. KI kann auch neue Kompetenzen fördern, sagt die Forschung. Wie viel wollen wir selbst noch denken?
Der Begriff "De-Skilling" beschreibt den Verlust von Fähigkeiten durch übermäßige Technologienutzung. Man kennt die Bedenken, etwa wenn es um Orientierungsfähigkeit und Navigationshilfen geht.
Besonders ausgeprägt sind die Sorgen vor dem Verlust wichtiger, kritischer kognitiver Kompetenzen, wenn es um die immer häufigere Anwendung von KI geht.
Diese Sorge ist nicht neu. Bereits Sokrates warnte vor der Schrift, sie würde das Gedächtnis schwächen. Später fürchteten Ingenieure, Taschenrechner könnten den Zahlensinn abstumpfen. Der Philosoph Kwame Anthony Appiah von der New York University erklärt in einem Artikel für The Atlantic [1]:
Jede Generation musste lernen, mit ihren neu erworbenen kognitiven Prothesen zu arbeiten.
Aktuelle Forschung zeigt jedoch konkrete Risiken. Eine britische Studie mit mehreren hundert Teilnehmern, die Appiah zitiert, ergab: Jüngere Menschen, die KI häufiger für Informationssuche und Entscheidungen nutzen, schnitten schlechter bei Tests zum kritischen Denken ab. Die Quintessenz: "Use it or lose it" – wer Fähigkeiten nicht nutzt, verliert sie.
Eine MIT-Studie [2] untersuchte 54 Erwachsene beim Schreiben von Essays. Teilnehmer, die ChatGPT verwendeten, zeigten deutlich geringere kognitive Aktivität im Gehirn.
Als sie später ohne KI arbeiten mussten, konnten sie sich schlechter an ihre eigenen Texte erinnern und fühlten sich weniger verantwortlich für ihre Arbeit. Die Forscher sprechen von "kognitiver Verschuldung".
Besonders alarmierend sind Befunde aus der Medizin. Eine in The Lancet [3] veröffentlichte Studie untersuchte über 1.400 Darmspiegelungen in Polen.
Nach monatelanger KI-Unterstützung sank die Erkennungsrate von Polypen ohne KI-Hilfe um 20 Prozent – von 28,4 auf 22,4 Prozent. Dr. Marcin Romańczyk [4] von der Academy of Silesia warnt: "Dies ist die erste Studie, die einen negativen Einfluss regelmäßiger KI-Nutzung auf medizinische Fähigkeiten zeigt."
Dennoch hat KI auch positive Seiten. Eine Harvard-Studie mit Physikstudenten, die Appiah in seinem Atlantic-Artikel zitiert, kommt zum Ergebnis, dass KI-gestützte Tutoren zu besseren Lernergebnissen als traditioneller Unterricht führten. Die Studenten lernten nicht nur mehr, sondern arbeiteten auch motivierter.
KI kann Fähigkeiten "demokratisieren", lautet ein anderes Pro-Argument, das der Philosoph anführt. Für Forscher, die mit Englisch kämpfen, können Chatbots beim Verfassen wissenschaftlicher Texte helfen und sie "glätten". Auch würden komplexe Berechnungen dank KI zugänglicher werden, sodass mehr Menschen "die Mathematik machen" können.
Experten unterscheiden zwischen schädlichem "erosivem De-Skilling" und produktivem "Reskilling". Während das erste grundlegende Fähigkeiten schwächt, ermöglicht das zweite neue Kompetenzen. Programmierer, die GitHub Copilot nutzen, verbringen weniger Zeit mit Code-Erstellung, aber mehr mit dessen Prüfung - die Expertise wandert von der Komposition zur Supervision.
Britische Bildungsbehörden haben bereits reagiert. Das Department for Education veröffentlichte Leitfäden für den sicheren KI-Einsatz in Schulen [5].
Eine bundesweite deutsche Studie zeigt: Über 90 Prozent der Studierenden nutzen bereits KI-Tools [6].
Forscher der Universität von Südaustralien [7] argumentieren, dass Bildung wie bei der Einführung von Taschenrechnern reagieren muss: Die Anforderungen müssen steigen, damit KI zu einem notwendigen Werkzeug wird, statt Denkarbeit zu ersetzen.
Die größte Sorge gilt dem Philosophen Appiah das sogenannte konstitutive De-Skilling. Gemeint ist der Verlust dessen, was uns menschlich macht. Appiah warnt: "Urteilskraft, Vorstellungskraft, Empathie, das Gefühl für Bedeutung und Proportion – das sind keine Backups, sondern tägliche Übungen."
Eine Studie der EPFL [8] zeigte, dass GPT-4 in personalisierten Debatten Menschen um 81 Prozent häufiger überzeugte – wobei hier der Genauigkeit willen anzumerken ist, dass sich die Zahl der 81,2 Prozent auf den "relativen Anstieg der Odds (Wahrscheinlichkeit) für eine höhere Zustimmung nach der Debatte" bezieht.
Beunruhigend erscheint in diesem Kontext: Die KI nutzte bereits minimale persönliche Daten effektiver als menschliche Debattierer.
Die Lösung liegt nach dem Tenor, der gegenwärtig aus vielen Berichten und Stellungnahmen herauszuhören ist, nicht im Verzicht auf KI, sondern in bewusster Gestaltung der KI-Anwendungen.
Appiah betont: "Wenn es eine Fähigkeit gibt, die wir uns nicht leisten können zu verlieren, dann die Fähigkeit zu wissen, welche von ihnen zählt." Die Herausforderung bestehe also darin, KI als Werkzeug zu nutzen, ohne unsere Menschlichkeit zu verlieren.
Was er damit meint?
Verschwinden könnte das stumme, verkörperte Wissen, das unser alltägliches Unterscheidungsvermögen trägt.
Wenn Menschen lernten, Fragen so zu stellen, wie das System sie bevorzugt, und aus seinem Menü plausibler Antworten zu wählen, nähme der Schaden nicht die Form spektakulärer Fehlurteile an, sondern einer allmählichen Ausdünnung unseres Charakters: flachere Gespräche, weniger Appetit auf Mehrdeutigkeit, ein Abdriften zu automatischer Phrasierung, wo wir einst nach dem treffenden Wort suchten, die stille Ersetzung von Gewandtheit anstelle von Verständnis.
Solche Vermögen auszulagern, hieße, uns selbst auszulagern. Sie zu verlieren, veränderte nicht nur, wie wir arbeiten; es veränderte, wer wir sind.
Kwame Anthony Appiah [9]
URL dieses Artikels:https://www.heise.de/-10963205
Links in diesem Artikel:[1] https://www.theatlantic.com/ideas/archive/2025/10/ai-deskilling-automation-technology/684669/[2] https://www.sciencealert.com/does-using-artificial-intelligence-ruin-your-actual-intelligence-scientists-investigated[3] https://www.eurekalert.org/news-releases/1094223[4] https://www.eurekalert.org/news-releases/1094223[5] https://www.gov.uk/government/collections/using-ai-in-education-settings-support-materials[6] https://nachrichten.idw-online.de/2025/03/21/bundesweite-studie-mehr-als-90-der-studierenden-nutzen-ki-basierte-tools-wie-chatgpt-fuers-studium[7] https://www.sciencealert.com/does-using-artificial-intelligence-ruin-your-actual-intelligence-scientists-investigated[8] https://pmc.ncbi.nlm.nih.gov/articles/PMC12367540/[9] https://www.theatlantic.com/ideas/archive/2025/10/ai-deskilling-automation-technology/684669/
Copyright © 2025 Heise Medien
Rauch über Gaza: Israel hat gestern seine Angriffe wieder aufgenommen
(Bild: Anas-Mohammed/Shutterstock.com)
Über 100 Palästinenser sterben bei israelischen Angriffen im Gazastreifen. US-Präsident Trump sieht Waffenruhe dennoch nicht gefährdet und rechtfertigt Israels Vorgehen.
US-Präsident Donald Trump hält trotz schwerer israelischer Angriffe im Gazastreifen an der von Washington vermittelten Waffenruhe fest. Innerhalb von zwölf Stunden töteten israelische Streitkräfte nach Angaben des Gesundheitsministeriums in Gaza über 100 Palästinenser, darunter 46 Kinder, und verletzten 253 weitere Menschen.
Trump verteidigte [1] am Mittwoch Israels Vorgehen mit dem Tod eines 37-jährigen israelischen Soldaten im südlichen Gaza.
"Soweit ich weiß, haben sie einen israelischen Soldaten getötet", sagte Trump vor Journalisten an Bord der Air Force One auf dem Weg von Japan nach Südkorea. "Die Israelis haben zurückgeschlagen, und das sollten sie auch", fügte er hinzu und bezeichnete die Angriffe als "Vergeltung" für den Soldatentod.
Die Hamas bestritt jede Verantwortung für den angeblichen Angriff auf israelische Streitkräfte in Rafah und erklärte, weiterhin dem Waffenstillstandsabkommen verpflichtet zu bleiben. Nach israelischen Medienberichten sollen bewaffnete Palästinenser Soldaten mit einer Panzerabwehrrakete und Scharfschützenfeuer angegriffen haben.
"Nichts wird die Waffenruhe gefährden", bekräftigte Trump. Die Hamas sei "nur ein sehr kleiner Teil des Friedens im Nahen Osten" und müsse sich "anständig verhalten". Falls sie sich nicht "gut" verhielten, würden "ihre Leben beendet", drohte der US-Präsident.
Das israelische Militär erklärte am Mittwoch, die Gaza-Waffenruhe nach einer Serie von Angriffen auf Dutzende "Terror-Ziele" wieder in Kraft gesetzt zu haben. Dabei seien "30 Terroristen in Führungspositionen" getötet worden, hieß es ohne Belege für diese Behauptungen.
Die neuen Angriffe versetzten die palästinensische Zivilbevölkerung in Panik. Der Korrespondent des arabischen Fernsehsenders Al Jazeera, Hani Mahmoud, berichtete aus Gaza-Stadt: "Eine kurze Hoffnung auf Ruhe ist in Verzweiflung umgeschlagen. Der Himmel ist voller Kampfjets, Drohnen und Aufklärungsflugzeuge."
Die Hilfsorganisation Save the Children bezeichnete Berichte über getötete Kinder als "qualvoll". "Das darf nicht zur neuen Normalität unter einer Waffenruhe werden", sagte Ahmad Alhendawi, Regionaldirektor der Organisation für den Nahen Osten, Nordafrika und Osteuropa.
Eine dauerhafte Waffenruhe müsse "Sicherheit, Hilfe und Erholung für Kinder bedeuten, nicht weiteres Leiden".
Mouin Rabbani vom Center for Conflict and Humanitarian Studies sagte [2] gegenüber Al Jazeera, Israel habe "niemals wirklich seine Verpflichtungen" aus dem Abkommen erfüllt, einschließlich des Rückzugs auf die vereinbarte Linie in Gaza oder der Zulassung der vereinbarten Hilfsmenge.
Rabbani zufolge versucht Israel bewusst, ein Waffenstillstandsabkommen zu untergraben, in das es von den USA widerwillig hineingedrängt wurde. Rob Geist Pinfold von King's College London bezeichnete die Waffenruhe als "von Tag eins an fragil", da beide Seiten dem Abkommen unter erheblichem US-Druck zugestimmt hätten.
Da Israel noch etwa 50 Prozent des Gazastreifens kontrolliere, könne dies "für viele Palästinenser in Gaza nicht wie eine echte Waffenruhe aussehen, sondern eher wie eine unbestimmte, langwierige Besetzung ohne absehbares Ende", erklärte Pinfold.
Seit Beginn der Waffenruhe am 10. Oktober kam es wiederholt zu tödlichen Zwischenfällen. Nach Angaben der Hamas-kontrollierten Gesundheitsbehörde wurden dabei bereits mehr als 90 Palästinenser getötet. Vor gut einer Woche starben zudem zwei israelische Soldaten bei einem Angriff mit einer Panzerfaust.
URL dieses Artikels:https://www.heise.de/-10962996
Links in diesem Artikel:[1] https://www.tagesschau.de/ausland/asien/israel-gazastreifen-waffenruhe-104.html[2] https://www.aljazeera.com/news/2025/10/29/israel-kills-over-100-palestinians-in-gaza-as-trump-insists-truce-holds
Copyright © 2025 Heise Medien
(Bild: Shutterstock/Alexander Supertramp)
Mit ADL stellt Eclipse eine einfache, offene und standardisierte Sprache für die Beschreibung des Aufbaus und Verhaltens von KI-Agentensystemen vor.
Die Eclipse Foundation hat eine offene, dezidierte Beschreibungssprache für die Planung, die Definition von Verhaltensmustern und die Steuerung von KI-Agentensystemen vorgestellt. Agent Definition Language (ADL) beschreibt Agentensysteme in einfachen, standardisierten Kategorien und Begrifflichkeiten, die ein strukturiertes Deployment und einen geregelten Betrieb ermöglichen sollen.
Laut der Ankündigung von Eclipse ist ein solcher offener und transparenter Standard im Markt bisher nicht vorhanden, der es Unternehmen ermöglicht, hersteller- und modellunabhängige Agentensysteme einzuführen und zu unterhalten [1].
Im Konzept trennt ADL die Definition von Agentensystemen vom konkreten Prompting, wobei der Entwurf mit ADL in den Fachabteilungen geschieht, während im Idealfall ein Compiler die Umsetzung automatisiert in Prompts vollzieht und für die Lösung der Aufgabe benötigte Tools einbindet.
Begrifflich gliedert die Sprache die Agenten in Use Cases ein, innerhalb derer sich verschiedene Szenarien ereignen. Hier agieren Nutzer mit Agenten oder Agenten untereinander. Die formalen Definitionen umfassen dabei:
Im Code:
### UseCase: password_reset
#### Description
Customer has forgotten their password and needs to reset it.
#### Steps
- Ask the customer for their registered email address.
- Send a password reset link to the provided email address.
#### Solution
Guide the customer through the password reset process defined on the webpage https://www.example.com/reset-password.
#### Fallback Solution
If the customer cannot access their email, escalate the issue to a higher tier of support.
#### Examples
- I forgot my password.Weitere Elemente sind beispielsweise Flow Options, mit denen Anwenderinnen und Anwender Entscheidungsbäume implementieren:
[option 1] command[option 2] command 2
Zum Ausprobieren bietet Eclipse einen Playground [2], in dem bereits ein erster Use Case "Automobile Example" hinterlegt ist. Tiefergehende Infos finden sich in der technischen Doku [3].
ADL bettet sich als Konzept in die Eclipse-Agentenplattform Language Model Operating System (LMOS), die zwei weitere Komponenten enthält: das ARC Agent Framework und die LMOS-Plattform. ARC bietet ein JVM-natives Framework [4] mit Kotlin-Laufzeitumgebung zum Entwickeln, Testen und Erweitern von KI-Agenten mit visueller Schnittstelle. Diese hat ADL bereits implementiert.
Die LMOS-Plattform befindet sich noch im Alphastadium [5] und soll als offene Orchestrierungsschicht für die Infrastruktur dienen und basiert auf den Open-Source-Tools aus dem Ökosystem der CNCF (Cloud Native Computing Foundation). LMOS ist bereits bei der Telekom als Basis für den Chatbot "Frag Magenta" im Einsatz [6].
URL dieses Artikels:
https://www.heise.de/-10962462
Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/Kurz-erklaert-Das-steckt-hinter-dem-Modewort-KI-Agenten-10508712.html
[2] https://adl.arcframework.dev/#/usecases
[3] https://eclipse.dev/lmos/docs/arc/adl/adl_technical/
[4] https://eclipse.dev/lmos/arc2/index.html
[5] https://eclipse.dev/lmos/docs/category/lmos-platform/
[6] https://www.telekom.com/de/konzern/details/frag-magenta-bester-chatbot-der-branche-1093544
[7] https://clc-conference.eu/programm.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_vo_clc.empfehlung-ho.link.link
[8] https://clc-conference.eu/?wt_mc=intern.academy.dpunkt.konf_dpunkt_vo_clc.empfehlung-ho.link.link
[9] mailto:who@heise.de
Copyright © 2025 Heise Medien
(Bild: heise medien)
Red Hat verteilt künftig Nvidias CUDA-Toolkit direkt über seine Plattformen. Das soll die Bereitstellung GPU-beschleunigter KI-Anwendungen vereinfachen.
Red Hat und Nvidia haben eine erweiterte Partnerschaft angekündigt, die das CUDA-Toolkit direkt in Red Hats Produktportfolio integriert. Entwickler können künftig über die offiziellen Repositories von Red Hat Enterprise Linux (RHEL), OpenShift und Red Hat AI auf die essenziellen Werkzeuge für GPU-beschleunigte Anwendungen zugreifen. Das soll die Installation vereinfachen und Abhängigkeiten automatisch auflösen.
Die Integration adressiert eine zentrale Herausforderung beim Einsatz von KI-Systemen in Unternehmensumgebungen: die operative Komplexität beim Zusammenspiel verschiedener Komponenten. Entwickler müssen bislang einigen Aufwand betreiben, um kompatible Treiber zu identifizieren, Abhängigkeiten zu managen und Workloads zuverlässig auf unterschiedlichen Systemen zum Laufen zu bringen. Durch die direkte Distribution über Red Hats Plattformen entfällt dieser Integrationsaufwand weitgehend.
Das CUDA-Toolkit umfasst Compiler, Bibliotheken und Entwicklerwerkzeuge für die Programmierung auf Nvidia-GPUs. Die Bereitstellung erfolgt nun über einen einheitlichen, getesteten Software-Stack, der laut Red Hat eine konsistente Umgebung für KI-Workloads bietet – unabhängig davon, ob diese lokal, in Public Clouds oder am Edge betrieben werden. Dieser Ansatz entspricht Red Hats bisheriger Hybrid-Cloud-Strategie.
Red Hat [1] betont den Open-Source-Charakter der Zusammenarbeit. Das Unternehmen positioniert sich als Brücke zwischen der Open-Hybrid-Cloud und Nvidias KI-Plattform, ohne dabei ein geschlossenes Ökosystem aufzubauen. Die Integration soll Unternehmen die Wahlfreiheit bei Tools und Technologien erhalten, während gleichzeitig eine stabile und sichere Plattform bereitgestellt wird.
Details zur Verfügbarkeit und zum genauen Zeitplan der Integration nannte Red Hat in der Ankündigung [2] nicht.
URL dieses Artikels:
https://www.heise.de/-10962655
Links in diesem Artikel:
[1] https://www.heise.de/thema/Red-Hat
[2] https://www.redhat.com/en/blog/red-hat-distribute-nvidia-cuda-across-red-hat-ai-rhel-and-openshift
[3] https://www.heise.de/ix
[4] mailto:fo@heise.de
Copyright © 2025 Heise Medien
(Bild: Andrii Yalanskyi/Shutterstock.com)
Systematisches Denken schlägt Tools: Warum ich seit Jahren auf den Einsatz eines Debuggers verzichte und trotzdem die Fehler finde.
Ich benutze seit vielen Jahren keinen Debugger mehr. Stattdessen füge ich console.log oder fmt.Println an den Stellen in meinen Code ein, wo ich es für sinnvoll erachte. Dafür werde ich oft belächelt und gelegentlich kritisiert, weil das vermeintlich kein "richtiges" Fehlersuchen wäre.
Ich habe jedoch meine Gründe, und die sind – aus meiner Sicht – durchaus gut. Am Ende des Tages bin nämlich oft ich derjenige, der gefragt oder gerufen wird, wenn anderen Entwicklern (trotz Debugger) die Ideen ausgehen. Und ich finde den Fehler dann in der Regel nach einer Weile. Nicht weil ich keinen Debugger benutze, sondern weil letztlich die Methodik entscheidet und nicht das Tool.
Fangen wir damit an, was mir vorgeworfen wird. Da heißt es oft:
"Ach, du benutzt console.log? Wie niedlich!"
Oder:
"Das ist doch kein richtiges Debugging!"
Oder:
"Den Typen sollte man niemals wichtigen Code schreiben lassen, das ist kein richtiger Entwickler, der benutzt ja noch nicht mal einen Debugger!"
Die implizite Annahme dahinter ist immer: Ein guter Entwickler muss einen Debugger beherrschen. Interessanterweise ist das allerdings stark von der Community abhängig, in der man sich bewegt. In der Go- und in der JavaScript-Community beispielsweise sind fmt.Println beziehungsweise console.log völlig normal und akzeptiert. Niemand guckt einen da schräg an. In der Java- oder C#-Welt hingegen wird der Einsatz eines Debuggers oft als Pflicht angesehen. Das zeigt bereits: Es gibt nicht die eine richtige Art zu debuggen. Das ist stark davon abhängig, in welchem Ökosystem man sich bewegt.
Warum benutze ich nun keinen Debugger? Dafür habe ich vier konkrete Gründe. Erstens: Der Set-up-Aufwand. Einen Debugger zu starten, zu attachen und zu konfigurieren kann je nach Set-up des Projekts (auf das man eventuell gar keinen Einfluss hat) sehr aufwendig sein. Besonders in fremden Projekten, wo man nicht genau weiß, wie die Infrastruktur aufgebaut ist, verliert man unter Umständen sehr schnell viel Zeit. Zeit, die man eigentlich für etwas anderes bräuchte, nämlich um den Fehler zu finden. Stattdessen konfiguriert man zunächst eine halbe Stunde lang Tools und ärgert sich, dass es nicht so funktioniert, wie man sich das vorstellt.
Zweitens: Die fehlende Übung. Wenn man viele Tests schreibt – und das sollte man tun –, erübrigen sich die einfachen Fälle. Die landen gar nicht erst auf dem Tisch, weil die Tests sie bereits abfangen. Was übrig bleibt, sind die schwierigen Fälle. Die gibt es jedoch gar nicht so oft. Vielleicht alle paar Wochen einmal, vielleicht alle paar Monate. Deswegen fehlt dann die Übung mit dem Debugger. Man ist aus der Routine raus, und wenn man ihn dann braucht, steht man da und muss sich erst wieder zurechtfinden. Man weiß dann oft gar nicht mehr so richtig, wie das funktioniert, wo welche Buttons sind, und so weiter. Genau das verstärkt natürlich auch den ersten Punkt, weil man wieder von vorn anfängt, um herauszufinden, wie man ihn überhaupt startet und attached.
Drittens: Die Timing-Verzerrung. Das ist für mich ein wichtiger Punkt, der viel zu oft ignoriert wird. Ein Debugger und dort insbesondere der Einsatz von Breakpoints verzerren nämlich das Zeitverhalten der Anwendung dramatisch. Ich habe vor vielen Jahren einmal in einem Projekt mit hunderten parallel laufenden Threads gearbeitet. Da war es praktisch unmöglich, mit einem Debugger etwas ausfindig zu machen. Warum? Weil jeder Breakpoint zum einen das Zeitverhalten komplett verändert hat. Hielt man einen Thread an, liefen die anderen weiter, und auf einmal hatte man ein völlig anderes Timing, und dann war der Fehler unter Umständen plötzlich weg. Oder es tauchten neue Fehler auf. Zum anderen hatte man bei zwei Läufen sowieso nie denselben Stand, weil Threads nebenläufig sind und das Scheduling von ihnen nicht deterministisch ist. Das heißt, hier kam es sehr darauf an, nachvollziehen zu können, welcher Thread etwas macht, was dann bei einem anderen Thread etwas verursacht. Das geht nur, indem man Code liest, sich Dinge notiert und vor allem, indem man sehr viel über den Code nachdenkt. Ein Debugger hilft einem da tatsächlich überhaupt nicht weiter, im Gegenteil: Er macht die Sache eigentlich nur schlimmer.
Viertens – und das ist aus meiner Sicht der wichtigste Punkt überhaupt: Der Debugger nimmt einem nicht das Denken ab. Die eigentliche Arbeit ist nämlich vor allem das Nachvollziehen und Nachdenken darüber, wie es zu einer bestimmten Situation überhaupt gekommen ist. Das kann ein Debugger naturgemäß nicht. Er ist nur ein Werkzeug. Er zeigt, was passiert ist, aber nicht warum. Man sieht die Werte in den Variablen, man sieht, welche Funktionen gerade aufgerufen werden, aber man versteht nicht die Kausalkette, wie es überhaupt dazu gekommen ist. Genau dieses Warum ist die Arbeit, die man als Entwicklerin oder als Entwickler leisten muss. Und das ist leider das, was vielen häufig schwerfällt.
Genau das ist der springende Punkt: Was wirklich zählt, ist systematisches Denken. Die Kernkompetenz beim Debuggen ist nämlich nicht, einen Debugger bedienen zu können. Die Kernkompetenz ist, Fehler systematisch eingrenzen zu können. Durch logisches Schlussfolgern die Zahl der Optionen, die als Ursache infrage kommen, immer weiter zu reduzieren. Und genau das macht der Mensch, nicht das Tool. Der Debugger kann einem zeigen, wie der Stand der Dinge ist, aber er kann einem nicht sagen, was sein sollte und warum es anders ist als erwartet.
Ich möchte dazu ein konkretes Beispiel geben, das zeigt, was ich meine. Vor einer Weile hatten wir bei einem Kunden ein Problem mit asynchronem Rendering in einer React-App. Keiner von uns wusste, dass an besagter Stelle etwas Asynchrones passierte; es war uns einfach nicht bewusst. Nachdem dann zwei Entwickler daran schon mehrere Stunden gesucht hatten, haben sie mich gefragt, ob ich einmal mit nach dem Fehler schauen könne. Beide hatten mit dem Debugger gearbeitet, hatten sich die Komponenten-Hierarchie angeschaut, hatten sich die Props angeschaut, hatten alles Mögliche gemacht. Ich habe es durch das Verwenden von console.log, das Beobachten des Verhaltens, Lesen des Codes und Nachdenken geschafft, den Fehler nach und nach immer weiter einzugrenzen. Und nach einer knappen Stunde blieb nur noch eine Möglichkeit als Ursache übrig: Diese und jene Zeile musste anscheinend asynchron verarbeitet werden, es war die einzig mögliche Erklärung, wie es zu dem gezeigten Verhalten kommen konnte.
Dann haben wir in die Dokumentation von React geschaut, und genau so war es dann auch. Natürlich hätte man das auch am Anfang nachschauen können, nur kam niemand auf die Idee, ausgerechnet an dieser Stelle zu suchen. Die Lektion dabei ist: Der Debugger hat das Problem offensichtlich nicht gelöst. Sondern: Das systematische Eingrenzen hat es am Ende gebracht. Eben die Frage:
"Wo könnte das Problem liegen?"
und dann Schritt für Schritt, nach und nach, alle Möglichkeiten bis auf eine ausschließen.
Wenn wir damit jetzt zu der Erkenntnis gekommen sind, dass systematisches Denken wichtiger ist als das Tool, stellt sich natürlich die Frage: Was ist dann an console.log oder fmt.Println eigentlich vermeintlich so falsch? Oder andersherum gefragt: Warum funktioniert das so gut? Dafür gibt es tatsächlich drei ausgezeichnete Gründe.
Erstens: das Observability-Mindset. Im Grunde macht man nämlich Observability im Kleinen. In Production hat man oft auch keinen Debugger – nur Logging, Tracing, Metrics. Wer gewohnt ist, durch gezieltes Logging zu debuggen, denkt automatisch in die Richtung:
"Was muss ich wissen, um das System zu verstehen?"
Man überlegt sich: An welcher Stelle brauche ich welche Informationen? Was ist relevant? Was hilft mir weiter? Das ist eine wertvolle Fähigkeit, gerade für moderne verteilte Systeme, bei denen man nicht mehr mit einem Debugger arbeiten kann, weil die einzelnen Services auf verschiedenen Maschinen laufen.
Zweitens: Reproduzierbarkeit und Dokumentation. Mit Logs hat man eine dauerhafte Spur. Man kann den Code laufen lassen, die Ausgabe analysieren, den Code erneut laufen lassen, die Ausgaben vergleichen. Man sieht:
"Ah, beim ersten Mal war der Wert hier 42, beim zweiten Mal ist er aber 43, da muss irgendwo ein Zähler sein, der nicht zurückgesetzt wird."
Mit einem Debugger ist das oft sehr viel flüchtiger. Man klickt sich durch, sieht etwas, aber hat es nicht festgehalten. Beim nächsten Durchlauf muss man sich dann wieder durchklicken, und wenn man nicht aufgepasst hat, weiß man gar nicht mehr so genau, was man beim letzten Mal eigentlich gesehen hat.
Drittens: Bewusstes Denken wird erzwungen. Man muss sich überlegen: Was will ich eigentlich wissen? Wo könnte das Problem liegen? Welche Variablen sind relevant? An welcher Stelle im Code muss ich schauen? All das fördert systematisches Denken. Gerade für weniger erfahrene Entwicklerinnen und Entwickler kann ein Debugger dann nämlich schnell ein schlechtes Hilfsmittel werden: Sie setzen dann einen Breakpoint, schauen sich Variablen an, klicken sich durch den Call-Stack, verstehen aber nicht den größeren Zusammenhang. Sie sehen zwar Daten, aber sie verstehen nicht, was sie bedeuten. Durch bewusstes Logging muss man sich diese Fragen aber stellen. Man muss sich überlegen, was relevant ist. Das ist eine wertvolle Übung.
Jetzt kommt eine Beobachtung aus der Praxis, die das Ganze noch unterstreicht: Ich bin, wie eingangs bereits erwähnt, in Kundenprojekten oft derjenige, der gefragt wird, wenn anderen die Ideen ausgehen. Die Leute kommen zu mir und sagen:
"Golo, wir suchen jetzt seit Tagen nach der Ursache für diesen Bug, wir finden ihn einfach nicht, kannst du mal draufschauen?"
Trotz Debugger finden sie den Fehler nicht. Ich finde ihn dann über kurz oder lang – ohne Debugger. Warum? Weil die Methodik entscheidet, nicht das Tool. Genau das können leider viel zu viele Entwicklerinnen und Entwickler nicht allzu gut: systematisch eingrenzen und logisch schlussfolgern. Die verlassen sich darauf, dass der Debugger ihnen die Antwort quasi auf dem Silbertablett präsentieren wird. So funktioniert das jedoch nicht. Der Debugger ist nur ein Werkzeug, das einem Daten zeigt. Die Interpretation dessen, also das Verstehen, das logische Schlussfolgern, das muss man selbst machen.
Ich will es aber auch nicht so darstellen, als wären Debugger per se schlecht oder als ob man sie nie benutzen sollte. Das wäre unseriös, und das wäre auch falsch. Es gibt durchaus Situationen, in denen ein Debugger legitim und sinnvoll ist. Zum Beispiel beim Verstehen von fremdem Code, den man noch gar nicht kennt. Man steigt in ein neues Projekt ein, und da kann ein Debugger natürlich helfen, schnell einen Überblick zu bekommen, im Sinne von:
"Ah, diese Funktion ruft jene auf, die ruft wiederum diese andere auf."
Oder bei sehr komplexen Objektgraphen, die man visualisieren möchte. Wenn man eine verschachtelte Datenstruktur hat, die man sich in einer schönen Baumansicht anschauen will, ist ein Debugger praktisch. Aber auch hier gilt: Der Debugger ersetzt nicht das Denken. Er ist ein Hilfsmittel, mehr nicht. Es geht mir also, um das noch einmal zu betonen, nicht darum, Debugger an sich zu verteufeln. Sondern es geht mir darum, zu sagen: Bloß weil jemand keinen Debugger verwendet, macht das sie oder ihn nicht zu einem schlechten Developer. Unter Umständen bewirkt es das genaue Gegenteil.
Das heißt: Nicht das Tool macht gute Developer aus, sondern die Methodik macht es. Systematisches Eingrenzen, logisches Denken, die Fähigkeit, eine Kausalkette nachzuvollziehen – das sind die Fähigkeiten, die zählen. Nur weil jemand keinen Debugger benutzt, ist sie oder er nicht schlecht oder falsch aufgehoben in der Entwicklung. Im Gegenteil: Wer ohne Debugger auskommt, hat oft die bessere Methodik, weil sie oder er sich nicht auf ein Tool verlässt, sondern auf das eigene Denken.
Mein Rat daher: Probieren Sie es einmal aus. Versuchen Sie beim nächsten Problem einmal, bewusst ohne Debugger auszukommen. Setzen Sie bewusst console.log oder fmt.Println ein, grenzen Sie systematisch ein und denken Sie nach. Stellen Sie sich die Frage: Was könnte die Ursache sein? Wie kann ich das überprüfen? Was schließe ich damit aus? Das wird vermutlich anstrengend, weil man es vielleicht nicht so geübt ist, so zu arbeiten. Je öfter man das macht, desto überraschter wird man aber sein, wie gut das funktioniert. Und irgendwann wird man merken, dass man auf einmal viel bewusster über seinen Code nachdenkt.
URL dieses Artikels:
https://www.heise.de/-10900103
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] mailto:rme@ix.de
Copyright © 2025 Heise Medien
Hardware und Betriebssysteme werden immer komplexer und erfordern ein immer größeres Wissen bei der System- und Netzwerkadministration. Der damit einhergehenden wachsenden Komplexität bei Problemen und Systemausfällen begegnen Admins mit immer neuen Werkzeugen.
Spezielle, auf die Problemlokalisierung und Fehlerbeseitigung in heterogenen IT-Umgebungen fokussierte Live-Systeme können Hilfestellung leisten. Wir stellen fünf dieser Werkzeug-Distributionen vor.
Für 8,49 Euro (anstelle der unverbindlichen Preisempfehlung von 10,99 Euro) wird bei Amazon eine LED-Taschenlampe angeboten, die laut Hersteller eine Helligkeit von bis zu 2.000 Lumen liefert und damit deutlich über den typischen Alltagswerten liegt soll – so der Wert stimmt. Wir vermuten eine deutlich geringere Helligkeit.
Der Lichtstrahl lässt sich laut Angaben stufenlos zwischen fokussiertem Punktlicht und breiter Ausleuchtung einstellen, ergänzt durch vier Modi: High, Low, Strobe und SOS.
Im Inneren arbeitet ein integrierter 1.800-mAh-Lithiumakku, so der Hersteller, der bei moderater Nutzung bis zu 16 Stunden durchhalten soll. Aufgeladen wird direkt per USB-C-Kabel, das im Lieferumfang enthalten ist. Die Lampe besteht aus einer Aluminiumlegierung, die laut Hersteller stoß- und verschleißfest gefertigt ist. Das geringe Gewicht sowie die kompakte Bauform erleichtern das Mitführen in Jacken- oder Rucksacktaschen.
Mit einer Bewertung von 4,6 von 5 Sternen bei über 29.368 Rezensionen sticht das Modell im Amazon-Sortiment sichtbar hervor. Auch mehr als 5.000 Bestellungen allein im vergangenen Monat deuten auf eine große Nachfrage hin. Die Nutzungsmöglichkeiten reichen dabei von alltäglichen Beleuchtungsaufgaben über Stromausfälle bis hin zu Freizeitaktivitäten wie Camping, Wandern oder Nachtspaziergänge. Zu beachten bleibt: Herstellerangaben wie maximale Laufzeit oder Wasserdichtigkeit werden nicht durch unabhängige Tests untermauert und sollten als Richtwerte verstanden werden. Auch die höchste Leuchtstufe dürfte den Akku schneller beanspruchen und Wärmeentwicklung verursachen. Trotzdem spricht die Beliebtheit für die Taschenlampe, auch wenn die eine oder andere Herstellerangabe übertrieben anmutet.
Unterm Strich bietet die Blukar-Taschenlampe zu diesem Preis eine breite Ausstattung mit starker Leuchtkraft und praktischer Wiederaufladbarkeit. Das befristete Angebot für 8,49 Euro macht sie zu einer Option für alle, die eine zuverlässige und vielseitige Handlampe bei einem kleinen Budget suchen, ohne dabei auf moderne Funktionen zu verzichten. Sie steht aktuell auf Platz 2 der Taschenlampen-Charts .
Reklame
Blukar LED Taschenlampe Aufladbar, Superhelle Zoombare 2000 Lumen Mini Torch mit 4 Lichtmodi und Langer Betriebsdauer, Wasserdichte Handlampe für Camping, Wandern, Outdoor, Notfäll
Zum AngebotDieser Artikel enthält sogenannte Affiliate-Links. Bei einem Kauf der Produkte über diese Links erhält Golem.de eine kleine Provision. Dies ändert nichts am Preis der Artikel.
Nvidia erreicht als erstes Unternehmen einen Börsenwert von fünf Billionen US-Dollar. Diese Entwicklung ist auf die Schlüsselrolle des Unternehmens bei der Entwicklung von KI-Modellen zurückzuführen. Der Wert der Nvidia-Aktie stieg im frühen US-Handel auf 211 US-Dollar. Das Unternehmen erreichte damit eine Marktkapitalisierung von etwa 5,05 Billionen US-Dollar.
Nvidia-Chips werden weltweit für das Training von großen Sprachmodellen (Large Language Models) und das Ausführen von KI-Anwendungen eingesetzt. Zu den Kunden des Unternehmens gehören Firmen wie Oracle, OpenAI, Meta und Google.
Die führende Rolle von Nvidia verschaffte dem Unternehmen ein explosives Wachstum, und Anleger gehen davon aus, dass es diese auch in Zukunft gegen Konkurrenten verteidigen kann.
Firmenchef Jensen Huang konnte zuletzt ein gutes Verhältnis zur Trump-Regierung aufbauen und kündigte an, eine Chipfabrik in den USA bauen zu wollen. Huang konnte den US-Präsidenten außerdem von der Ausnahmerolle Nvidias bei der Fertigung von Halbleitern überzeugen.
Trump stellte zudem in Aussicht, dass er mit Chinas Staatschef Xi Jinping über die neueren Blackwell-Chips von Nvidia sprechen möchte. Zuletzt versuchte die chinesische Regierung, Unternehmen im Land daran zu hindern, Nvidia-Chips mit einer reduzierten Leistung zu verwenden, die nicht den US-Exportbeschränkungen unterliegen.
Huang argumentierte gegenüber der US-Regierung, dass ein Exportverbot von Nvidias leistungsstärkeren Systemen dazu führen könnte, dass sich am Ende eine starke Konkurrenz für US-amerikanische Technik in China entwickeln könnte.
Mit dem nun an der Börse erreichten Rekordwert festigt Nvidia seine Stellung als wertvollstes Unternehmen – mit großem Abstand zu anderen Tech-Unternehmen. Die Nvidia folgenden Unternehmen Apple und Microsoft erreichen jeweils eine Marktkapitalisierung von rund vier Billionen US-Dollar.
