Anmelden
Uwe Kerkow
Enceladus vor den Wolkenbändern des Saturn. Grafik: Alex Terentii, shutterstock
Der Eismond Enceladus befindet sich in einem thermischen Gleichgewicht und beherbergt komplexe organische Moleküle. Was bedeuten diese Ergebnisse genau?
Enceladus, einer der faszinierendsten Monde des Saturn, entpuppt sich als noch vielversprechender für die Suche nach außerirdischem Leben als bisher angenommen. Jüngst ausgewertete Forschungsergebnisse der NASA-Mission Cassini zeigen, dass der kleine Eismond nicht nur am aktiven Südpol, sondern auch am Nordpol bedeutende Mengen Wärme abstrahlt [1].
Ein internationales Forschungsteam der Universität Oxford, des Southwest Research Institute und des Planetary Science Institute in Tucson hat erstmals einen signifikanten Wärmefluss am Nordpol von Enceladus nachgewiesen. Bislang gingen Wissenschaftler davon aus, dass der Wärmeverlust auf den Südpol beschränkt sei, wo spektakuläre Geysire Wasserdampf und Eispartikel ins All schleudern.
Diese Entdeckung deutet darauf hin, dass sein unterirdischer Ozean über geologische Zeiträume stabil bleiben könnte - eine Grundvoraussetzung für die Entstehung von Leben.
Die Messungen ergaben einen endogenen Wärmefluss von 46 Milliwatt pro Quadratmeter am Nordpol. Das entspricht etwa zwei Dritteln der durchschnittlichen Wärme, die durch die kontinentale Erdkruste entweicht.
Besonders bemerkenswert ist das nahezu perfekte Gleichgewicht zwischen Wärmeerzeugung und -verlust auf Enceladus. Kombiniert man die neuen Messungen mit der zuvor am Südpol entdeckten Wärme, ergibt sich ein Gesamtwärmeverlust von rund 54 Gigawatt. Dieser Wert stimmt fast exakt mit den Vorhersagen überein, wie viel Wärme durch Gezeitenkräfte erzeugt werden sollte – etwa 50 bis 55 Gigawatt.
Diese Gezeitenheizung wird durch die starke Gravitation des Saturn angetrieben, die den Mond während seiner elliptischen Umlaufbahn streckt und dann wieder komprimiert. Das thermische Gleichgewicht zwischen beiden Polen legt nahe, dass der Ozean von Enceladus über Milliarden von Jahren flüssig bleiben kann und so ein stabiles Umfeld für potenzielle Lebensentwicklung bieten könnte.
"Es ist wirklich spannend, dass dieses Ergebnis die langfristige Stabilität von Enceladus unterstützt - ein entscheidender Faktor für die Entwicklung von Leben", sagte Dr. Carly Howett, korrespondierende Autorin der Studie.
Parallel dazu haben Forscher der Freien Universität Berlin und anderer Institutionen die bisher detaillierteste Analyse organischer Verbindungen [2] in frisch ausgeworfenen Eispartikeln von Enceladus durchgeführt. Das Team um Dr. Nozair Khawaja analysierte Daten des Cosmic Dust Analyzers (CDA) der Cassini-Sonde [3], die während eines schnellen Vorbeiflugs mit 17,7 Kilometern pro Sekunde gesammelt wurden.
Die hohe Geschwindigkeit erwies sich als entscheidender Vorteil in der Versuchsanordnung: Sie verhinderte die Bildung von Wasserclustern, die die Signale organischer Moleküle oft überdecken, und ermöglichte neue Einblicke in die chemische Zusammensetzung der Eispartikel.
Die Wissenschaftler identifizierten eine Vielfalt bisher unentdeckter organischer Verbindungen, darunter aliphatische und zyklische Ester, Alkene, Ether sowie Verbindungen mit Stickstoff- und Sauerstoffgruppen. Khawaja betonte: "Diese organischen Verbindungen waren nur wenige Minuten alt und stammten aus frischem Eis direkt vom Ozean unter der Oberfläche von Enceladus."
Die neu entdeckten Moleküle ergänzen eine bereits beeindruckende Liste organischer Moleküle auf Enceladus. Der Mond beherbergt unter seiner eisigen Oberfläche einen globalen, salzigen Ozean, der flüssiges Wasser, Wärme und essenzielle chemische Bestandteile wie Phosphor und komplexe Kohlenwasserstoffe enthält.
Mit der jüngsten Identifikation von Phosphaten sind nun fünf der sechs bioessentiellen CHNOPS-Elemente [4] (Kohlenstoff, Wasserstoff, Stickstoff, Sauerstoff, Phosphor, Schwefel) in Material von Enceladus nachgewiesen.
Die organischen Verbindungen decken sich in erstaunlichem Maße mit Modellen zur organischen Synthese in hydrothermalen Systemen, wie sie am Meeresboden von Enceladus vermutet werden. Dr. Frank Postberg, Mitautor der Studie, erklärte: "Diese Moleküle, die wir in dem frisch ausgeworfenen Material fanden, beweisen, dass die komplexen organischen Moleküle nicht nur ein Produkt langer Weltraumstrahlung sind, sondern direkt im Ozean von Enceladus verfügbar sind."
Die Wärmemessungen liefern zudem wichtige Erkenntnisse über die Struktur von Enceladus. Basierend auf den neuen Wärmeflussmessungen schätzen die Forscher die Eisdicke am Nordpol auf 20 bis 23 Kilometer, im globalen Durchschnitt auf 25 bis 28 Kilometer. Diese Werte stimmen gut mit früheren Modellen überein, die auf Gravitationsmessungen und der Rotationsbewegung des Mondes basierten.
Trotz dieser Fortschritte bleibt eine zentrale Frage unbeantwortet: Wie alt ist der Ozean von Enceladus? Zwar ist Enceladus die kleinste Wasserwelt im Sonnensystem [5]. Doch sollte das flüssige Wasser dort bereits Milliarden Jahre alt sein, wären die Bedingungen lange genug stabil, damit Leben entstehen könnte. Sein genaues Alter ist jedoch derzeit noch ungewiss.
Unabhängig davon zeigen die Forschungsergebnisse einmal mehr, warum Enceladus als einer der vielversprechendsten Orte im Sonnensystem für die Suche nach Leben gilt. Mit seinem stabilen thermischen Gleichgewicht, der reichen organischen Chemie und dem direkten Zugang zu seinem Ozean durch die Geysire bietet er einzigartige Möglichkeiten für die Astrobiologie.
URL dieses Artikels:https://www.heise.de/-11099752
Links in diesem Artikel:[1] https://www.science.org/doi/10.1126/sciadv.adx4338[2] https://www.nature.com/articles/s41550-025-02655-y[3] https://www.nasa.gov/missions/cassini/nasa-cassini-study-finds-organics-fresh-from-ocean-of-enceladus/[4] https://de.wikipedia.org/wiki/CHNOPS[5] https://www.businessinsider.com/water-space-volume-planets-moons-2016-10
Copyright © 2025 Heise Medien
Neu in WordPress 6.9: Das Anheften von Notizen an Blöcken
(Bild: WordPress)
WordPress 6.9 "Gene" konzentriert sich auf verbesserte Zusammenarbeit, neue Blöcke, schnellere Ladezeiten und Grundlagen für die KI-Integration.
Das Content-Management-System WordPress ist in Version 6.9 erschienen. Das in Anlehnung an den US-amerikanischen Jazz-Pianisten Gene Harris mit dem Codenamen „Gene“ bezeichnete Update [1] legt einen Schwerpunkt auf neue Funktionen zur Zusammenarbeit, enthält neue Blöcke und soll deutlich schnellere Ladezeiten ermöglichen. Zudem wurden Grundlagen zur KI-Integration geschaffen.
Die zweite und letzte große Aktualisierung des Jahres 2025 ermöglicht das Anheften von Notizen an Blöcken. Dies soll das gemeinsame Arbeiten an Inhalten deutlich vereinfachen. Nutzer können so Kommentare und Feedback direkt an den angesprochenen Teilen einer Seite hinterlassen. Die neue Funktion soll die Erfordernis externer Kommunikations-Tools und Feedback-Systeme deutlich reduzieren.
Neu ist auch, dass Blöcke mit einem Klick ausgeblendet werden können, aber im Editor sichtbar bleiben. Auf diese Weise können sie zum Beispiel für saisonale Inhalte oder für die schrittweise Entwicklung einer Seite leichter aktiviert werden.
Bei den Blöcken gibt es mit WordPress 6.9 dank Ergänzungen neue Gestaltungsmöglichkeiten. Der Accordion-Block ermöglicht aufklappbare Inhalte mit individueller Gestaltung, während der Math-Block mathematische Formeln in MathML und LaTeX darstellt.
Aus typografischer Sicht interessant: Die neue „Fit Text"-Funktion in Paragraph- und Heading-Blöcken passt die Schriftgröße automatisch an die Container-Größe an – die Notwendigkeit, hierfür eigene Style Sheets anzulegen (Custom CSS) soll damit entfallen.
WordPress soll mit dem Update zudem deutlich schneller werden: Dazu sollen Block-Styles bei Classic Themes und minifizierte Styles bei Block Themes bei Bedarf geladen werden. Nicht-kritische Skripte wie die für interaktive Blöcke oder Emoji-Erkennung werden zurückgestellt. Hinzu kommen optimierte Datenbankabfragen, verbessertes Caching und ein neuer Template Enhancement Output Buffer.
Um WordPress für den Einsatz von KI fit zu machen, wurde die Entwicklerschnittstelle Abilities API eingeführt. Damit stehe ein standardisiertes, maschinenlesbares System bereit, mit dem Core-Funktionen, Plugins und Themes ihre Funktionalitäten registrieren können. Die API ist Teil der „AI Building Blocks for WordPress"-Initiative und soll KI-Assistenten und Automatisierungsplattformen künftig ermöglichen, WordPress-Funktionen zu verstehen und auszuführen.
Weitere interessante Neuigkeiten sind der Beta-Support für PHP 8.5 und die Vorbereitung der Iframe-Integration im Post-Editor. Die wp_mail()-Funktion unterstützt jetzt Inline-Bilder in HTML-E-Mails und wurde robuster gegen Header-Injection-Angriffe.
An WordPress 6.9 (Release Notes [2]) haben über 900 Menschen aus aller Welt mitgearbeitet.
URL dieses Artikels:
https://www.heise.de/-11101303
Links in diesem Artikel:
[1] https://wordpress.org/news/2025/12/gene/
[2] https://make.wordpress.org/core/tag/dev-notes+6-9/
[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
(Bild: programmier.bar)
Wie wird aus einem Beweis an sich selbst eine Karriere durch bekannteste Tech-Stationen? CTO und CPO Dirk Daumann erzählt von seinen prägendsten Entscheidungen.
Dirk Daumanns beruflicher Werdegang führt durch eine Reihe bekannter Technologieunternehmen. Im CTO-Special gibt er einen Einblick in zentrale Entscheidungen seiner Karriere und erläutert, welche Motive ihn über die Jahre begleitet haben.
Heute verantwortet Dirk Daumann [1] bei Blacklane eine hybride Rolle als CPO und CTO. Der Einstieg in die Technik erfolgte aus einem persönlichen Antrieb heraus: dem Wunsch, sich selbst zu beweisen, dass mathematische Fähigkeiten über das hinausgehen, was die Schulzeit vermuten ließ. Ein Physikstudium bildete dafür die Grundlage und öffnete den Weg zu Positionen bei HERE Maps, Skype, Klarna, Joyn, sennder und Flink.
Im Podcast beschreibt Dirk Daumann die unterschiedlichen Unternehmenskulturen, Herausforderungen und Lernprozesse, die seinen Werdegang geprägt haben.
Die aktuelle Ausgabe des Podcasts steht auch im Blog der programmier.bar [3] bereit: „Dirk Daumann von Blacklane“ [4]. Fragen und Anregungen gerne per Mail [5] oder via Mastodon [6], Bluesky [7], LinkedIn [8] oder Instagram [9].
URL dieses Artikels:
https://www.heise.de/-11101191
Links in diesem Artikel:
[1] https://www.linkedin.com/in/pptengineer/?originalSubdomain=de
[2] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[3] https://programmier.bar/
[4] https://www.programmier.bar/podcast/cto-special-36-dirk-daumann-von-blacklane
[5] mailto:podcast@programmier.bar
[6] https://social.programmier.bar/@podcast
[7] https://bsky.app/profile/programmier.bar
[8] https://www.linkedin.com/company/programmier-bar
[9] https://www.instagram.com/programmier.bar/
[10] mailto:mdo@ix.de
Copyright © 2025 Heise Medien
(Bild: sdecoret / shutterstock.com)
KI generiert Code, aber wer entscheidet, welcher Code entstehen soll? Warum Architektur und Domänenwissen jetzt wichtiger werden, nicht weniger.
Vor einigen Monaten habe ich an dieser Stelle beschrieben, wie künstliche Intelligenz die Softwareentwicklung verändert [1] und warum bestimmte Tätigkeiten in diesem Berufsfeld mittelfristig wegfallen werden. Die Reaktionen darauf waren gemischt: von Zustimmung über Skepsis bis hin zu offener Ablehnung. Doch eine Frage tauchte in den Kommentaren und in Gesprächen auf Konferenzen immer wieder auf: Wenn KI tatsächlich Code schreiben kann, was bleibt dann für Menschen übrig?
Diese Frage ist berechtigt. Sie verdient eine ehrliche Antwort. Und diese Antwort führt uns zu einem Thema, das in der Debatte um KI in der Softwareentwicklung oft zu kurz kommt: die Rolle der Architektur, des Domänenwissens und der konzeptuellen Arbeit. Meine These lautet: Diese Bereiche werden nicht weniger wichtig, sondern wichtiger. Die Wertschöpfung verschiebt sich von der Umsetzung zur Konzeption. Und genau das hat weitreichende Konsequenzen für alle, die in diesem Feld arbeiten, von der Entwicklerin am Anfang ihrer Karriere bis zur Führungskraft, die Investitionsentscheidungen trifft.
Beginnen wir mit einer ehrlichen Bestandsaufnahme dessen, was moderne KI-Systeme im Bereich der Softwareentwicklung leisten. Die Fortschritte der letzten zwei Jahre sind beeindruckend, und wer sie leugnet, macht sich etwas vor. LLMs (Large Language Models) können heute Funktionen, Klassen und ganze Module auf Zuruf generieren. Sie erkennen Muster in bestehendem Code und wenden Best Practices an, ohne dass man sie explizit darauf hinweisen muss. Sie schreiben Tests, die tatsächlich sinnvolle Randfälle abdecken. Sie erstellen Dokumentation, die oft besser ist als das, was überarbeitete Entwickler um 23 Uhr produzieren. Sie schlagen Refactorings vor, die technische Schulden reduzieren.
Wer heute mit GitHub Copilot, Claude, ChatGPT oder ähnlichen Werkzeugen arbeitet, erlebt täglich, wie viel Routinearbeit diese Systeme abnehmen können. Eine REST-API mit Standard-CRUD-Operationen, die früher einen halben Tag gekostet hätte, entsteht in dreißig Minuten. Ein Datenmigrationsskript, für das man früher Stack Overflow durchsucht hätte, generiert sich fast von selbst. Das ist real, das ist nützlich, und es wird noch besser werden.
Das ist die beeindruckende Seite. Und sie wird noch beeindruckender werden. Die Modelle werden besser, die Integration in Entwicklungsumgebungen wird nahtloser, die Anwendungsfälle werden breiter. Wer glaubt, dass wir den Höhepunkt dieser Entwicklung bereits erreicht haben, unterschätzt das Tempo des Fortschritts.
Doch es gibt auch blinde Flecken, die bei aller Euphorie nicht übersehen werden dürfen. Und diese Flecken werden nicht kleiner, wenn die Modelle größer werden – denn sie sind struktureller Natur.
KI-Systeme arbeiten auf der Ebene von Syntax und Mustern. Sie haben gelernt, welche Codezeilen typischerweise auf welche anderen folgen. Sie wissen, wie ein Repository-Pattern in C# aussieht, weil sie Zehntausende davon gesehen haben. Aber sie wissen nicht, warum ein bestimmtes System dieses Pattern verwenden sollte, oder ob es überhaupt das Richtige ist. Sie kennen die Form, nicht die Bedeutung.
Das zeigt sich besonders deutlich bei Halluzinationen. Ein LLM kann eine Funktion generieren, die syntaktisch korrekt ist, alle Konventionen einhält und auf den ersten Blick vernünftig aussieht, aber inhaltlich falsch ist. Nicht, weil das Modell lügt, sondern weil es gar nicht weiß, was „richtig“ in einem bestimmten fachlichen Kontext bedeutet. Es optimiert Wahrscheinlichkeiten für Zeichenfolgen, nicht für Geschäftslogik. Es produziert, was statistisch plausibel ist, nicht was sachlich korrekt ist.
Hinzu kommt das Problem des lokalen Optimums: KI optimiert das Offensichtliche. Wenn Sie nach einer Lösung für ein Problem fragen, bekommen Sie die wahrscheinlichste Lösung basierend auf den Trainingsdaten. Das ist oft eine gute Lösung. Aber es ist selten die beste Lösung für Ihren spezifischen Kontext, denn den kennt das Modell nicht. Es weiß nicht, dass Ihr Team nur aus zwei Personen besteht und keine Zeit für eine Microservices-Architektur hat. Es weiß nicht, dass Ihre Datenbank-Performance der eigentliche Engpass ist. Es weiß nicht, dass der Fachbereich nächstes Jahr alles umwerfen wird.
Die Schlussfolgerung daraus ist einfach: KI ist ein hervorragendes Werkzeug für die Umsetzung. Aber das setzt voraus, dass jemand weiß, was umgesetzt werden soll. Die entscheidende Frage verschiebt sich damit von „Wie schreibe ich diesen Code?“ zu „Welchen Code sollte ich überhaupt schreiben?“. Und diese Frage kann KI nicht beantworten.
Damit sind wir bei der Architektur. Und hier lohnt es sich, zunächst zu klären, was dieser Begriff eigentlich bedeutet, denn er wird (zu) oft missverstanden.
Architektur ist nicht das Diagramm mit den großen Boxen und Pfeilen, das in jeder Projektdokumentation auftaucht und nach dem Kick-Off nie wieder angeschaut wird. Architektur ist auch nicht die Entscheidung für ein bestimmtes Framework oder eine bestimmte Cloud-Plattform. Architektur ist vielmehr die Summe der Entscheidungen, die schwer zu ändern sind. Es sind die Entscheidungen über Struktur, über Kommunikationswege, über Grenzen zwischen Komponenten, über Verantwortlichkeiten. Es sind die Entscheidungen, bei denen eine Änderung später teuer wird, sei es technisch, organisatorisch oder beides.
Diese Entscheidungen sind aus mehreren Gründen nicht automatisierbar. Und diese Gründe werden auch nicht verschwinden, wenn die Modelle größer werden.
Erstens erfordern Architekturentscheidungen Kontextwissen, das nicht im Code steht. Um zu entscheiden, ob ein System als Monolith oder als verteiltes System gebaut werden sollte, muss man die Organisation kennen, die es betreibt. Wie groß ist das Team? Wie sind die Deployment-Zyklen? Welche Teile des Systems ändern sich häufig, welche selten? Wie sieht die bestehende Infrastruktur aus? Welche Kompetenzen sind vorhanden, welche fehlen? Diese Informationen stehen in keinem Repository. Sie existieren in Köpfen, in Gesprächen, in der gelebten Praxis einer Organisation.
Zweitens erfordern Architekturentscheidungen Abwägungen zwischen konkurrierenden Zielen. Soll das System maximal performant sein oder maximal wartbar? Soll es schnell ausgeliefert werden oder langfristig stabil sein? Soll es flexibel erweiterbar sein oder einfach zu verstehen? Diese Trade-offs haben keine objektiv richtige Antwort. Sie hängen von Prioritäten ab, die Menschen setzen müssen, basierend auf Geschäftszielen, Ressourcen und Risikobereitschaft.
Drittens erfordern sie Voraussicht. Was könnte sich in zwei Jahren ändern? Welche Annahmen, die wir heute treffen, werden sich als falsch herausstellen? Welche Teile des Systems müssen flexibel bleiben, welche dürfen in Beton gegossen werden? Wo lohnt sich Investition in Abstraktion, wo ist sie Over-Engineering? Diese Fragen erfordern Erfahrung, Intuition und die Fähigkeit, mit Unsicherheit umzugehen. Sie erfordern das, was erfahrene Architekten „Bauchgefühl“ nennen: eine internalisierte Mustererkennung, die sich nicht in Regeln fassen lässt.
Viertens erfordern sie Dialog. Architektur entsteht nicht im stillen Kämmerlein. Sie entsteht im Gespräch mit Fachbereichen, mit Stakeholdern, mit dem Entwicklungsteam. Sie erfordert die Fähigkeit, zuzuhören, nachzufragen, zwischen verschiedenen Welten zu übersetzen. Ein Architekt muss verstehen, was der Vertrieb meint, wenn er von „flexiblen Rabatten“ spricht, und das in eine technische Struktur übersetzen. Diese Übersetzungsleistung ist zutiefst menschlich.
Es gibt noch einen fünften Punkt, der oft übersehen wird: Architekturentscheidungen sind soziale Akte. Sie formen Teams, sie definieren Schnittstellen zwischen Menschen, sie beeinflussen, wer mit wem zusammenarbeiten muss. Die Entscheidung, ein System in drei Services aufzuteilen, ist nicht nur eine technische Entscheidung. Sie ist auch eine Entscheidung darüber, wie die Arbeit verteilt wird, welche Teams entstehen, wie Kommunikation fließt. Diese organisatorischen Implikationen zu verstehen und zu gestalten, erfordert Einfühlungsvermögen und politisches Gespür. All das sind Eigenschaften, die kein Sprachmodell besitzt.
Ein LLM kann das Observer Pattern implementieren. Aber es kann nicht entscheiden, wann dieses Pattern die richtige Wahl ist. Es kann Microservices generieren. Aber es kann nicht beurteilen, ob Microservices für eine bestimmte Organisation überhaupt sinnvoll sind, oder ob sie die Komplexität nur verlagern, statt sie zu reduzieren. Die wertvollste Architekturentscheidung ist oft die Entscheidung, etwas nicht zu bauen. Und genau diese Entscheidung liegt außerhalb dessen, was ein generatives Modell leisten kann.
Das führt uns zum zweiten Bereich, der durch KI nicht ersetzt wird: das Domänenwissen.
Jede Software existiert, um ein Problem in einer bestimmten Domäne zu lösen [2]. Ein Bestellsystem löst Probleme im E-Commerce. Eine Patientenakte löst Probleme im Gesundheitswesen. Eine Handelssoftware löst Probleme an den Finanzmärkten. Eine Produktionssteuerung löst Probleme in der Fertigung. Die Software ist nie Selbstzweck. Sie ist immer Mittel zu einem fachlichen Zweck. Diese Erkenntnis klingt banal, wird aber in der Praxis erstaunlich oft vergessen.
Um gute Software zu bauen, muss man diesen Zweck verstehen. Man muss die Domäne verstehen. Und genau hier stößt KI an eine fundamentale Grenze, die sich nicht durch größere Modelle oder bessere Trainingsdaten überwinden lässt.
LLMs wurden auf öffentlich verfügbarem Text trainiert. Sie kennen, was über Domänen geschrieben wurde. Sie kennen die allgemeinen Konzepte von Bestellungen, Patienten, Handelspositionen, Fertigungsaufträgen. Aber sie kennen nicht die spezifische Logik eines bestimmten Unternehmens. Sie wissen nicht, dass in Ihrem Unternehmen eine „Bestellung“ drei verschiedene Zustände haben kann, die nirgendwo dokumentiert sind, weil das historisch so gewachsen ist. Sie wissen nicht, dass der Begriff „Kunde“ in der Buchhaltung etwas anderes bedeutet als im Vertrieb. Sie wissen nicht, dass bestimmte Produkte aus regulatorischen Gründen anders behandelt werden müssen als andere.
Die richtige Frage ist nicht „Wie baue ich ein Bestellsystem?“. Die richtige Frage ist: „Was bedeutet eine Bestellung in diesem Geschäft? Wann beginnt sie? Wann endet sie? Was passiert, wenn sie storniert wird? Was passiert, wenn sie teilweise geliefert wird? Wer darf sie ändern, und unter welchen Bedingungen? Welche Ereignisse in der Domäne sind relevant, welche nicht?“
Diese Fragen lassen sich nicht durch Prompt-Engineering beantworten. Sie erfordern Gespräche mit Fachexperten. Sie erfordern das geduldige Herausarbeiten von implizitem Wissen, das oft nicht einmal den Fachleuten selbst bewusst ist. Es ist Wissen, das in Routinen steckt, in Ausnahmen. In den Geschichten, die erzählt werden, wenn etwas schiefgelaufen ist. Dieses Wissen sichtbar zu machen, erfordert Methoden wie Event-Storming oder Collaborative Modeling, bei denen Menschen gemeinsam an einem Whiteboard stehen und rekonstruieren, was in ihrer Domäne eigentlich passiert.
Das ist zutiefst menschliche Arbeit. Es ist Arbeit, die Geduld erfordert, die Ambiguitätstoleranz verlangt, die manchmal frustrierend ist, weil die Antworten nicht sofort klar sind. Es ist Arbeit, die man nicht beschleunigen kann, indem man schneller tippt. Und genau deshalb wird sie durch KI nicht obsolet, sondern im Gegenteil: Je mehr die Umsetzung automatisiert wird, desto wichtiger wird es, das Richtige umzusetzen. Und um das Richtige zu identifizieren, benötigt man Domänenwissen.
Ich erlebe in meiner Beratungsarbeit regelmäßig, dass Projekte scheitern, nicht weil die Technik schlecht wäre, sondern weil niemand die richtigen Fragen gestellt hat. Das neue System wurde gebaut, es funktioniert technisch einwandfrei – aber es bildet die falschen Prozesse ab, verwendet die falschen Begriffe, macht die falschen Annahmen. Das sind keine Fehler, die KI verhindern wird. Es sind Fehler, die entstehen, wenn man die Domäne nicht versteht. Und sie werden häufiger werden, wenn die Illusion entsteht, dass schnelle Codegenerierung auch schnelles Verstehen bedeutet.
Was bedeutet das alles für die Praxis? Wie verändert sich die Arbeitsteilung in der Softwareentwicklung? Diese Fragen höre ich oft, und die Antworten sind weniger düster, als manche befürchten. Vorausgesetzt, man versteht die Richtung der Veränderung.
Zunächst das Offensichtliche: Routineaufgaben werden schneller und günstiger. Code, der früher Stunden gebraucht hat, entsteht heute in Minuten. Die Einstiegshürde „etwas zu bauen“ sinkt dramatisch. Das ist grundsätzlich positiv. Es demokratisiert den Zugang zur Softwareentwicklung und ermöglicht schnellere Experimente. Ideen können ausprobiert werden, bevor man sich auf eine teure Implementierung festlegt.
Aber es birgt auch eine Gefahr: die Gefahr, das Falsche sehr effizient zu bauen. Wenn es einfach wird, Code zu generieren, besteht die Versuchung, sofort loszulegen, ohne vorher gründlich nachzudenken. Das Ergebnis sind Systeme, die technisch funktionieren, aber am eigentlichen Bedarf vorbeigehen. Oder Systeme, die kurzfristig funktionieren, aber langfristig nicht wartbar sind. Die Geschwindigkeit der Codegenerierung kann eine trügerische Sicherheit vermitteln. Man fühlt sich produktiv, obwohl man eigentlich nur schneller in die falsche Richtung läuft.
Bestimmte Fähigkeiten werden in dieser neuen Welt wichtiger:
Andere Fähigkeiten verlieren an Bedeutung. APIs und Syntax auswendig zu kennen, wird weniger wertvoll, wenn man jederzeit nachfragen kann. Boilerplate-Code zu schreiben war nie besonders erfüllend und wird künftig noch weniger nötig sein. Routine-Debugging bei Standardproblemen lässt sich zunehmend automatisieren. Das ist kein Verlust, sondern eine Befreiung, vorausgesetzt, man nutzt die gewonnene Zeit für wertvollere Tätigkeiten.
Eine besondere Warnung möchte ich an dieser Stelle aussprechen: Hüten Sie sich vor der Prompt-Engineering-Illusion. Die Vorstellung, dass man nur „die richtige Frage stellen“ müsse, um von KI perfekte Ergebnisse zu bekommen, ist gefährlich. Ja, gute Prompts führen zu besseren Ergebnissen. Aber wer die richtige Frage nicht kennt, bekommt bestenfalls plausible Antworten auf die falsche Frage. Prompt Engineering ersetzt kein Domänenwissen. Es setzt es voraus. Wer nicht versteht, was gebaut werden soll, kann auch nicht sinnvoll danach fragen.
Lassen Sie mich mit konkreten Empfehlungen schließen.
Für Entwicklerinnen und Entwickler: Nutzen Sie KI als Werkzeug, nicht als Ersatz für das Denken. Lassen Sie sich Routinearbeit abnehmen, aber geben Sie die Verantwortung für das Ergebnis nicht ab. Prüfen Sie generierten Code kritisch, verstehen Sie ihn, bevor Sie ihn committen. Investieren Sie in Architektur und Domänenwissen, nicht nur in Technologie. Lernen Sie, mit Fachbereichen auf Augenhöhe zu sprechen. Kultivieren Sie die Fähigkeit, Anforderungen zu hinterfragen, statt sie blind umzusetzen. Die Frage „Warum benötigen wir das?“ ist wertvoller als die Frage „Wie bauen wir das?“.
Für Führungskräfte und Unternehmen: Widerstehen Sie der Versuchung, „alles mit KI zu machen“. Die Technologie ist mächtig, aber sie ist kein Ersatz für Nachdenken. Erkennen Sie Architektur- und Domänenkompetenz als strategisches Asset. Diese Fähigkeiten lassen sich nicht kurzfristig einkaufen oder durch Tools ersetzen. Sie entstehen über Jahre, durch Erfahrung, durch Fehler, durch intensive Beschäftigung mit einer Domäne. Investieren Sie in Menschen, die verstehen, nicht nur in Tools, die generieren. Und stellen Sie sich regelmäßig die Frage: Wissen wir eigentlich, was wir bauen wollen? Wenn die Antwort unklar ist, wird auch die beste KI nicht helfen.
Für die Ausbildung: Der Fokus auf Syntax und Programmiersprachen wird weniger wichtig. Konzepte, Modellierung und Abstraktion werden wichtiger. Interdisziplinäres Denken sollte gefördert werden, also die Fähigkeit, technische und fachliche Perspektiven zu verbinden. Und vor allem: die Fähigkeit, mit Unsicherheit umzugehen. Denn in einer Welt, in der sich Technologie schnell verändert, ist die Bereitschaft zum lebenslangen Lernen wichtiger als jedes spezifische Wissen. Die Absolventen von heute werden in ihrer Karriere Technologien nutzen, die heute noch nicht existieren. Was bleibt, sind die Grundlagen: logisches Denken, Abstraktion, Kommunikation.
Die Entwicklung, die wir gerade erleben, ist keine Bedrohung, sondern eine Verschiebung. Dabei wandert die Wertschöpfung von der Umsetzung zur Konzeption. Die Frage ist nicht mehr „Können wir das bauen?“, denn das können wir fast immer, und es wird immer einfacher. Die Frage ist: „Sollten wir das bauen? Und wenn ja, was genau? Für wen? Mit welchem Ziel?“
Diese Fragen zu beantworten, erfordert etwas, das KI nicht hat: ein Verständnis von Bedeutung. Software ist nicht nur Code. Sie ist ein Ausdruck von Geschäftslogik, von Prozessen, von menschlichen Bedürfnissen. Sie bildet ab, wie Menschen arbeiten, wie sie kommunizieren, wie sie Entscheidungen treffen. Den Sinn hinter dem Code zu verstehen und zu gestalten, das bleibt menschliche Arbeit.
Architekten, Domänenexperten und konzeptuelle Denker werden in dieser neuen Welt nicht weniger gebraucht. Sie werden mehr gebraucht. Denn je leichter es wird, irgendetwas zu bauen, desto wichtiger wird es, das Richtige zu bauen. Die Fähigkeit, das Richtige zu identifizieren, wird zur Kernkompetenz. Und diese Kompetenz ist nicht angeboren. Sie lässt sich entwickeln. Wer heute anfängt, in Architekturdenken und Domänenverständnis zu investieren, wird in fünf Jahren einen erheblichen Vorsprung denen gegenüber haben, die nur auf das nächste Tool warten.
Software war nie Selbstzweck. Sie war immer Mittel zu einem Zweck. Und den Zweck definieren Menschen. Das war vor dreißig Jahren so, das ist heute so, und das wird auch in zehn Jahren noch so sein – egal, wie leistungsfähig die Modelle dann geworden sind.
Die gute Nachricht ist: Wer diese Verschiebung versteht und sich darauf einstellt, hat eine glänzende Zukunft. Wer hingegen glaubt, dass es reicht, Code zu schreiben, der sollte sich Gedanken machen. Nicht, weil KI alles übernimmt. Sondern weil KI das übernimmt, was sich automatisieren lässt. Was bleibt, ist das, was sich nicht automatisieren lässt: Verstehen, Entscheiden, Gestalten. Das sind die Fähigkeiten, in die es sich zu investieren lohnt.
URL dieses Artikels:
https://www.heise.de/-11097760
Links in diesem Artikel:
[1] https://www.heise.de/blog/Softwareentwicklung-Lern-bloss-nicht-programmieren-10493709.html
[2] https://www.youtube.com/watch?v=E9yx9w3GJk0
[3] mailto:rme@ix.de
Copyright © 2025 Heise Medien
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Viele moderne Prozessoren vereinen unterschiedliche CPU-Kerne. Dafür gibt es verschiedene Konzepte, erklärt Folge 2025/25 des Podcasts Bit-Rauschen.
Seit einigen Jahren gibt es auch für Notebooks und Desktop-PCs Prozessoren mit verschiedenen Typen von CPU-Kernen: P- und E-Kerne. P steht dabei für Performance, E für Effizienz. Aber so einfach ist es natürlich nicht.
Das Konzept der hybriden Prozessoren kam im Massenmarkt zuerst bei Smartphone-Chips mit ARM-Kernen zum Einsatz. Dort startete es unter dem Namen big.LITTLE. Häufig kombinierten die Chiphersteller dabei wenige P-Kerne mit hoher Taktfrequenz, großen Caches und Out-of-Order-Architektur mit mehreren Effizienzkernen. Letztere hatten beispielsweise In-Order-Mikroarchitektur, takteten niedriger und hatten viel weniger Cache. Das genügt für viele Hintergrundaufgaben.
Heutzutage gibt es ganz unterschiedliche Konzepte, etwa mehrere unterschiedliche E-Kerne, von denen manche beim Multithreading kräftig anschieben. Und einige Smartphone-Chips verzichten auf E-Kerne, sondern setzen auf unterschiedlich ausgelegte P-Kerne. Und ein ganz exotisches Konzept sind Intels Supercores [7], die aus mehreren E-Kernen dynamisch einen P-Kern machen.
Die c’t-Redakteure Christian Hirsch [8] und Christof Windeck [9] diskutieren über die vielen unterschiedlichen Konzepte in Folge 2025/25 von "Bit-Rauschen, der Prozessor-Podcast von c’t".
Podcast Bit-Rauschen, Folge 2025/25 :
Wir freuen uns über Anregungen, Lob und Kritik zum Bit-Rauschen. Rückmeldungen gerne per E-Mail an bit-rauschen@ct.de [11].
Alle Folgen unseres Podcasts sowie die c’t-Kolumne Bit-Rauschen finden Sie unter www.ct.de/Bit-Rauschen [12]
Viele weitere Podcasts finden Sie unter heise.de/podcasts [13].
URL dieses Artikels:
https://www.heise.de/-11081417
Links in diesem Artikel:
[1] https://ct.de/bit-rauschen
[2] https://Bit-Rauschen.podigee.io/feed/mp3
[3] https://podcasts.apple.com/de/podcast/bit-rauschen-der-prozessor-podcast-von-ct/id1549821753
[4] https://open.spotify.com/show/6JD6gwqgVR27GYZACrWOT1
[5] https://podcasts.google.com/feed/aHR0cHM6Ly9iaXQtcmF1c2NoZW4ucG9kaWdlZS5pby9mZWVkL21wMw
[6] https://www.deezer.com/de/show/2195452
[7] https://www.heise.de/news/Intel-plant-virtuelle-Super-Prozessorkerne-10626845.html
[8] https://www.heise.de/autor/Christian-Hirsch-3691966
[9] https://www.heise.de/autor/Christof-Windeck-3687176
[10] https://www.heise.de/Datenschutzerklaerung-der-Heise-Medien-GmbH-Co-KG-4860.html
[11] mailto:bit-rauschen@ct.de
[12] https://www.heise.de/meinung/Bit-Rauschen-Der-Prozessor-Podcast-von-c-t-4914290.html
[13] http://heise.de/podcasts
[14] https://www.heise.de/ct
[15] mailto:ciw@ct.de
Copyright © 2025 Heise Medien
Marcel Kunzmann
Triebwerk einer (älteren) Sojus-Rakete
(Bild: Ivanova Ksenia/Shutterstock.com)
Nach fast einem Jahrzehnt Entwicklung steht Russlands Sojus-5-Rakete vor dem Erstflug. Doch der Ukraine-Krieg hat den Markt für russische Raketen verändert.
Russlands Raumfahrtbehörde Roskosmos steht vor dem Start ihrer neuen Mittelklasse-Rakete Sojus-5 [1], auch Irtysch genannt, die das veraltete Proton-System ersetzen soll. Nach Angaben von Ministerpräsident Michail Mischustin ist der Erstflug für den 24. Dezember 2025 vom Weltraumbahnhof Baikonur geplant [2], nachdem die Entwicklung inzwischen abgeschlossen werden konnte.
Die Rakete ist 65,3 Meter hoch, hat einen Durchmesser von 4,1 Metern und kann bis zu 18 Tonnen Nutzlast in eine niedrige Erdumlaufbahn befördern. Das Herzstück bildet das RD-171MV-Triebwerk der ersten Stufe, das vom Hersteller NPO Energomasch als weltweit leistungsstärkstes Flüssigkeitstriebwerk beworben wird. Mit einem Schub von 800 Tonnen ist es dreimal stärker als ein einzelnes Raptor-3-Triebwerk von SpaceX [3].
Die Entwicklung der Sojus-5 begann vor fast einem Jahrzehnt, wobei das Vordesign 2017 abgeschlossen wurde. Russland wollte damit nicht nur den alternden Proton-Träger ersetzen, sondern auch preislich mit SpaceX' Falcon-9-Rakete konkurrieren können, wie die Fachpublikation Ars Technica berichtet [4].
Ein weiterer Grund war die Reduzierung der Abhängigkeit von ukrainischer Technologie. Die frühere Zenit-2-Rakete aus der Sowjetzeit wurde vom Konstruktionsbüro Juschnoye in Dnipro entwickelt und ihre ersten beiden Stufen in der Ukraine gefertigt. Das RD-171MV-Triebwerk verwendet nach Angaben von Roskosmos ausschließlich russische Komponenten.
Daniil Subbotin, stellvertretender Geschäftsführer des Progress-Zentrums für Entwicklung, hatte gegenüber der Nachrichtenagentur TASS bestätigt, dass die Rakete Ende 2025 startbereit sein werde. Im Oktober 2025 meldete Roskosmos den Abschluss der Bodentests der ersten Stufe in Moskau, wobei das RD-171MV-Triebwerk 160 Sekunden lang lief.
Die zentrale Frage bleibt jedoch, welchen Markt die Sojus-5 bedienen wird. Der Ukraine-Krieg hat russische Raketen für viele westliche Satellitenbetreiber vom Tisch genommen. Gleichzeitig ist die Zahl der jährlich gestarteten geostationären Satelliten, einst das Hauptgeschäft der Proton-Rakete, stark zurückgegangen.
Die Sojus-5 ordnet sich leistungsmäßig zwischen der Sojus-2 und der Angara-A5-Rakete ein. Während Russland bereits über die Sojus-2 für Besatzungs- und Frachtmissionen zur Internationalen Raumstation verfügt, sowie über die Angara-Raketenfamilie, ist unklar, welche Nachfrage für eine Rakete mit 18 Tonnen Kapazität in die niedrige Erdumlaufbahn besteht.
Die internationale Konkurrenz im Mittelklasse-Segment hat sich verschärft. China [5] verfügt über eine wachsende Zahl staatlicher und kommerzieller Optionen, auch Indiens Startangebote wachsen. Für preisbewusste Kunden kann Russland wahrscheinlich nicht mit der wiederverwendbaren Falcon-9 von SpaceX mithalten, so die Analyse von Ars Technica.
Gleichwohl dürfte die Entwicklung für Russland primär auch mit Blick auf die Souveränität und Modernisierung der eigenen Raketentechnologie von Nutzen sein. Russland setzt bei der Sojus-5 seit 2018 moderne Technologien wie 3D-Druck und digitales Design ein, um die Produktion zu optimieren und Verzögerungen wie beim Angara-Programm zu vermeiden. Die zweite Stufe verwendet zwei RD-0124MS-Triebwerke, die dritte Stufe Block DM oder Fregat-SBU.
Roskosmos plant auch, die Sojus-5 als Booster-Stufe für eine Schwerlastrakete namens Jenissei zu verwenden, die für ein bemanntes Mondprogramm gedacht ist. Dieses Projekt befindet sich jedoch in einem unklaren Entwicklungsstadium.
Die Raumfahrtbehörde strebt an, 30 Raketen pro Jahr zu starten – doppelt so viele wie derzeit – und in den nächsten zehn Jahren 1.000 Raumfahrzeuge zu befördern. Weitere Demonstrationsflüge sind vor dem vollständigen Betrieb 2028 geplant.
URL dieses Artikels:https://www.heise.de/-11099963
Links in diesem Artikel:[1] https://en.wikipedia.org/wiki/Irtysh_(rocket)[2] https://tass.com/science/1661733[3] https://www.telepolis.de/thema/SpaceX[4] https://arstechnica.com/space/2025/11/after-a-decade-russias-native-built-soyuz-5-rocket-finally-reaches-the-launch-site/[5] https://www.heise.de/tp/article/Starship-aus-Fernost-Chinas-neue-Schwerlastrakete-wird-wiederverwendbar-10004602.html
Copyright © 2025 Heise Medien
15 Bundesländer würden laut einem gemeinsamen Beschluss den Deutschland-Stack übernehmen, wenn der Bund diesen bezahlt. Nur Bayern stimmte gegen den Vorschlag.
Fast alle Bundesländer haben sich bereit erklärt, den von der Bundesregierung angekündigten „Deutschland-Stack [1]“ zu übernehmen – unter den Voraussetzungen, dass der Bund den Stack finanziert und dieser zur sogenannten „Deutschland-Architektur“ kompatibel bleibt. Der Bund solle die „investiven und konsumtiven Kosten des verbindlichen Plattformkerns“ tragen, heißt es in einem aktuellen Beschluss der Digitalministerkonferenz der Länder. Im Gegenzug könne der Bund den Plattformkern definieren und für verbindlich erklären.
Der Beschluss [2] (PDF) der Digitalministerkonferenz [3] ist bemerkenswert, weil bislang viele Bundesländer bei der Gestaltung von ebenenübergreifend eingesetzten IT-Systemen gleichberechtigt mitbestimmen wollten. So haben Bund und Länder zum Beispiel für die „Datenautobahn“ NOOTS [4] eine Steuerungsgruppe eingerichtet. In dem nun veröffentlichten Länder-Beschluss zum Deutschland-Stack ist nur noch von Konsultation und Einbeziehung die Rede. Hinzu kommt, dass die Bundesregierung noch gar nicht festgelegt hat, woraus der Deutschland-Stack bestehen soll. Noch bis zum 30. November führte das Bundesministerium für Digitales und Staatsmodernisierung ein Konsultationsverfahren durch.
Als einziges Bundesland lehnte Bayern den Beschlussvorschlag in der Digitalministerkonferenz ab. "Wir beteiligen uns gerne und aus Überzeugung an der Konzeption des Deutschland-Stacks, kaufen die sprichwörtliche Katze aber nicht im Sack", sagte ein Sprecher von Digitalminister Fabian Mehring (Freie Wähler) gegenüber c’t. Bevor über eine verbindliche Nutzung sowie die Finanzierungsstruktur des Deutschland-Stacks entschieden werden könne, müssten zunächst inhaltliche Fragen geklärt werden. Grundsätzlich unterstütze man den Deutschland-Stack und sehe darin „einen Gamechanger für die erfolgreiche Gestaltung der digitalen Transformation von Staat und Verwaltung mitsamt bundesweiten Standards“, sagte der Sprecher.
Initiiert worden war der Beschluss von den Bundesländern Bremen und Hamburg. Dort verspricht man sich von der zentralen Finanzierung und Steuerung des Deutschland-Stacks ein schnelleres Vorankommen als in föderalen Gremien. „Die große Beschleunigung entsteht dadurch, dass die Entscheidung allein bei demjenigen liegt, der bezahlt“, sagte der Bremer Staatsrat Martin Hagen im Interview mit c’t. Der Deutschland-Stack solle „alle Verwaltungen in Deutschland in die Lage versetzen, schneller digitale Lösungen anzubieten, indem er eine gemeinsame technische Plattform schafft“, erklärte Hagen. Die von Bund und Ländern gemeinsam abgestimmte „Deutschland-Architektur“ sichere dabei die Kompatibilität aller Komponenten.
Ein ausführliches Interview mit dem Bremer Staatsrat Martin Hagen zum Deutschland-Stack und zur Deutschland-Architektur lesen Sie in der aktuellen Ausgabe des c’t-Newsletters D.digital. Den Newsletter können Sie hier kostenlos abonnieren [5].
URL dieses Artikels:
https://www.heise.de/-11099632
Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/Wie-der-Deutschland-Stack-den-Durchbruch-fuer-die-Digitalisierung-bringen-soll-10376056.html
[2] https://dmk.rlp.de/fileadmin/dmk/Beschluesse_4_DMK/TOP_3.3_BV_HB_Finanzierung_Government_Plattformen_final_extern.pdf
[3] https://dmk.rlp.de/
[4] https://www.heise.de/hintergrund/Das-ehrgeizigste-und-riskanteste-Digitalisierungsprojekt-Deutschlands-9844054.html
[5] https://www.heise.de/newsletter/anmeldung.html?id=ct-ddigital
[6] https://www.heise.de/ct
[7] mailto:cwo@ct.de
Copyright © 2025 Heise Medien
HPE wird seine Zusammenarbeit mit AMD mit dem Helios-System stark ausweiten. Das gab der US-Serverhersteller am 2. Dezember 2025 auf seiner Hausmesse HPE Discover in Barcelona bekannt . Als einer der ersten OEMs wird Hewlett Packard Enterprise (HPE) AMDs GPU-KI-Server-Rack einsetzen, das ab dem nächsten Jahr mit Nvidias Vera-Rubin-Plattform konkurrieren soll.
Die Ausrüster aus Houston, Texas wird Cloud-Betreibern die AMD Rack-Scale-Plattform Helios mit 72 Instinct MI455X GPUs für große KI-Workloads zur Verfügung stellen. Doch man verkauft nicht nur KI-Systeme von AMD weiter, sondern hat dafür einen sehr speziellen Netzwerk-Switch entwickelt.
Die neue HPE Tochterfirma Juniper Networks wird dafür gemeinsam mit Broadcom einen skalierbaren Netzwerk-Switch speziell für Helios Produkte bauen. Der Switch basiert auf Broadcoms Tomahawk-6-Netzwerk-Chip und nutzt den Ultra Accelerator Link over Ethernet, der als Alternative zu Nvidias NVLink entwickelt wurde. Dies soll extrem schnelle Verbindungen zwischen den 72 GPUs des Racks ermöglichen.
In einem herkömmlichen Rechenzentrum verbindet ein Switch einfach die Server. In einem KI-Cluster hat der Switch die spezialisierte Aufgabe zu ermöglichen, dass sich die vielen GPUs fast wie ein einziger riesiger Chip verhalten.
Im Rahmen der europäischen Supercomputing-Initiative arbeiten AMD und HPE zudem an Herder, einen neuen Supercomputer für das Hochleistungsrechenzentrum Stuttgart (HLRS) in Deutschland. Der Rechner basiert auf der HPE Cray GX5000-Plattform und verfügt über AMD Instinct MI430X-GPUs, sowie neue AMD EPYC-CPUs.
Die Auslieferung des Supercomputers Herder ist aber erst für die zweite Hälfte des Jahres 2027 geplant, die Inbetriebnahme dann voraussichtlich für Ende 2027.
HPE hat Juniper Networks offiziell am 2. Juli 2025 für 14 Milliarden US-Dollar übernommen. Seitdem ist Juniper eine hundertprozentige Tochtergesellschaft von Hewlett Packard Enterprise. Der Kauf wurde erstmals am 9. Januar 2024 angekündigt.
Juniper war der drittgrößte Anbieter für Router und Switches für ISPs und Telekommunikationskonzerne. HPE bündelt seit der Aufspaltung IT-Infrastruktur, Software und Services für Großunternehmen und Regierungsstellen. In der Firma HP Inc. laufen alle Druck- und PC-Produkte unter dem alten Firmenlogo. Mit Juniper bekam HPE Zugriff auf ein umfassendes Angebot von Routern, Switches, Security-Produkten wie Firewalls und Artifical Intelligenz. Konkurrent in den USA ist hier Cisco, weltweit ist es Huawei.
HPE hatte bereits im Jahr 2015 für rund 3 Milliarden US-Dollar Aruba Networks gekauft. Seit November 2015 firmiert das Unternehmen als Intelligent-Edge-Geschäftsbereich von HPE. Zu den Produkten gehören Netzwerk-Switches, Access Points, Hotspots und Wireless-Controller.
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Alle Details zur Störungsmeldung ansehen Eigene Internetstörung melden
Die Entscheidung des CA- und Browser-Forums kappt Zertifikate nach 45 Tagen. Die Änderung kommt jedoch nicht schlagartig, Admins können ausgiebig testen.
Kostenlose TLS-Zertifikate von Let’s Encrypt (LE) sind bald wesentlich kürzer gültig als gewohnt: Ihre Laufzeit sinkt von derzeit 90 Tagen auf die Hälfte. Als Certificate Authority (CA) setzt Let’s Encrypt damit eine Änderung der „Baseline Requirements“ um, die die Vergabe von Zertifikaten für die Web-PKI regeln. Zunächst schaltet LE im kommenden Mai einen Testbetrieb frei.
Am 13. Mai 2026 geht es los: Wer möchte, kann ab diesem Tag Zertifikate mit einer Laufzeit von 45 Tagen bestellen und muss dafür das optionale Zertifikatsprofil „tlsserver“ nutzen. Am 10. Februar 2027 sinkt die Laufzeit für alle neu ausgestellten Zertifikate dann zunächst auf 64 Tage und gut ein Jahr später, am 16. Februar 2028, auf 45 Tage.
Die meisten Administratoren, die für ihre Webserver die Zertifikate von Let’s Encrypt verwenden, dürften von der Änderung wenig bemerken: Ihre Automatisierung zur Erneuerung läuft künftig alle anderthalb statt drei Monate. Um derlei automatischen Helferlein zu assistieren, gibt es künftig eine Protokollerweiterung für ACME (Automatic Certificate Management Environment), die ACME Renewal Information (ARI).
Von einer manuellen Erneuerung der Zertifikate rät das Projekt schon seit langer Zeit ab, das Verfahren sei zu fehlerbehaftet und müsste nun doppelt so oft durchgeführt werden. Zudem sollten Administratoren sicherstellen, dass sie durch Monitoring-Systeme alarmiert werden, sobald eine Erneuerung fehlschlägt, empfiehlt Let’s Encrypt im Ankündigungs-Blogpost.
Wer sich noch immer mit der Automatisierung schwertut, goutiert womöglich die neue Verifizierungsmethode „DNS-PERSIST-01“. Hier muss ein DNS-Eintrag zur Überprüfung nur noch einmalig und nicht bei jeder Zertifikatserneuerung gesetzt werden. Allerdings muss DNS-PERSIST-01 noch durch die relevanten Gremien, also die IETF und das CA/Browser Forum [1], ratifiziert werden.
Hintergrund der Änderungen ist ebenfalls der mächtige Zusammenschluss der Browserhersteller und CAs. Vor allem Chrome, Mozilla und Co. sehen in langen Zertifikatslaufzeiten große Sicherheitsrisiken und betreiben seit Jahren Lobbyarbeit, [2] die im vergangenen Herbst zur Entscheidung des CA/B [3] geführt hat, die Laufzeiten verbindlich zu kappen.
URL dieses Artikels:
https://www.heise.de/-11100233
Links in diesem Artikel:
[1] https://cabforum.org/
[2] https://www.heise.de/news/TLS-Zertifikate-Apple-schlaegt-maximale-Laufzeit-von-10-Tagen-vor-9991640.html
[3] https://www.heise.de/news/47-Tage-CAs-und-Browserhersteller-beschliessen-kuerzere-Laufzeit-fuer-Zertifikate-10352867.html
[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:cku@heise.de
Copyright © 2025 Heise Medien
Hacker im Nebel: Das CCH ist während des 38C3 abends stimmungsvoll beleuchtet
(Bild: Christopher Kunz / heise medien)
Vier Wochen vor Deutschlands größtem Hackerkongress gibt es eine erste Version des Programms mit über 160 Vorträgen. Einige Überraschungen bleiben jedoch noch.
„Wie lassen sich zerfahrene und planetenfressende Prozesse power-cyclen, um sie neu und nachhaltiger zu denken?“ Diesen und vielen anderen Fragen will der Chaos Computer Club auf seinem 39. Jahreskongress unter dem Motto „Power Cycles“ auf den Grund gehen. Nun stellt der Club die erste Version des Kongressfahrplans vor: Über 160 Vorträge warten in sieben thematischen Tracks auf die Gäste.
Das Congress Center Hamburg (CCH) ist Heimat des größten fest bestuhlten Saals der Hansestadt – und dessen 3000 Plätze dürften wie in den Vorjahren heiß begehrt sein, um nach der Eröffnungszeremonie (27.12., 10:30 Uhr) Vorträgen von Bluetooth-Hacking bis zum traditionellen CCC-Jahresrückblick (28.12., 16:35 Uhr) zu lauschen. Auch in den anderen drei Sälen des CCH findet ein bunt gemischtes Programm aus sieben Bereichen [1] statt: CCC & Community, Ethics, Society & Politics, Art & Beauty, Hardware, Science und natürlich Security.
Kängurufreunde kommen in diesem Jahr auch auf ihre Kosten: Die Figur des Autors Marc-Uwe Kling ruft am Eröffnungstag von 19:15 bis 20:15 Uhr [2] gemeinsam mit ihrem Schöpfer und CCC-Sprecher Linus Neumann zum „Digital Independence Day“ auf.
Wie üblich für den Fahrplan behalten sich die Organisatoren Änderungen vor und versprechen einige Last-Minute-Überraschungen: Mehrere Vorträge geben sie erst kurz vor Kongressbeginn bekannt, der Fahrplan ist demnach noch eine Alphaversion. Und auch abseits der großen Bühnen finden in den Assemblies und überall im CCH weitere Events statt, die im „Hub“, dem zentralen Wiki des Kongresses, angekündigt werden.
Der 39C3 findet vom 27. bis 29. Dezember 2025 in Hamburg statt. Die Veranstaltung ist restlos ausverkauft, allenfalls auf dem Ticketmarkt [3] sind möglicherweise noch einzelne Rückläufer-Tickets zu haben.
URL dieses Artikels:
https://www.heise.de/-11099880
Links in diesem Artikel:
[1] https://fahrplan.events.ccc.de/congress/2025/fahrplan/
[2] https://fahrplan.events.ccc.de/congress/2025/fahrplan/event/die-kanguru-rebellion-digital-independence-day
[3] https://tickets.events.ccc.de/39c3/secondhand/
[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:cku@heise.de
Copyright © 2025 Heise Medien
FreshRSS