Anmelden
(Bild: The Groove Thing)
Ein Vibrator aus einer Kickstarter-Kampagne verspricht, Musik als körperliche Empfindung zu übertragen. Dabei sollen einzelne Instrumente wahrnehmbar sein.
Ein Vibrator, der Musik nicht nur rhythmisch begleitet, sondern deren akustische Struktur als körperliche Empfindung übertragen soll: Mit diesem Anspruch ist ein neues Gerät auf Kickstarter angetreten [1] – und auf große Resonanz gestoßen. Das System kombiniert einen Bluetooth-Lautsprecher mit einem externen Resonator, an den unterschiedliche vibrierende Aufsätze angeschlossen werden können. Diese werden in den Körper eingeführt, um Musik auf eine neue Art zu erleben.
Vibratoren, die auf Musik reagieren, sind allerdings keine Neuheit. In der Praxis beschränkt sich diese Funktion jedoch meist auf einfache Korrelationen: lauter gleich stärker, schneller gleich intensiver. Eine feine Abbildung von Musik ist allerdings neu.
Laut der Kampagnenseite von Groove Thing übersetzt das System Musik nicht nur in einfache Vibrationsmuster, sondern soll die komplette Audio-Waveform als körperliche Empfindung wiedergeben, sodass angeblich unterschiedliche Noten, Instrumente und Tonhöhen spürbar werden. Dazu koppelt man eine Audioquelle per Bluetooth an den integrierten Lautsprecher; ein als patentiert beworbenes Signalverarbeitungsverfahren überträgt die Musik in Echtzeit in vibrierende Signale, die über einen internen Resonator fühlbar werden.
Auch jenseits des Sextoy-Bereichs ist das Interesse an Produkten, die Musik oder Geräusche physisch spürbar machen, in den vergangenen Jahren stetig gewachsen. Das taktile System des kanadischen Herstellers SUBPAC [2] etwa wandelt tiefe Audiofrequenzen aus der Musik in körperliche Vibrationen um, indem haptische Wandler die Bass-Informationen direkt auf Rücken oder Oberkörper übertragen. Die Geräte decken typischerweise einen Frequenzbereich von etwa 1 bis 200 Hz ab. Erhältlich sind sie als tragbare Weste oder als Sitzlösung und werden von Musikschaffenden sowie im Gaming- und VR-Bereich zur intensiveren Basswahrnehmung genutzt.
Seit 2020 ist zudem der in Deutschland entwickelte und gefertigte Feelbelt auf dem Markt, der ebenfalls aus einer Kickstarter-Kampagne hervorgegangen ist. Dabei handelt es sich um einen tragbaren Gürtel [3], der ähnlich wie SUBPAC arbeitet, jedoch das gesamte hörbare Frequenzspektrum von etwa 10 bis 20 000 Hz in haptische Impulse übersetzen soll. Im Gürtel sind zehn unabhängig voneinander arbeitende Aktuatoren verbaut, um unterschiedliche Tonhöhen gleichzeitig als Vibrationen darzustellen. Die Signalverarbeitung übernimmt ein ARM-Dual-Core-Prozessor mit integrierter DSP-Einheit.
Ob das neue Gerät seine technischen Versprechen tatsächlich einlösen kann und ob sich ein musikzentrierter Nutzungskontext beim Masturbieren etabliert, bleibt offen. Das Magazin Wired konnte ein frühes Prototypgerät testen [5] und zeigte sich nur mäßig beeindruckt: Der Prototyp wird als klobig beschrieben, die Erfahrung als unterdurchschnittlich. Kritisiert wurden zudem laute Motorgeräusche und Vibrationen, die als wenig angenehm empfunden wurden.
Laut Wired habe der Hersteller mehrfach betont, dass das Gerät nicht primär auf sexuelle Erregung oder Orgasmen ausgelegt sei, sondern auf das Hören von Musik und insbesondere darauf, Bass und Percussion körperlich zu spüren. Auf der sehr professionell gestalteten Kickstarter-Seite werden solche Einschränkungen allerdings nicht thematisiert. Dort heißt es stattdessen, das Gerät sei bereits erfolgreich in „170 holes“ getestet worden. Die gezeigten Videos enthusiastischer Nutzer besitzen dabei zumindest einen hohen Unterhaltungswert.
URL dieses Artikels:
https://www.heise.de/-11159037
Links in diesem Artikel:
[1] https://www.kickstarter.com/projects/groove-thing/the-worlds-first-internal-music-player/creator
[2] https://subpac.com/what-is-the-SUBPAC/
[3] https://feelbelt.de/de/
[4] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[5] https://www.wired.com/story/the-groove-thing-is-a-bluetooth-speaker-and-vibrator-combo-because-why-not/?utm_source=chatgpt.com
[6] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[7] mailto:mch@make-magazin.de
Copyright © 2026 Heise Medien
(Bild: Sony // Raspberry Pi Foundation)
Ein Raspberry Pi Pico als Modchip greift direkt in den Bootprozess der PS3 ein. Ein unpatchbarer Exploit für CFW.
Die PS3-Modding-Szene hält den Atem an: Ein Team um Modder Modyfiktor hat Custom-Firmware [1] auf Playstation-3-Konsolen der Modelle Super Slim & Slim mit NOR-Flash zum Laufen gebracht. Das galt bisher als unmöglich. Und natürlich kam dabei Hardware zum Einsatz, die Makern gut bekannt ist.
Die Modder haben einen Raspberry Pi Pico mit RP2040 direkt an die Hauptplatine der Konsole angeschlossen. Der Mikrocontroller fungiert dabei als eine Art Modchip und injiziert bei jedem Start einen Payload direkt in den Arbeitsspeicher der PS3. Entscheidend ist: Es handelt sich nicht um einen Software-Exploit auf Betriebssystemebene, sondern um einen hardwarebasierten Eingriff in den Bootprozess und gilt daher als unpatchbar.
(Bild: Modyfikator [2])
HEN (Homebrew Enabler) ist seit Jahren der Standardweg, um auf neueren PS3-Modellen überhaupt Homebrew auszuführen. Technisch handelt es sich dabei um einen Software-Exploit, der nach jedem Start manuell aktiviert werden muss. HEN verschafft Zugriff auf Modding-Funktionen wie das Starten von Homebrew-Anwendungen, Backup-Managern oder das Patchen einzelner Systemfunktionen im laufenden Betrieb. Im Gegensatz zu echter Custom Firmware läuft dabei aber weiterhin Sonys originale Firmware, die nur temporär im RAM modifiziert wird. Das bringt Einschränkungen mit sich: Kein direkter Zugriff auf Low-Level-Funktionen und stark begrenzte Hardwarekontrolle. Für den Alltag vieler Nutzer war HEN ein brauchbarer Kompromiss: Stabil, relativ einfach zu installieren und ohne Löteisen. Für tiefere Eingriffe blieb es jedoch immer eine Notlösung und genau an dieser Stelle setzt der neue Pi-Pico-Ansatz an.
Diese neue Modding-Methode eröffnet Möglichkeiten, die unter HEN schlicht nicht erreichbar sind. Besonders erwähnt wird die Rückkehr von OtherOS: Linux lässt sich wieder nativ auf der PS3 betreiben, eine Funktion, die Sony 2010 offiziell entfernt hatte. Auch echtes Hardware-Overclocking wird möglich. Im gezeigten Setup läuft der RSX-Grafikchip mit 850 MHz und bleibt dabei bei rund 55 Grad Celsius stabil. Solche Eingriffe sind mit HEN nicht realisierbar. Hinzu kommt die Möglichkeit, PS2-ISOs direkt abzuspielen.
(Bild: Modyfikator [3])
Maker, die sowieso schon einen Pi Pico auf dem Basteltisch liegen haben, können ihre PS3-Konsolen aber noch nicht zum Zittern bringen. Bisher wurde nämlich noch keine genaue Anleitung veröffentlicht. Die soll aber folgen. Die grundlegende Machbarkeit ist bereits belegt. Für Maker zeigt das Projekt mal wieder eindrucksvoll, wie viel Potenzial in kleinen Mikrocontrollern steckt.
Wem es jetzt in den Fingern juckt, seine Konsolen zu modden, kann in unserem Artikel nachlesen, wie man Linux auf einer Playstation 4 installieren kann [4].
URL dieses Artikels:
https://www.heise.de/-11157091
Links in diesem Artikel:
[1] https://www.reddit.com/r/PS3/comments/1qji2ls/the_impossible_is_now_reality_full_cfw_on_ps3/
[2] https://www.reddit.com/r/PS3/comments/1qji2ls/the_impossible_is_now_reality_full_cfw_on_ps3/
[3] https://www.reddit.com/r/PS3/comments/1qji2ls/the_impossible_is_now_reality_full_cfw_on_ps3/
[4] https://www.heise.de/ratgeber/Linux-auf-der-Playstation-4-installieren-10250863.html
[5] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[6] https://www.heise.de/make
[7] mailto:das@heise.de
Copyright © 2026 Heise Medien
This is a release focussing on bug fixing, in particular regressions from the release 1.28.0.
Selected new features ✨:
Improved performance 🏎️:
Many bug fixes 🐛
This release has been made by @Alkarex, @Frenzie, @Inverle and newcomers @ciro-mota, @eveiscoull, @hackerman70000, @Hufschmidt, @johan456789, @martgnz, @mmeier86, @netsho, @neuhaus, @RobLoach, @rupakbajgain.
Full changelog:
FreshRSS transliterator_transliterate fallback (when the php-intl extension is unavailable) #8427lastUserModified database column also during mark-as-read action #8346session.cookie-lifetime #8446CURLOPT_ACCEPT_ENCODING #8376, simplepie#960, simplepie#962<template> element #8443.gitignore to ignore installed extensions #8372
(Bild: OpenWrt / Banana Pi)
Der erste eigene Router OpenWrt One des OpenWrt-Projekts läuft nun auch mit Debian. Das macht ihn zum Allzweck-Linux-System.
OpenWrt One ist der erste eigene Router des OpenWrt-Projekts. Entstanden ist er in Zusammenarbeit mit Banana Pi und Mediatek. Natürlich läuft das Router-Betriebssystem OpenWrt mit einem U-Boot-Bootloader darauf. Nun aber hat Collabora, sonst insbesondere für Office-Software bekannt, die Linux-Distribution Debian auf das Gerät portiert.
OpenWrt One hat eine aufrüstbare Hardwarebasis [1], die auf dem ARM-Prozessor MT7981B von Mediatek, auch als Filogic 820 bekannt, mit zwei Cortex-A53-Kernen basiert. Dem steht ein WLAN-Modul MT7976C zur Seite, der Wi-Fi 6 beherrscht. An Speicher kommen 256 MByte Flash hinzu, zudem ein Recovery-Bootloader in einem mittels SPI angebundenen NOR-Flashspeicher mit 16 MByte. An einen SSD-Steckplatz für NVMe-SSDs mit 30 oder 42 mm Länge haben die Entwickler ebenfalls gedacht.
Laut Blog-Beitrag bei Collabora von Sjoerd Simons [2] ist der auch nötig, um das Debian-System auf den OpenWrt One zu bringen. „Mit OpenWrt-One-Debian kannst du nun ein vollständiges Debian-System mithilfe des NVMe-Speichers des OpenWrt One installieren und laufen lassen“, erklärt Simons. Er schwärmt weiter, das „ermöglicht alles von benutzerdefinierten Diensten und Containern bis hin zu Entwicklungstools und leichtgewichtigen Server-Workloads, alles auf offener Hardware.“
Auf Github hat Simons sein Projekt [3] als Open-Source bereitgestellt. Er hebt hervor, dass mit dem vollständigen Debian auf NVMe-SSD nicht nur ein eingeschränktes Embedded-System laufe. Dadurch lassen sich die bekannten Programme zur Paketverwaltung, die gewohnten Dienste und auch Entwicklungsprozesse nutzen. Als Zweck nennt er Experimentieren, Edge-Computing, Selbsthosten von Diensten oder Entwicklungseinsatz.
Als Voraussetzung zur Installation nennt Simons einen OpenWrt One, eine NVMe-SSD im Gerät, Zugang mittels serieller Konsole (über den vorderen USB-C-Port mit 115200 Baud) und einen USB-Stick für die Installation. Der jüngste Build lässt sich [4] über einen eigenen Link herunterladen und soll auf den USB-Stick mit FAT oder FAT32-Dateisystem verfrachtet werden. Die Installation soll in zwei Teilen ablaufen, wobei im ersten Schritt der U-Boot-Bootloader ersetzt und im zweiten dann damit das System vom USB-Stick auf die SSD geflasht wird. Die Projektseite auf Github geht detaillierter auf die nötigen Schritte ein. Falls Tester wieder zurück auf OpenWrt wechseln wollen, verweist Simons dafür auf die zugehörige Anleitung des OpenWrt-Projekts [5].
URL dieses Artikels:
https://www.heise.de/-11150708
Links in diesem Artikel:
[1] https://www.heise.de/news/OpenWrt-One-Open-Source-Router-fuer-100-Euro-9962260.html
[2] https://www.collabora.com/news-and-blog/news-and-events/openwrt-one-meets-debian.html
[3] https://github.com/sjoerdsimons/openwrt-one-debian
[4] https://github.com/sjoerdsimons/openwrt-one-debian/releases/tag/latest
[5] https://openwrt.org/toh/openwrt/one#boot_into_norfull_recovery_modeflash_nand_from_usb
[6] https://www.heise.de/newsletter/anmeldung.html?id=ki-update&wt_mc=intern.red.ho.ho_nl_ki.ho.markenbanner.markenbanner
[7] mailto:dmk@heise.de
Copyright © 2026 Heise Medien
(Bild: PiSugarStudio / Youtube)
Ein tragbarer KI-Sprachassistent, der komplett ohne Cloud oder WLAN funktioniert, hat ein Maker aus Hongkong gebaut. Als Basis dazu dient ein Raspberry Pi 5.
In einer Reihe von Videos [1] erklärt Jdaie Lin detailliert, wie sein vollständig offline nutzbarer KI-Sprachassistent aufgebaut ist, und teilt mit, wie jeder Interessierte ihn nachbauen kann. Hardwareseitig kommt die Whisplay-HAT-Erweiterung zum Einsatz, die ein kompaktes 1,69-Zoll-Farbdisplay bereitstellt. Für die Stromversorgung sorgt der Akku Pi Sugar 3 mit 5000 mAh, sodass das Gerät auch längere Zeit ohne externe Stromquelle betrieben werden kann.
Um die für KI-Anwendungen erforderliche hohe Rechenleistung bereitzustellen, hat Lin die KI-Beschleunigerkarte LLM-8850 [2] integriert. Die Karte im M.2-Format stammt vom chinesischen Hersteller M5Stack und ist speziell für lokale KI-Aufgaben – darunter große Sprachmodelle (LLMs), Vision- und Audioanwendungen – auf kleinen Single-Board-Computern wie dem Raspberry Pi 5 konzipiert. Laut Lin eignet sich die LLM-8850 besonders gut für Offline-KI-Anwendungen, für die die 24 Billionen Rechenoperationen pro Sekunde (TOPS) genügen. Allerdings hat diese Leistung ihren Preis: Mit 139 US-Dollar kostet die Karte deutlich mehr als ein Raspberry Pi 5 – und sie erzeugt dabei erheblich Abwärme. Alternativen gibt es vom Raspi-Hersteller selbst (ab 112 €) [3].
(Bild: youtube.com/@PiSugarStudio)
Um die Karte ausreichend zu kühlen und einen guten Luftstrom zu gewährleisten, experimentierte Lin mit verschiedenen Aufbauvarianten. Letztlich entschied er sich dafür, die LLM-8850 auf einem Waveshare Dual M.2 HAT [4] zu montieren. Dieser Aufbau ermöglicht nicht nur eine effektive Kühlung, sondern bietet auch die Option, später eine SSD unter dem Whisplay HAT nachzurüsten.
Im Dezember 2025 stellte Lin zudem ein Upgrade des Geräts vor: Der KI-Sprachassistent erhielt eine Kamera (Raspberry Pi-Kamera v3 (ab 25,50 €) [5]) und ein schickes Gehäuse, um ihn alltagstauglich zu machen. Mit der Kamera ist nun auch Bilderkennung möglich.
Für die lokale Verarbeitung von Sprache und Antworten kommen verschiedene KI-Komponenten zum Einsatz: Von Ollama kommt ein lokales Sprachmodell, Whisper übernimmt die Sprache-zu-Text-Funktion, und Piper wandelt den Text wieder in gesprochene Sprache um (Text-to-Speech).
KI-Sprachassistenten auf Basis des Raspberry Pi sind nicht neu – ein vergleichbares Projekt [6] wurde bereits in der Make 7/23 vorgestellt, allerdings noch mit Cloud-Anbindung. Ein entscheidender Vorteil von Lins aktueller Version ist die Datensicherheit: Alle Berechnungen und Datenverarbeitungen erfolgen lokal, sodass kein Byte das Gerät verlässt, sofern der Nutzer dies nicht wünscht. So entsteht ein vollständig autarker, offline-fähiger Sprachassistent, der Datenschutz und Leistung vereint.
URL dieses Artikels:
https://www.heise.de/-11150389
Links in diesem Artikel:
[1] https://www.youtube.com/watch?v=IuTD5OMaVVU
[2] https://shop.m5stack.com/products/ai-8850-llm-accleration-m-2-module-ax8850
[3] https://preisvergleich.heise.de/raspberry-pi-ai-hat-a3593420.html?cs_id=1206858352&ccpid=hocid-hardware_hacks
[4] https://www.waveshare.com/wiki/PCIe_TO_M.2_HAT%2B
[5] https://preisvergleich.heise.de/raspberry-pi-kameramodul-v3-a2913854.html?cs_id=1206858352&ccpid=hocid-hardware_hacks
[6] https://www.heise.de/ratgeber/Raspberry-Pi-Projekt-KI-Sprachassistent-mit-eigenem-sprechenden-Avatar-bauen-9591453.html
[7] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[8] mailto:mch@make-magazin.de
Copyright © 2026 Heise Medien
This is a major release, just in time for the holidays 🎄
Selected new features ✨:
userdate:PT1H for the past hourImproved performance 🏎️:
Selected bug fixes 🐛:
Breaking changes 💥:
This release has been made by @Alkarex, @Frenzie, @Inverle, @aledeg, @andris155, @horvi28, @math-GH, @minna-xD and newcomers @Darkentia, @FollowTheWizard, @GreyChame1eon, @McFev, @jocmp, @larsks, @martinhartmann, @matthew-neavling, @pudymody, @raspo, @scharmach, @scollovati, @stag-enterprises, @vandys, @xtmd, @yzx9.
Full changelog:
userdate:PT1H for the past hour #8093\b and \B for regex search using PostgreSQL #8141~ subsequent-sibling #8154
Retry-After rules for proxies #8029, #8218data: to CSP in subscription controller #8253Retry-After #8195f.kind to ease migrations from FreshRSS versions older than 1.20.0 #8148config.custom.php during install #8033window.bcrypt object #8166chart.js v4 update #8298WordPress.com HTTP duplicates with WebSub Automattic/pushpress#16cli/health.php compatibility with OpenID Connect #8040cli/access-permissions.sh to detect the correct permission Web group such as www-data, apache, or httpexec() function for git update #8228DOMDocument::saveHTML() scrambling charset encoding in some versions of libxml2 #8296php-intl #8334<select> #8190Promise to async/await: #8182move #8214lib_rss.php with potential breaking changes for some extensions #8193,#[Deprecated] #8325--no-progress #8315This is a security-fix and bug-fix release for FreshRSS 1.27.x.
A few highlights ✨:
healthcheckframe-ancestorsThis release has been made by @Alkarex, @Frenzie, @Inverle, @aledeg, @math-GH and newcomers @beerisgood, @nykula, @horvi28, @nhirokinet, @rnkln, @scmaybee.
Full changelog:
Retry-After #7875no-cache.txt #7907.yml and SERVER_DNS example #7858overflow-wrap instead of word-wrap #7898make target to generate the translation progress #7905entry_before_update and entry_before_add hooks for extensions #7977A few highlights ✨:
429 Too Many Requests and 503 Service Unavailable, obey Retry-Afterc: for categories like c:23,34 or !c:45,56Content-Security-Policy: frame-ancestorsThis release has been made by @Alkarex, @Inverle, @the7thNightmare and newcomers @Deioces120, @Fraetor, @Tarow, @dotsam, @hilariousperson, @pR0Ps, @triatic, @tryallthethings
Full changelog:
429 Too Many Requests and 503 Service Unavailable, obey Retry-After #7760c: for categories like c:23,34 or !c:45,56 #7696s parameter of streamId #7695Content-Security-Policy: frame-ancestors #7677referrerpolicy, ping #7770clean_hash() #7813, FreshRSS/simplepie#48:newest updated to PHP 8.5-alpha and Apache 2.4.65 #7773FRESHRSS_INSTALL and FRESHRSS_USER variables #7725onbeforeunload #7554<video poster="..."> and <image> #7636<code> inside of <pre> #7797data-auto-leave-validation #7785chart.js to 4.5.0 #7752, #7816This is a bug-fix release for FreshRSS 1.26.x
A few highlights ✨:
This release has been made by @Alkarex, @Inverle and newcomers @CarelessCaution, @the7thNightmare
Full changelog:
bgcolor, text, background, link, alink, vlink #7606This is a security-focussed release for FreshRSS 1.26.x, addressing several CVEs (thanks @Inverle) 🛡
A few highlights ✨:
Notes ℹ:
This release has been made by @Alkarex, @Frenzie, @hkcomori, @loviuz, @math-GH
and newcomers @dezponia, @glyn, @Inverle, @Machou, @mikropsoft
Full changelog:
<iframe srcdoc=""> #7494, CVE-2025-32015<button formaction=""> #7506Content-Security-Policy HTTP headers to favicons #7471, CVE-2025-31136Referrer-Policy: same-origin #6303, #7478ext.php #7479, CVE-2025-31134mod_filter to ensure that AddOutputFilterByType works #7419[unable to retrieve full-text content]
[unable to retrieve full-text content]
[unable to retrieve full-text content]
(Bild: Pincasso/Shutterstock.com)
Eine neue Methode erlaubt die Multiplikation großer Zahlen.
Die Klassen für Ganzzahltypen Int32, UInt32, Int64 und UInt64 bieten jeweils eine neue Methode BigMul() für die Multiplikation, die die Ergebnisse als Int64 und UInt64 bzw. Int128 und UInt128 zurückliefert (ohne Überlauf).
public void BigMul()
{
CUI.Demo();
long Value1 = long.MaxValue;
ulong Value2 = ulong.MaxValue;
Console.WriteLine("Value1: " + Value1.ToString("#,0"));
Console.WriteLine("Value2: " + Value2.ToString("#,0"));
CUI.H1("Normale Multiplikation");
Int128 e1 = Value1 * 2; // Überlauf! -2
UInt128 e2 = Value2 * 2; // Überlauf! 18446744073709551614
Console.WriteLine(e1.ToString("#,0")); // Überlauf! -2
Console.WriteLine(e2.ToString("#,0")); // Überlauf! 18446744073709551614
CUI.H1("Multiplikation mit BigMul()");
Int128 e3 = Int64.BigMul(Value1, 2); // 18.446.744.073.709.551.614
UInt128 e4 = UInt64.BigMul(Value2, 2); // 36.893.488.147.419.103.230
Console.WriteLine(e3.ToString("#,0")); // 18.446.744.073.709.551.614
Console.WriteLine(e4.ToString("#,0")); // 36.893.488.147.419.103.230
}
URL dieses Artikels:
https://www.heise.de/-10331981
Links in diesem Artikel:
[1] mailto:rme@ix.de
Copyright © 2025 Heise Medien
(Bild: Pincasso/Shutterstock.com)
In .NET 9.0 kann man neuerdings einen Globally Unique Identifier in der Version 7 mit Zeitstempel erzeugen.
Die .NET-Klasse System.Guid bietet seit .NET 9.0 neben der statischen Methode NewGuid(), die einen Globally Unique Identifier (GUID), alias UUID (Universally Unique Identifier), gemäß RFC 9562 [1] mit reinen Zufallszahlen (Version 4) erzeugt, nun auch eine weitere statische Methode CreateVersion7() mit einem Timestamp und einer Zufallszahl.
Folgender Code zeigt sowohl den Einsatz von NewGuid() als auch den von CreateVersion7():
public void Run()
{
CUI.Demo(nameof(FCL9_Guid));
for (int i = 0; i < 10; i++)
{
Guid guid = Guid.NewGuid();
Console.WriteLine($"Guid v4:\t{guid}");
}
for (int i = 0; i < 10; i++)
{
Guid guid7 = Guid.CreateVersion7();
Console.WriteLine($"Guid v7:\t{guid7}");
}
CUI.Yellow("Warte 1 Sekunde...");
Thread.Sleep(1000);
for (int i = 0; i < 10; i++)
{
Guid guid7 = Guid.CreateVersion7();
Console.WriteLine($"Guid v7:\t{guid7}");
}
}
(Bild: Screenshot (Holger Schwichtenberg))
Der Timestamp ist in UTC-Zeit in den ersten 64 Bits der GUID enthalten.
Zum Extrahieren des Zeitpunkts gibt es keine eingebaute Methode, man kann ihn aber folgendermaßen extrahieren:
public DateTimeOffset GetDateTimeOffset(Guid guid)
{
byte[] bytes = new byte[8];
guid.ToByteArray(true)[0..6].CopyTo(bytes, 2);
if (BitConverter.IsLittleEndian)
{
Array.Reverse(bytes);
}
long ms = BitConverter.ToInt64(bytes);
return DateTimeOffset.FromUnixTimeMilliseconds(ms);
}
URL dieses Artikels:
https://www.heise.de/-10316051
Links in diesem Artikel:
[1] https://www.rfc-editor.org/rfc/rfc9562.html
[2] mailto:rme@ix.de
Copyright © 2025 Heise Medien
(Bild: Pincasso/Shutterstock)
In C# 13.0 hat Microsoft den Einsatzbereich von ref struct unter anderem zum Implementieren von Schnittstellen erweitert.
Seit C# 7.2 gibt es Strukturen, die immer auf dem Stack leben und niemals auf den Heap wandern können: ref struct. In C# 13.0 hat Microsoft den Einsatz von ref struct erweitert.
Solche Typen können nun:
where T : allows ref struct verwenden.yield verwendet werden. Allerdings darf die Struktur nicht länger leben als der aktuelle Durchlauf des Iterator.Task oder Task<T> liefern, genutzt werden.Weiterhin gilt aber: Wenn man einen Typ als ref struct deklariert, ist ein Boxing nicht mehr möglich. Der Einsatz von ref struct ist daher begrenzt. So kann man beispielsweise kein Array und keine List<T> daraus erzeugen.
Folgender Code zeigt einen eigenen Typ mit ref struct, der eine Schnittstelle implementiert:
internal interface IPerson
{
int ID { get; set; }
int Name { get; set; }
}
// NEU seit C# 13.0: ref struct kann Schnittstelle implementieren
ref struct Person : IPerson
{
public int ID { get; set; }
public int Name { get; set; }
// ToString()
public override string ToString()
{
return "Person #" + ID + " " + Name;
}
}
}
class Client
{
public void Run()
{
Person p = new Person();
p.ID = 1;
p.Name = 2;
Console.WriteLine(p.ID);
Console.WriteLine(p.Name);
// Das ist alles nicht erlaubt!
// IPerson i = p; // Casting auf Schnittstelle
// List<Person> PersonList = new(); // List<T>
// PersonList[] PersonArray = new Person[10]; // Array
}
}
URL dieses Artikels:
https://www.heise.de/-10307583
Links in diesem Artikel:
[1] mailto:rme@ix.de
Copyright © 2025 Heise Medien
(Bild: Vova Shevchuk / Shutterstock.com)
Psychologische Tricks werden scheinbar erfolgreich gegen ein LLM eingesetzt – aber ist das wirklich relevant?
Einem Psychologen ist es gelungen, Sicherheitsrichtlinien diverser Large Language Models (LLMs) mit Tricks auszuhebeln, die eigentlich zur Manipulation von Menschen dienen. Mit Gaslighting hat Luke Bölling LLMs [1] dazu gebracht, einen Text zu erzeugen, der scheinbar erklärt, wie man einen Molotowcocktail [2]herstellt (Siehe dazu auch der heise-Artikel [3] von Niklas Jan Engelking).
Gaslighting [4] ist ein psychologisches Konzept: Es ist "eine Form von psychischer Manipulation …, mit der Opfer gezielt desorientiert, verunsichert und in ihrem Realitäts- und Selbstbewusstsein allmählich beeinträchtigt werden". LLMs generieren jedoch lediglich Texte. Sie nehmen keine Realität wahr und haben kein Selbstbewusstsein. Der Artikel argumentiert, dass dieser Angriff trotzdem funktioniert, weil das Trainingsmaterial von Menschen geschrieben wurde und daher auch Konzepte wie Gaslighting darin vorkommen. Dennoch dürfen wir nie vergessen, dass LLMs nichts weiter als Textgeneratoren sind. Sie haben keine Emotionen, wie die zitierte Arbeit auch feststellt. Daher werde ich im weiteren Text den Begriff "Textgenerator" verwenden, da er besser beschreibt, was LLMs tatsächlich tun.
Textgeneratoren können offensichtlich einen Text erzeugen, der wie eine plausible Anleitung zur Herstellung eines Molotowcocktails erscheint – genau, wie sie scheinbar plausible Verweise auf Gerichtsentscheidungen [5] für einen Anwalt generieren können. Und obwohl diese Verweise für den Anwalt überzeugend klingen, sind sie in Wirklichkeit erfunden. Das ist eines der Probleme mit Textgeneratoren: Sie sind darauf optimiert, überzeugend zu klingen, und versuchen so, das kritische Hinterfragen ihrer Ergebnisse zu vermeiden.
Die eigentliche Frage lautet also: Würde die angebliche Anleitung zur Herstellung eines Molotowcocktails tatsächlich funktionieren? Ich habe mit Lucas Dohmen einen Stream über Textgeneratoren [6] gemacht, und eine der zentralen Erkenntnisse war: Man muss die Ergebnisse von Textgeneratoren überprüfen, um sicherzustellen, dass sie korrekt und nicht erfunden sind. Der zitierte Artikel scheint dies nicht zu tun – das heißt, die gesamte Information über Molotowcocktails könnte schlicht "halluziniert" sein. Das Problem der Generierung von Fake-Informationen durch Textgeneratoren ist nämlich so bekannt, dass es einen eigenen Begriff (Halluzination) gibt. Tatsächlich ist "halluziniert" der falsche Begriff, denn "unter Halluzination [7]versteht man eine Wahrnehmung, für die keine nachweisbare externe Reizgrundlage vorliegt". Textgeneratoren haben jedoch keine Wahrnehmungen. Daher sollten wir dieses Phänomen korrekt als "Generierung von Fake-Informationen" benennen.
Wir können die Information über den Molotowcocktail nicht überprüfen, da sie im Originalartikel unkenntlich gemacht wurde – was natürlich absolut sinnvoll ist. Ich würde mich aber nicht auf diese Informationen verlassen, um tatsächlich einen improvisierten Brandsatz zu bauen.
Der Artikel behauptet, dieses Problem sei ein Sicherheitsrisiko bei Textgeneratoren. Falls das wirklich der Fall wäre, bestünde die Lösung darin, sensible Informationen aus dem Trainingsmaterial auszuschließen. Das Anpassen der Trainingsdaten wäre ohnehin sinnvoll, beispielsweise aufgrund von Urheberrechtsproblemen. Aus irgendeinem Grund scheint Urheberrecht für Textgeneratoren nicht zu gelten, während es für Menschen schwere Folgen [8]haben kann. Warum sollte es nicht möglich sein, Anleitungen zur Herstellung von improvisierten Brand- oder Sprengsätzen aus dem Trainingsmaterial zu entfernen? Wenn das zu viel Aufwand ist, dann ist das Problem vielleicht gar nicht so groß.
Dieses "Sicherheitsproblem" wäre auch nur dann ein echtes Problem, wenn der Textgenerator keine Fake-Informationen generiert hätte – dazu sagt der Artikel jedoch nichts. Falls es Fake-Informationen sind, könnte man es vielleicht als eine Art Honeypot [9] betrachten, um Menschen von echten Informationen fernzuhalten?
Doch die eigentliche Frage ist: Wäre dies wirklich der einfachste Weg, um an solche Informationen zu gelangen? Angenommen, ich plane, einen Molotowcocktail zu bauen – würde ich komplizierte "psychologische Angriffe" auf einen Textgenerator durchführen, um eine möglicherweise falsche Antwort zu erhalten? Gibt es einfachere und präzisere Möglichkeiten? Also habe ich den naheliegenden Weg ausprobiert: eine Suche mit einer Suchmaschine. Zwei Klicks später fand ich ein Dokument, das detailliert erklärt, wie man anspruchsvolle improvisierte Sprengsätze herstellt – und ich habe guten Grund zu glauben, dass diese Anleitungen tatsächlich funktionieren. Zugegeben, dieses spezielle Dokument beschreibt nicht, wie man einen Molotowcocktail baut, aber es erklärt eine Vielzahl anderer Vorrichtungen. Diese Recherche selbst nachzuvollziehen, ist sicher spannend.
LLMs sind Textgeneratoren, die potenziell erfundene Informationen produzieren – das ist bekannt. Es mag ausgeklügelte Methoden geben, um sie dazu zu bringen, Texte zu generieren, die sensible Informationen zu enthalten scheinen – doch diese könnten schlicht Falschinformationen sein. Häufig gibt es einfachere Wege, um an sensible Informationen zu gelangen, insbesondere wenn es um improvisierte Brand- oder Sprengsätze geht. Daher sehe ich keinen Grund, "psychologische" Tricks auf Textgeneratoren anzuwenden – denn genau das sind LLMs letztlich.
URL dieses Artikels:
https://www.heise.de/-10334947
Links in diesem Artikel:
[1] https://humandataexperience.substack.com/p/librarian-bully-attack-gaslighting
[2] https://de.wikipedia.org/wiki/Molotowcocktail
[3] https://www.heise.de/news/Neuer-LLM-Jailbreak-Psychologe-nutzt-Gaslighting-gegen-KI-Filter-10332571.html
[4] https://de.wikipedia.org/wiki/Gaslighting
[5] https://news.bloomberglaw.com/litigation/lawyer-sanctioned-over-ai-hallucinated-case-cites-quotations
[6] https://www.heise.de/news/software-architektur-tv-KI-und-LLMs-kritisch-betrachtet-10287426.html
[7] https://de.wikipedia.org/wiki/Halluzination
[8] https://en.wikipedia.org/wiki/Aaron_Swartz#United_States_v._Aaron_Swartz
[9] https://de.wikipedia.org/wiki/Honeypot
[10] mailto:map@ix.de
Copyright © 2025 Heise Medien
(Bild: erzeugt mit KI durch iX)
Automatisiertes Refactoring klingt verlockend – doch lässt sich Codequalität wirklich auf Knopfdruck verbessern, oder braucht es am Ende doch den Menschen?
Heute habe ich eine große Ankündigung für Sie – eine, die für viele Entwicklerinnen und Entwickler wohl einem echten Traumszenario gleichkommt. Ein Gedanke, der so bestechend einfach klingt, dass man sich fragen könnte, warum es so etwas nicht schon längst gibt. Sicher kennen auch Sie Gespräche im Team, in denen dieser Wunsch immer wieder auftaucht – meist mit ironischem Unterton, aber manchmal durchaus mit einem Funken Hoffnung.
Stellen Sie sich vor, Sie könnten Ihren kompletten Codestand einfach in eine ZIP-Datei packen, per HTTP an einen Service hochladen – und wenige Minuten später erhalten Sie ihn vollständig refactored zurück: besser strukturiert, mit klaren Abhängigkeiten, sinnvoll modularisiert, mit sprechenden Namen, nachvollziehbarer Architektur und aussagekräftigen Tests. Inklusive aktualisierter Dokumentation, vollständig durchgelintet und formatiert. Einmal hochladen, und der Code sieht anschließend aus, als hätte ein erfahrenes Senior-Architekturteam drei Wochen intensiv daran gearbeitet. Genau das haben wir jetzt Realität werden lassen und nennen es: "Refactoring as a Service".
Die Idee ist so einfach wie genial: Haben Sie ein Repository, dessen Zustand nicht mehr ganz optimal ist? Kein Problem: Sie laden den Code einfach über unsere API hoch oder verweisen auf ein Git-Repository mit einem gültigen Token – der Rest passiert automatisch im Hintergrund. Unser Service analysiert den Code mit statischen und dynamischen Verfahren, führt eine kombinierte AST- und Graphanalyse durch, identifiziert strukturelle Schwächen, erkennt Anti-Patterns, bewertet essenzielle Metriken wie zyklomatische Komplexität, Kohäsion, Kopplung, Testabdeckung und Architekturkonformität – und erstellt daraus ein kontextsensitives, semantisch fundiertes Refactoring-Konzept, das automatisiert umgesetzt wird. Die resultierende Codebasis ist nicht nur schöner und verständlicher, sondern auch modularer, wartbarer und besser getestet. Selbstverständlich integriert sich das Ganze nahtlos in CI/CD-Prozesse und ist über eine OpenAPI-Schnittstelle vollständig automatisierbar.
Weil uns das noch nicht genug war, wird zusätzlich eine KI-gestützte Kommentierung vorgenommen, die basierend auf Codeverständnis sowie Projektkontext passgenaue Kommentare und Erläuterungen hinzufügt – sowohl auf Code- als auch auf Modul- und Architekturebene. Die Testabdeckung wird nicht nur erhöht, sondern zielgerichtet erweitert, mit besonderem Augenmerk auf Pfadabdeckung, Grenzfälle, Randbedingungen und semantisch relevante Kombinationen. All dies orchestriert ein auf Kubernetes skalierendes Service-Backend, das selbst größere Projekte in kurzer Zeit bewältigt. Für besonders kritische Projekte bieten wir zudem eine Audit-Funktion: Jede Änderung bleibt einzeln nachvollziehbar, jeder Commit wird semantisch kommentiert, jeder Refactoring-Schritt dokumentiert. Kurz gesagt: Der perfekte Begleiter für Softwareteams, die Qualität ernst nehmen, dabei aber ihren Fokus auf die eigentliche Entwicklung legen wollen.
Die eigentliche Magie entsteht durch die Kombination verschiedener Technologien und Ansätze: Statische Analyse alleine hilft wenig, wenn sie den fachlichen Kontext nicht berücksichtigt. LLMs alleine schreiben zwar Code, wissen aber nicht, ob dieser wirklich zu Ihrem Projekt passt. Clean-Code-Prinzipien sind essenziell, lösen aber nicht das grundlegende Problem der strukturellen Überarbeitung. Erst die systematische Verbindung dieser Ansätze schafft etwas, das sich wirklich als Refactoring im engeren Sinne bezeichnen lässt. Genau das macht "Refactoring as a Service" nicht nur zu einem interessanten Tool, sondern zu einem echten Gamechanger.
Natürlich – und das war uns von Anfang an bewusst – ersetzt "Refactoring as a Service" nicht den Menschen. Unser Ziel war es nie, die Expertise erfahrener Entwicklerinnen und Entwickler überflüssig zu machen. Ganz im Gegenteil: Wir wollten diese Expertise entkoppeln, also ermöglichen, dass sie unabhängig von individueller Verfügbarkeit, Projektkontext oder Zeitdruck eingesetzt werden kann. Deshalb haben wir all unser Wissen, unsere Erfahrungen und Prinzipien in diesen Service einfließen lassen – damit andere Teams davon profitieren können, ohne dass wir immer persönlich involviert sein müssen.
Das ist nicht nur für Entwicklerinnen und Entwickler spannend, sondern gleichermaßen interessant für Softwarearchitektinnen und -architekten, Teamleads und CTOs sowie alle, die sich intensiv mit Softwarequalität und Wartbarkeit auseinandersetzen. Denn Refactoring ist nicht nur ein technisches Hilfsmittel, sondern ein strategisches Instrument. Es entscheidet maßgeblich über Lebensdauer, Änderbarkeit und Erweiterbarkeit – und damit letztlich über den wirtschaftlichen Erfolg eines Projekts. Genau deshalb möchten wir mit "Refactoring as a Service" dazu beitragen, dass mehr Teams die Möglichkeit erhalten, ihre Codebasis auf ein solides und wartbares Fundament zu stellen.
An dieser Stelle fragen Sie sich vermutlich bereits: Klingt vielversprechend – doch wie viel kostet das Ganze? Wann und wie kann ich es ausprobieren? Die Antwort auf diese Fragen lautet leider: gar nicht. Denn heute ist der 1. April, und "Refactoring as a Service" existiert nicht.
Doch bevor Sie enttäuscht sind: Die Idee hinter "Refactoring as a Service" – also der Wunsch nach automatisiertem, reproduzierbarem und skalierbarem Refactoring – ist real und absolut verständlich. Wer von uns kennt nicht den Frust, sich durch Altlasten zu kämpfen, zu fragen, was sich jemand bei einem Stück Code gedacht haben könnte, und den Wunsch, einfach einen Knopf drücken zu können: "Jetzt Refactor" – klick, fertig. Leider ist es nicht ganz so einfach, und dafür gibt es gute Gründe.
Refactoring ist eben nicht nur eine technische Tätigkeit, sondern eine bewusste Entscheidung: eine Entscheidung darüber, wie Code strukturiert werden soll. Welche Konzepte getrennt, welche zusammengeführt werden müssen. Welche Benennungen welche Bedeutung tragen. Welche Architekturprinzipien zum Einsatz kommen, wann bestimmte Patterns sinnvoll sind und wann man bewusst darauf verzichten sollte. All das hängt unmittelbar mit einem fundierten fachlichen Verständnis zusammen: Sie können keine gute Struktur aufbauen, wenn Sie nicht wissen, was diese Struktur abbilden soll. Sie können keine Struktur sinnvoll bewerten, wenn Sie nicht verstehen, welche Anforderungen diese erfüllen muss. Genau deshalb ist Refactoring auch nichts, was sich rein nach Schema F automatisieren ließe. Es handelt sich eben nicht um einen rein technischen Akt, sondern um einen analytischen und diskursiven Prozess.
Natürlich gibt es Tools, Plug-ins und LLMs. Doch keines dieser Hilfsmittel kann Ihnen beantworten, ob eine Methode in einen Service oder in einen Controller gehört. Keines erkennt zuverlässig, ob eine bestimmte Implementierung noch zur aktuellen Realität passt oder lediglich ein Relikt früherer Feature-Iterationen darstellt. Keines entscheidet für Sie, ob ein Name tatsächlich treffend oder nur historisch gewachsen ist. Kein Tool abstrahiert Fachlichkeit umfassend, ersetzt Kommunikation oder übernimmt Verantwortung. All diese Dinge erfordern Erfahrung, Kontextverständnis, Empathie – also letztlich Menschen.
Deshalb ist gutes Refactoring stets gute Teamarbeit. Es bedeutet, innezuhalten, Code bewusst erneut zu lesen, zu verstehen, was er ausdrücken möchte, und anschließend in kleinen, wohlüberlegten Schritten etwas Besseres daraus zu machen. Etwas Klareres und Stabileres, das den Alltag erleichtert und nicht erschwert. Genau darin liegt auch die Verantwortung beim Refactoring. Wer refactored, entscheidet sich für langfristige Qualität – und gegen kurzfristige Bequemlichkeit. Das ist nicht immer einfach.
In vielen Teams fehlt dafür oft Zeit, Mut oder Rückendeckung. Features werden entwickelt, Stories geliefert und der Durchsatz optimiert – doch der Boden, auf dem alles steht, wird selten stabilisiert. Je länger das andauert, desto brüchiger wird das Fundament. Irgendwann wächst Refactoring dann zu einem Mammutprojekt heran, das niemand mehr anfassen möchte – obwohl anfangs nur wenige kleine Schritte nötig gewesen wären. Genau das darf nicht passieren.
Was also ist der bessere Weg? Sehen Sie Refactoring nicht als einmalige, große Aufgabe, sondern als kontinuierlichen Prozess. Machen Sie Refactoring zum festen Bestandteil Ihres Alltags, jeder Story, jedes Features, jedes Sprints. Refactoring ist nicht etwas, das man macht, wenn gerade Zeit übrig bleibt – sondern etwas, das man stets tun sollte, um sich die Zukunft deutlich einfacher zu gestalten. Das bedeutet konkret: kleine Schritte, regelmäßige Reviews, klare Verantwortlichkeiten, Mut zur Veränderung und ein gemeinsames Verständnis im Team, dass gute Software niemals Zufall ist, sondern das Ergebnis von Haltung, Prinzipien und kontinuierlicher Pflege.
URL dieses Artikels:
https://www.heise.de/-10333543
Links in diesem Artikel:
[1] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[2] mailto:mai@heise.de
Copyright © 2025 Heise Medien
(Bild: Pincasso/Shutterstock.com)
Eine neue Methode erlaubt die Multiplikation großer Zahlen.
Die Klassen für Ganzzahltypen Int32, UInt32, Int64 und UInt64 bieten jeweils eine neue Methode BigMul() für die Multiplikation, die die Ergebnisse als Int64 und UInt64 bzw. Int128 und UInt128 zurückliefert (ohne Überlauf).
public void BigMul()
{
CUI.Demo();
long Value1 = long.MaxValue;
ulong Value2 = ulong.MaxValue;
Console.WriteLine("Value1: " + Value1.ToString("#,0"));
Console.WriteLine("Value2: " + Value2.ToString("#,0"));
CUI.H1("Normale Multiplikation");
Int128 e1 = Value1 * 2; // Überlauf! -2
UInt128 e2 = Value2 * 2; // Überlauf! 18446744073709551614
Console.WriteLine(e1.ToString("#,0")); // Überlauf! -2
Console.WriteLine(e2.ToString("#,0")); // Überlauf! 18446744073709551614
CUI.H1("Multiplikation mit BigMul()");
Int128 e3 = Int64.BigMul(Value1, 2); // 18.446.744.073.709.551.614
UInt128 e4 = UInt64.BigMul(Value2, 2); // 36.893.488.147.419.103.230
Console.WriteLine(e3.ToString("#,0")); // 18.446.744.073.709.551.614
Console.WriteLine(e4.ToString("#,0")); // 36.893.488.147.419.103.230
}
URL dieses Artikels:
https://www.heise.de/-10331981
Links in diesem Artikel:
[1] mailto:rme@ix.de
Copyright © 2025 Heise Medien
(Bild: Shutterstock/Milos Milosevic)
CloudEvents schafft Interoperabilität für Event-basierte Systeme. Warum der Standard sinnvoll ist und wie er funktioniert, behandelt dieser Blogpost.
Es heißt oft, Event-basierte Systeme seien besonders leistungsfähig, weil sich Events hervorragend dazu eignen, Informationen über fachliche Ereignisse zwischen verschiedenen Systemen auszutauschen und diese so zu integrieren. In der Realität zeigt sich jedoch häufig ein ganz anderes Bild: Jedes System verwendet seine eigene Variante von Events, die Formate sind nicht kompatibel, und die erhoffte Integration über Events scheitert dadurch schnell. Was hier eindeutig fehlt, ist ein standardisiertes Format – ein allgemeingültiger Standard, der definiert, welche Daten ein Event enthalten soll, wie es strukturiert ist und wie es übermittelt wird.
Glücklicherweise hat sich die Cloud Native Computing Foundation [1] (CNCF) dieser Herausforderung angenommen und genau einen solchen Standard geschaffen: CloudEvents [2]. Für jede Entwicklerin und jeden Entwickler, die mit Event-basierten Systemen arbeiten, ist dieses Thema von großer Relevanz. Daher möchte ich Ihnen in diesem Blogpost einen genaueren Einblick geben.
Vielleicht fragen Sie sich zunächst, was ich überhaupt unter dem Begriff "Event" verstehe. Eine präzise Antwort würde an dieser Stelle den Rahmen sprengen. Daher empfehle ich Ihnen meinen Blogpost zum Thema Event Sourcing [3], der vor einigen Wochen erschienen ist. Es lohnt sich, sich zunächst damit vertraut zu machen und erst anschließend hier weiterzulesen.
Wenn Sie bereits wissen, was mit Events gemeint ist, dann kennen Sie vermutlich auch das Problem: Jedes Event-getriebene System definiert sein eigenes Format für Events, was den Austausch und die Integration zwischen verschiedenen Systemen erheblich erschwert. Der theoretische Vorteil einer gemeinsamen Kommunikationsform durch Events bleibt in der Praxis oft ungenutzt, da die Formate schlicht nicht zueinander passen. Solange es keinen verbindlichen Standard gibt, bleibt der Nutzen solcher Events für die Systemintegration begrenzt.
Genau hier setzt das Konzept von CloudEvents an. Die dahinterstehende Idee ist einfach: Es geht darum, ein standardisiertes Format für Events zu schaffen, um die Interoperabilität zwischen verschiedenen Systemen zu ermöglichen. Entwickelt wurde dieser Standard, wie gesagt, von der Cloud Native Computing Foundation, einer gemeinnützigen Organisation, die von nahezu allen großen Cloud-Anbietern wie Microsoft, Amazon und Google unterstützt wird.
Das Ziel von CloudEvents ist es, einheitliche Metadaten für Events zu definieren, damit diese zumindest in ihrer äußeren Struktur kompatibel zueinander gestaltet werden können. Zusätzlich sollen plattform- und transportschichtunabhängige Strukturen ermöglicht werden – zum Beispiel soll JSON über HTTPS genauso einsetzbar sein wie XML über MQTT. Der Standard definiert dabei zentrale Begriffe wie "ID", "Source", "Type" und weitere essenzielle Felder.
Warum sollte man auf diesen Standard setzen? Der naheliegende Vorteil liegt in der Reduktion des Aufwands für Konvertierungen und Parsings sowie in einer deutlich verbesserten Interoperabilität zwischen Systemen. Zudem unterstützt CloudEvents verschiedene Protokolle und lässt sich dadurch flexibel transportieren – unabhängig vom konkreten Übertragungsweg. Das ist nicht nur für Anwendungen relevant, sondern auch für Router und Broker, da sich Events durch die standardisierten Metadaten wesentlich besser analysieren, filtern und verteilen lassen. Außerdem verbessert sich durch die strukturierte Beschreibung der Events die Nachvollziehbarkeit, etwa hinsichtlich Ursprung und Zeitpunkt des Ereignisses. Auf dieser Basis lassen sich generische Werkzeuge für Events realisieren – ein Aspekt, der insbesondere für Microservices, Serverless-Funktionen und vergleichbare Architekturen von Bedeutung ist. Und wenn man diesen Gedanken weiterführt, dann wäre CloudEvents sogar als Persistenzformat für Event Sourcing gut geeignet.
Natürlich stellt sich die Frage, welche Herausforderungen oder Einwände gegen die Nutzung von CloudEvents sprechen könnten. Ein zentrales Problem besteht darin, dass bisher noch nicht viele Systeme diesen Standard unterstützen. Das heißt, es existieren derzeit nur wenige Anwendungen, die direkt kompatibel sind. Bestehende, proprietäre Event-Formate müssen daher weiterhin unterstützt werden – zumindest ergänzend. Das verursacht zusätzlichen Aufwand, den man eigentlich vermeiden möchte. Dies betrifft nicht nur kleinere Systeme, sondern auch Dienste wie die Amazon EventBridge von AWS oder das Event Grid von Microsoft Azure.
Ein weiterer Punkt ist, dass CloudEvents lediglich die Metadaten vereinheitlicht. Die Nutzdaten – also die Payload – bleiben weiterhin spezifisch für die jeweilige Anwendung. Das ist systemimmanent, denn der fachliche Inhalt eines Events lässt sich nicht generisch definieren. Hinzu kommt, dass CloudEvents durch ihre strukturierte Form möglicherweise mehr Overhead verursachen als einfachere proprietäre Formate, insbesondere wenn nicht alle vorgesehenen Felder genutzt werden.
Trotzdem halte ich CloudEvents für einen großen Schritt in die richtige Richtung. Ohne klare Regeln ist es unnötig aufwendig, Event-basierte Systeme miteinander zu koppeln. Ein gemeinsames Vokabular erscheint hier ausgesprochen sinnvoll. Positiv hervorzuheben ist auch, dass sich CloudEvents gut mit anderen Standards kombinieren lässt – etwa mit AsyncAPI [5] oder OpenTelemetry [6]. Alles in allem ist der Standard darauf ausgelegt, den Einstieg möglichst einfach zu gestalten und die Integration in bestehende Systeme zu erleichtern.
Daraus ergibt sich die Frage, wie man CloudEvents sinnvoll umsetzt. Zunächst sollte man klären, ob der Einsatz für die eigene Anwendung überhaupt sinnvoll ist. Meiner persönlichen Einschätzung nach lautet die Antwort eindeutig: Sobald Sie mit Events arbeiten und sobald Sie auch nur ansatzweise darüber nachdenken, Ihre Software mit anderen Systemen zu koppeln oder zu integrieren, sollten Sie CloudEvents in Betracht ziehen. Natürlich können Sie auch ein eigenes Format definieren – gewinnen werden Sie dadurch allerdings wenig. Der einzige "Nachteil" besteht darin, dass man sich einmal mit dem CloudEvents-Standard vertraut machen muss. Nach meiner Erfahrung ist das sehr gut machbar: Der Standard ist verständlich und überschaubar.
Wenn Sie sich dafür entscheiden, CloudEvents zu nutzen, dann sollten Sie es auch korrekt tun. Das bedeutet vor allem, sich mit der Bedeutung und dem Format der einzelnen Felder auseinanderzusetzen. Es wäre wenig hilfreich, das Format formal zu unterstützen, dabei aber inkorrekte Werte zu verwenden – insbesondere, wenn sich solche Fehler erst Monate später im Integrationsfall zeigen. Felder wie "source", "subject" oder "type" erfordern dabei besondere Aufmerksamkeit. Es ist nicht kompliziert, erfordert jedoch eine sorgfältige Lektüre der Spezifikation [7].
Falls Sie bereits ein Event-basiertes System im Einsatz haben, das den CloudEvents-Standard bislang nicht berücksichtigt, ist das kein Grund, das Thema abzulehnen. Sie können mit vergleichsweise geringem Aufwand Wrapper, Konverter oder Middleware einsetzen, um zwischen bestehenden Formaten und dem Standard zu übersetzen. Das lohnt sich vor allem langfristig, da Sie auf diese Weise einen einheitlichen Austauschstandard etablieren und den Bedarf an individuellen Adaptern reduzieren. Besonders relevant wird das, wenn Sie CloudEvents auch als Basis für Event Sourcing nutzen – dann sind die Events bereits im Kern standardisiert.
Bleibt abschließend die Frage, ob sich CloudEvents langfristig als Standard etablieren wird. Ich bin in dieser Hinsicht optimistisch. Die Unterstützung durch Cloud-Anbieter wächst, ebenso wie die Verbreitung in Open- und Closed-Source-Anwendungen. Darüber hinaus dient CloudEvents bereits als Grundlage für weitere Standards, etwa CDEvents [8], die sich speziell auf Continuous-Delivery-Prozesse konzentrieren. Diese Entwicklung verdeutlicht, dass CloudEvents als tragfähige und zukunftsfähige Basis angesehen werden.
Ich kann Ihnen daher nur empfehlen, sich intensiv mit CloudEvents zu beschäftigen. Der Standard ist hilfreich, durchdacht und vor allem praxisnah. Je stärker Sie mit Event-basierten Architekturen arbeiten – sei es in der Entwicklung, in der Infrastruktur oder in anderen Bereichen –, desto relevanter wird dieses Konzept für Sie.
Wenn Sie bereits Erfahrungen mit CloudEvents gesammelt haben oder planen, sich damit auseinanderzusetzen, freue ich mich über Ihre Rückmeldung. Und falls Sie generell mehr über Event-basierte Systeme lernen möchten: Neben der bereits erwähnten Einführung in Event Sourcing finden Sie weiterführende Informationen auch in dem Blogpost "CQRS als Grundlage für moderne, flexible und skalierbare Anwendungsarchitektur [9]".
URL dieses Artikels:
https://www.heise.de/-10325241
Links in diesem Artikel:
[1] https://www.cncf.io/
[2] https://cloudevents.io/
[3] https://www.heise.de/blog/Event-Sourcing-Die-bessere-Art-zu-entwickeln-10258295.html
[4] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[5] https://www.asyncapi.com/
[6] https://opentelemetry.io/
[7] https://github.com/cloudevents/spec
[8] https://cdevents.dev/
[9] https://www.heise.de/blog/CQRS-als-Grundlage-fuer-moderne-flexible-und-skalierbare-Anwendungsarchitektur-10275526.html
[10] https://www.mastering-gitops.de/?wt_mc=intern.academy.dpunkt.konf_dpunkt_clc_gitops.empfehlung-ho.link.link
[11] https://www.mastering-gitops.de/veranstaltung-83006-se-0-gitops-auf-allen-ebenen-mit-crossplane-&-argocd.html?wt_mc=intern.academy.dpunkt.konf_dpunkt_clc_gitops.empfehlung-ho.link.link
[12] https://www.mastering-gitops.de/veranstaltung-83394-se-0-gitops-evolution-moderne-infrastruktur-pipelines-mit-pulumi-und-argo-cd.html?wt_mc=intern.academy.dpunkt.konf_dpunkt_clc_gitops.empfehlung-ho.link.link
[13] https://www.mastering-gitops.de/veranstaltung-83008-se-0-praxisbericht-zwei-jahre-gitops-mit-fluxcd-in-produktion.html?wt_mc=intern.academy.dpunkt.konf_dpunkt_clc_gitops.empfehlung-ho.link.link
[14] https://www.mastering-gitops.de/veranstaltung-83446-se-0-effiziente-multi-tenant-architekturen-gitops-mit-argo-cd-in-der-praxis.html?wt_mc=intern.academy.dpunkt.konf_dpunkt_clc_gitops.empfehlung-ho.link.link
[15] https://www.mastering-gitops.de/veranstaltung-83445-se-0-gitops-pattern-fuer-verteilte-deployment-pipelines-mit-kargo.html?wt_mc=intern.academy.dpunkt.konf_dpunkt_clc_gitops.empfehlung-ho.link.link
[16] https://www.mastering-gitops.de/tickets.php?wt_mc=intern.academy.dpunkt.konf_dpunkt_clc_gitops.empfehlung-ho.link.link
[17] mailto:mai@heise.de
Copyright © 2025 Heise Medien
