Connect with us

Entwicklung & Code

Meetings, Konferenzen und Workshops: Warum wir uns noch physisch treffen sollten


Wir haben heute alles, um uns nie wieder physisch begegnen zu müssen. Videocalls ersetzen Meetings, KI-Assistenten beantworten Fachfragen in Sekunden, Vorträge stehen auf YouTube, und asynchrone Kommunikation macht Zeitzonen irrelevant. Mein Unternehmen (die the native web GmbH) arbeitet seit der Gründung im Jahr 2012 vollständig remote, und das nicht als Notlösung, sondern als bewusste Entscheidung. Wir beraten Kundinnen und Kunden, entwickeln Software, produzieren Videos für YouTube und schreiben Fachartikel und Bücher, ohne dass dafür jemals jemand in ein Büro fahren müsste. Wir haben keines.

Weiterlesen nach der Anzeige

Wenn man es streng betrachtet, sind physische Treffen in unserer Branche kaum noch zu rechtfertigen. Die Anreise kostet Zeit und Geld, die Umweltbilanz ist fragwürdig, die Hotels sind überteuert und nicht immer komfortabel. Einen Fachvortrag kann man auf YouTube schauen, eine Diskussion in einem Forum führen, einen Workshop über ein geteiltes Whiteboard abhalten. Trotzdem bin ich überzeugt, dass etwas Entscheidendes verloren geht, wenn man sich nur noch digital begegnet. Nicht, weil die digitale Welt schlecht funktioniert. Sondern, weil sie für eine bestimmte Kategorie von Erfahrung blind ist.

Die digitale Welt funktioniert hervorragend

Das soll kein Artikel werden, der Remote-Arbeit schlechtredet. Im Gegenteil: Remote ist für den Alltag der Softwareentwicklung eine ausgezeichnete Arbeitsform, die ich nicht mehr missen möchte. Code-Reviews, Pair-Programming, technische Abstimmungen, Kundenberatung, sogar Workshops lassen sich digital durchführen, und zwar gut. Wer das Gegenteil behauptet, hat es entweder nie ernsthaft versucht oder es mit den falschen Werkzeugen getan.

KI verstärkt diesen Effekt noch. Wissen, das früher nur auf Konferenzen oder in Fachgesprächen zugänglich war, steht heute jederzeit zur Verfügung. Man kann ein technisches Problem beschreiben und bekommt in Sekunden eine fundierte Einschätzung. Man kann sich in ein neues Themengebiet einarbeiten, ohne dafür einen Kurs zu besuchen oder eine Kollegin zu fragen. Die Barrieren für den Zugang zu Information waren noch nie so niedrig wie heute.

Und die Werkzeuge werden besser, nicht schlechter. Virtuelle Whiteboards erlauben kollaboratives Arbeiten in Echtzeit. Bildschirmfreigaben machen Code-Walkthroughs so transparent wie einen Blick über die Schulter. Automatische Transkriptionen halten fest, was besprochen wurde. In vielen Situationen ist die digitale Zusammenarbeit der physischen sogar überlegen, weil sie dokumentierbar, durchsuchbar und reproduzierbar ist.

Die Frage ist also nicht, ob die digitale Welt funktioniert. Sie funktioniert. Die Frage ist, ob sie für alles reicht. Und die ehrliche Antwort darauf lautet: Nein. Nicht, weil ihr etwas Technisches fehlt, sondern weil bestimmte Formen der menschlichen Wahrnehmung an physische Präsenz gebunden sind.

Was durch den Bildschirm nicht passt

Weiterlesen nach der Anzeige

Stellen Sie sich einen Raum vor, in dem 200 Menschen sitzen und einem Vortrag zuhören. Im Raum herrscht eine bestimmte Energie: aufmerksame Stille, gelegentliches Nicken, ein leises Raunen bei einer überraschenden These. Oder eben das Gegenteil: unruhiges Hin- und Herrutschen, verstohlene Blicke auf Smartphones, ein spürbares Desinteresse. Beide Zustände transportieren Information, und zwar wichtige Information darüber, ob eine Idee Resonanz findet oder ins Leere läuft. Diese Information existiert in keinem Video, in keinem Transkript und in keinem Chat-Protokoll.

Dasselbe gilt für die Kaffeepause. In einem Videocall gibt es keine Kaffeepause. Es gibt eine Bildschirmpause, in der man aufsteht, sich einen Kaffee holt und auf das eigene Smartphone schaut. In einer physischen Kaffeepause dagegen passiert etwas anderes: Man kommt mit jemandem ins Gespräch, den man vorher nicht kannte. Man hört zufällig ein Gesprächsfragment, das einen aufhorchen lässt. Man stellt sich zu einer Gruppe, die über ein Problem diskutiert, das man selbst gerade hat. Nichts davon ist geplant, und genau das ist der Punkt.

Digitale Kommunikation ist zielgerichtet. Man öffnet einen Call, um ein bestimmtes Thema zu besprechen. Man schreibt eine Nachricht, weil man eine konkrete Frage hat. Man schaut ein Video, weil man etwas Bestimmtes lernen will. Physische Begegnung dagegen ist offen. Sie lässt Raum für das Ungeplante, das Zufällige, das Beiläufige. Und in meiner Erfahrung entsteht genau dort oft das Wertvollste.

Ich habe das in meiner eigenen Laufbahn mehrfach erlebt. 2011 bin ich zur ersten Node.js Conference Italy nach Brescia gereist. Rein rational hätte ich mir die Vorträge irgendwann als Aufzeichnung ansehen können. Aber was mich dort erreicht hat, war nicht der Inhalt der Talks. Es war die Atmosphäre: 250 Menschen aus ganz Europa, die für eine Technologie brannten, die damals kaum jemand kannte. In diesem Raum wurde mir klar, dass Node.js kein Experiment bleiben würde. Diese Erkenntnis hätte mir kein Video vermittelt. Sie entstand nicht aus dem, was gesagt wurde, sondern aus dem, was im Raum spürbar war.

Inspiration entsteht selten am Schreibtisch

Für den Alltag ist der Schreibtisch der richtige Ort. Dort wird Code geschrieben, dort werden Architekturen entworfen, dort entstehen Artikel und Präsentationen. Der Schreibtisch ist der Ort der Ausführung, und Remote-Arbeit optimiert ihn auf beeindruckende Weise. Man arbeitet ungestört, in seinem eigenen Rhythmus, mit seinen eigenen Werkzeugen. Das ist produktiv, effizient und für viele Menschen auch die angenehmere Arbeitsform.

Aber Neues entsteht selten im Modus der Ausführung. Inspiration braucht einen anderen Zustand: eine gewisse Offenheit, eine Bereitschaft, sich von etwas Unerwartetem treffen zu lassen. Wer jeden Tag am selben Schreibtisch sitzt, dieselben Werkzeuge nutzt und dieselben Kanäle konsumiert, bewegt sich in einem geschlossenen System. Die Impulse, die hereinkommen, sind gefiltert, kuratiert, algorithmisch ausgewählt. Sie bestätigen bestehende Annahmen, statt sie in Frage zu stellen. Das ist kein böser Wille der Algorithmen, es ist ihre Funktionsweise: Sie zeigen, was zum bisherigen Verhalten passt, nicht was davon abweicht.

Physische Begegnung durchbricht dieses System, weil sie ungefiltert ist. Man nimmt Stimmungen wahr, Körpersprache, Begeisterung, Skepsis. Man wird mit Perspektiven konfrontiert, die man sich nicht selbst ausgesucht hat. Man erlebt, wie andere Menschen über Probleme denken, die man selbst aus einer völlig anderen Richtung betrachtet. Und manchmal reicht ein einziger solcher Moment, um einen Gedanken auszulösen, der monatelange Arbeit beeinflusst. Nicht weil der Gedanke so brillant wäre, sondern weil er in einem Kontext entsteht, der ihn wirksam macht.

Das gilt nicht nur für Konferenzen. Es gilt genauso für den Workshop bei einer Kundin oder einem Kunden, bei dem man zum ersten Mal die tatsächliche Dynamik eines Teams erlebt, statt sie aus Jira-Tickets und Slack-Nachrichten zu rekonstruieren. In einem Remote-Call sieht man Gesichter in kleinen Kacheln. Vor Ort sieht man, wer mit wem spricht, wer schweigt, wer die Augen verdreht, wenn ein bestimmtes Thema aufkommt. Man spürt, wo die eigentlichen Spannungen liegen und wo die Energie ist. Diese Wahrnehmung ist für eine Beraterin oder einen Berater Gold wert, weil sie Probleme sichtbar macht, die in keinem Dokument stehen.

Es gilt für das Meetup, bei dem man in einer fremden Stadt zum ersten Mal eine lokale Community kennenlernt und feststellt, dass die Probleme, die man für einzigartig hielt, anderswo längst gelöst sind. Und es gilt für das Gespräch beim Abendessen nach einem langen Konferenztag, in dem mehr strategische Klarheit entsteht als in zehn geplanten Videocalls. Solche Gespräche haben keinen Zeitslot, keine Agenda und kein geteiltes Dokument. Genau deshalb sind sie so produktiv.

Der Unterschied zwischen Information und Erfahrung

Einen Vortrag auf YouTube anzuschauen, liefert Information. Denselben Vortrag live zu erleben, die Reaktionen im Publikum zu spüren und danach mit der Speakerin ins Gespräch zu kommen, liefert Erfahrung. Beides hat seinen Wert, aber es ist nicht dasselbe. Und wer den Unterschied für irrelevant hält, unterschätzt die Rolle, die Erfahrungen bei Entscheidungen spielen.

Information lässt sich verlustfrei digitalisieren. Ein Fachvortrag verliert nichts, wenn man ihn als Video anschaut. Die Folien sind dieselben, die Worte sind dieselben, die Codebeispiele sind dieselben. Wer ausschließlich nach Information sucht, kann sich die Anreise tatsächlich sparen. Insofern haben diejenigen, die Konferenzen für überflüssig erklären, auf dieser Ebene durchaus recht.

Erfahrung dagegen lässt sich nicht digitalisieren, weil sie aus dem Zusammenspiel von Inhalt, Kontext und eigenem Erleben entsteht. Die Erfahrung, in einem Raum voller Gleichgesinnter zu sitzen, ist eine andere als die, allein vor dem Bildschirm denselben Vortrag zu sehen. Die Erfahrung, einer Speakerin gegenüberzustehen und eine Frage zu stellen, ist eine andere als die, einen Kommentar unter ein Video zu schreiben. Die Erfahrung, beiläufig mitzubekommen, worüber sich die Menschen in den Pausen unterhalten, ist eine andere als die, eine kuratierte Zusammenfassung zu lesen.

Wir betreiben einen YouTube-Kanal mit rund 60.000 Abonnentinnen und Abonnenten. Keine Konferenz der Welt versammelt so viele Menschen in einem Raum für einen einzelnen Vortrag. Rein quantitativ ist YouTube der physischen Bühne haushoch überlegen. Aber Reichweite und Wirkung sind nicht dasselbe.

Wenn ich ein Video aufnehme, spreche ich in eine Kamera. Ich sehe keine Gesichter, bekomme keine Reaktionen, spüre nicht, ob ein Gedanke ankommt oder ob ich mein Publikum verliere. Die Kommentare unter dem Video kommen Stunden oder Tage später, oft losgelöst vom eigentlichen Kontext. Auf einer Konferenz dagegen sehe ich sofort, was funktioniert und was nicht. Und danach entstehen Gespräche, die neue Richtungen eröffnen. Solche Gespräche haben mir schon ganze Projekte eingebracht, neue Denkansätze vermittelt und Kooperationen angestoßen, die über Jahre getragen haben.

In einem persönlichen Gespräch entsteht etwas, das über den reinen Informationsaustausch hinausgeht: Vertrauen, Verbindung und manchmal der Beginn einer Zusammenarbeit, die man vorher nicht für möglich gehalten hätte. Kein Algorithmus kann das erzeugen.

Die Gegenargumente sind berechtigt

Natürlich gibt es berechtigte Einwände gegen physische Treffen. Die Umweltbilanz von Flugreisen und Hotelübernachtungen ist nicht zu ignorieren. Die Kosten für Anreise, Unterkunft und Konferenztickets summieren sich schnell. Die Zeit, die man unterwegs verbringt, fehlt für produktive Arbeit. Und nicht jede Konferenz ist die Reise wert: Es gibt durchaus Veranstaltungen, bei denen man nach zwei Tagen feststellt, dass man die wesentlichen Erkenntnisse auch in einem einstündigen Video hätte aufnehmen können.

Diese Einwände ernst zu nehmen bedeutet, bewusster zu entscheiden, wann physische Präsenz ihren Aufwand rechtfertigt und wann nicht. Nicht jedes Meeting braucht einen Raum. Nicht jeder Workshop muss vor Ort stattfinden. Nicht jede Konferenz verdient die Anreise. Wer wahllos zu jeder Veranstaltung fährt, verschwendet Ressourcen. Aber die pauschale Schlussfolgerung, dass physische Treffen ein Relikt vergangener Zeiten seien, ist ebenso falsch wie die Behauptung, Remote-Arbeit sei nur ein vorübergehender Trend. Beides sind Extrempositionen, die der Realität nicht gerecht werden. Die Realität ist differenzierter: Manche Situationen verlangen Präsenz, andere nicht, und die Kunst liegt darin, den Unterschied zu erkennen.

Was hilft, ist eine einfache Unterscheidung: Geht es um den Austausch von Information oder um das Sammeln von Erfahrung? Geht es um die Abarbeitung bekannter Aufgaben oder um die Suche nach neuen Impulsen? Geht es um Effizienz oder um Inspiration? Wenn die Antwort in Richtung Information, Abarbeitung und Effizienz weist, ist Remote die bessere Wahl. Wenn sie in Richtung Erfahrung, Impulse und Inspiration weist, lohnt sich der Weg.

Der Raum, den es nur in der physischen Welt gibt

Die Frage ist nicht, ob man sich physisch oder digital trifft. Die Frage ist, wann welcher Modus seine Stärken ausspielt. Und die Antwort darauf ist im Grunde einfach: Für den Alltag ist die digitale Welt überlegen. Für die Momente, die den Alltag verändern, ist physische Begegnung durch nichts zu ersetzen.

Das bedeutet in der Praxis, sich bewusst zu fragen: Wann lohnt sich der Aufwand? Wenn ich einen Kunden zum ersten Mal treffe und verstehen will, wie sein Unternehmen tickt, fahre ich hin. Wenn wir im dritten Sprint das nächste Inkrement planen, reicht ein Videocall. Wenn ich auf einer Konferenz das Gespür dafür entwickeln will, wohin sich eine Community bewegt, bin ich vor Ort. Wenn ich einen bestimmten Vortrag sehen will, schaue ich ihn auf YouTube.

Ich werde weiterhin remote arbeiten. Ich werde weiterhin Videos drehen und Artikel schreiben und Wissen digital vermitteln. Aber ich werde genauso weiterhin in Züge und Flugzeuge steigen, in überteuerten Hotels schlafen und mich mit Menschen in einem Raum treffen. Nicht trotz der digitalen Möglichkeiten, sondern weil ich ihren Wert kenne und deshalb auch ihre Grenzen sehe.

Denn am Ende ist die wichtigste Erkenntnis, die ich in über 20 Jahren in dieser Branche gewonnen habe, nicht aus einem Buch, einem Video oder einem Chat gekommen. Sie ist in einem Raum entstanden, in dem Menschen zusammenkamen, die für dieselbe Sache brannten. Und diesen Raum gibt es nur in der physischen Welt. Kein Algorithmus kann ihn simulieren, kein Bildschirm kann ihn ersetzen, und kein noch so gutes Remote-Set-up kann die Energie reproduzieren, die entsteht, wenn Menschen sich an einem Ort versammeln, weil ihnen etwas wirklich wichtig ist.


(who)



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Rust rutsch überraschend ab – Python bleibt vorn: Tiobe-Index für April


Im Tiobe-Index für April 2026 ist Rust von seinem Höchststand von Platz 13 Anfang des Jahres auf Rang 16 zurückgefallen. Die Herausgeber des monatlichen Index sehen das als Anzeichen dafür, dass sich der seit 2020 bestehende Aufstieg der Sprache insgesamt verlangsamt.

Weiterlesen nach der Anzeige

Python führt das Ranking mit 20,97 Prozent an Suchtreffern weiterhin an, gefolgt von C (12,34 Prozent), C++ (8,03 Prozent), Java (7,79 Prozent) und C# (5,98 Prozent) – diese Sprache hatte Tiobe erst im Januar zur Programmiersprache des Jahres 2025 gekürt.

Rust erreicht im aktuellen Ranking einen Anteil von 1,09 Prozent. Tiobe-Chef Paul Jansen sieht die Ursache für den Abstieg vor allem in der hohen Einstiegshürde: „Rust bleibt für Nicht-Experten schwierig zu erlernen“. Konzepte wie Ownership und Borrowing erfordern für Umsteiger ein grundlegendes Umdenken.


Infografik Rust in Tiobe

Infografik Rust in Tiobe

Rust hat sich stetig nach oben gearbeitet und seinen Index insgesamt verbessert.

(Bild: Screenshot Tiobe)

C zeigt eine gegenläufige Tendenz, da die Sprache mit einem Plus von 2,39 Prozentpunkten deutlich zulegen konnte. Das ist verwunderlich, denn C gilt als unsichere Variante für hardwarenahe Programmierung im Vergleich zu Rust, und immer mehr Entwicklerinnen und Entwickler wenden sich davon ab, gerade auch in den großen Organisationen wie Google, Microsoft oder dem Linux-Kernel-Team.

Rust als typsichere Programmiersprache bildet auch im Umgang mit KI einen Vorteil gegenüber vielen anderen Sprachen, da sie zu mehr Eindeutigkeit und weniger Fehlern führt. Der Verlauf der letzten Monate lässt sich auch als normale Schwankung interpretieren.

Die Methodik des Tiobe-Index gilt in der Branche als zweifelhaft, denn sie misst nicht die tatsächliche Verwendung von Sprachen durch Entwickler, sondern deren Interesse daran – gemessen an Suchtreffern im Web. Die Quote steht für den Anteil von Suchtreffern einer Programmiersprache gegenüber allen Programmiersprachen. Tiobe wertet dazu die Ergebnisse von 25 Suchmaschinen aus, darunter Google, Wikipedia oder Amazon.

Weiterlesen nach der Anzeige

Der Herausgeber muss künftig zeigen, wie tragfähig diese Methode im KI-Zeitalter noch ist, in dem die meisten Programmiererinnen und Programmierer eher ihren Coding-Assistenten befragen als Google.


(who)



Source link

Weiterlesen

Entwicklung & Code

Linux 7.0 erschienen – mehr als ein Nummernsprung


Die neue Versionsnummer des Linux-Kernels wirkt wie ein kleiner Paukenschlag. Wir schreiben nun eine 7.0. Das hat jedoch weniger mit einem großen architekturellen Wurf oder den neuen Features zu tun. Linus Torvalds ist dafür bekannt, große Zahlen hinter dem Punkt einer Versionsnummer nicht sonderlich zu mögen. Daher erfolgt dieses Mal wieder ein Sprung auf ein neues Major-Release, nur der besseren Nummerierung wegen.

Weiterlesen nach der Anzeige

Wüsste man es jedoch nicht besser, ließen einige Features in Linux 7.0 durchaus an einen Major-Release-würdigen Sprung glauben. Immerhin verspricht der Neue im Kernel-Reigen selbstheilende Dateisysteme, robusten Code beim Allokieren von Speicher und Rust als offizielles – nicht experimentelles – Feature.

Das Projekt „Rust für Linux“ hat einen wichtigen Meilenstein erreicht. Wie Maintainer Miguel Ojeda in einem Commit zum Entwicklungszweig von Linux 7.0 festhält, gilt die Integration der Programmiersprache Rust nicht länger als experimentell. Wörtlich heißt es, Rust sei „here to stay“. Diese Einschätzung wird auch von Linus Torvalds und anderen Kernel-Entwicklern getragen.

Entsprechend wurde der Status der Rust-Unterstützung im Kernel angepasst. In der Konfigurationsoberfläche (menuconfig) wird Rust nicht mehr als experimentelles Feature geführt. Damit ist die Sprache formal im Mainline-Kernel etabliert.

Rust war erstmals 2022 mit Linux 6.1 in den Kernel aufgenommen worden. Zu diesem Zeitpunkt beschränkte sich die Unterstützung im Wesentlichen auf ein einfaches Beispielmodul für ein „Hello, world!“. Seither wurde die Infrastruktur kontinuierlich erweitert, etwa im Bereich von Treibern und Kernel-Schnittstellen.

Weiterer Ausbau nötig

Weiterlesen nach der Anzeige

Ungeachtet dieses Fortschritts befindet sich die Rust-Integration weiterhin im Ausbau. Zahlreiche Subsysteme bieten bislang nur eingeschränkte oder noch keine Rust-Schnittstellen. Entsprechend ist auch in kommenden Kernel-Versionen mit weiteren Anpassungen und Erweiterungen zu rechnen.

Parallel dazu wird Rust bereits in anderen Bereichen des Linux-Ökosystems eingesetzt, etwa im Android-Umfeld. Die Entwicklung im Mainline-Kernel ist damit Teil eines übergeordneten Trends hin zu speichersicheren Programmiersprachen in systemnaher Software.

Mit dem Auszug aus dem Experimentellen will Ojeda auch ein Zeichen setzen. Investitionen in Rust stünden auf gesichertem Fundament. Insbesondere Aufwände in das Training von Kernel-Entwicklern zu Rust sollen eine sichere Anlage sein. Ein wenig Exot bleibt Rust dennoch. Den jeweiligen Maintainern bleibt es freigestellt, Rust aus ihren Subsystemen im Kernel herauszuhalten.

XFS: Selbstüberwachung statt Reparaturwerkzeug

Mit der Einführung des „autonomous self-healing support“ entwickelt sich XFS konzeptionell weiter: weg von einem rein reaktiven Dateisystem hin zu einer Architektur, die Fehler früh erkennt und automatisiert darauf reagieren kann. Dabei geht es weniger um „Selbstheilung“ im engeren Sinne als um eine intelligente Aufgabenteilung zwischen Kernel und User-Space. Es ist also kein Feenstaub im Spiel.

Traditionell erfolgt die Fehlerbehebung bei XFS über Werkzeuge wie xfs_repair. Dieses starten Administratoren manuell und typischerweise dann, wenn bereits ein Problem aufgetreten ist – etwa nach einem Absturz oder bei erkannten Inkonsistenzen im Dateisystem.

Der Ablauf ist dabei klar strukturiert, aber auch schwergewichtig: Zunächst muss das Dateisystem ausgehängt werden, also offline gehen. Es folgt eine vollständige Analyse des Dateisystems. Abschließend erfolgt die Reparatur aller gefundenen Fehler.

Dieses Vorgehen ist zuverlässig, bringt aber klare Nachteile mit sich: Es verursacht Downtime, reagiert erst spät auf Probleme und ist bei großen Speichersystemen zeitaufwendig.

Ereignisbasierte Selbstüberwachung

Der neue „Selbstheilungsmechanismus“ verfolgt einen grundlegend anderen Ansatz. Anstatt Fehler erst im Nachhinein zu beheben, erkennt der Kernel Probleme bereits während des laufenden Betriebs und meldet sie an den User-Space. Dabei gilt ein wichtiges Prinzip: Der Kernel erkennt und meldet. Die Entscheidung, was zu tun ist, trifft jedoch der User-Space.

Technisch geschieht das über ein Ereignissystem, beispielsweise mittels File Deskriptor und ioctl. Über dieses erhalten spezialisierte Programme kontinuierlich Informationen über den Zustand des Dateisystems.

Dämonen im User-Space

Ein zentraler Bestandteil dieser Architektur ist ein User-Space-Dienst (Healer Daemon). Dieser bewertet eingehende Ereignisse und entscheidet, welche Maßnahmen sinnvoll sind. Typische Reaktionen könnten der Start eines gezielten Scrubbing-Prozesses, das Anstoßen einer Teilreparatur oder der Neustart betroffener Anwendungen oder Container sein. Auch die Eskalation an Monitoring- oder Alerting-Systeme wäre eine Option.

Dadurch wird die Fehlerbehandlung deutlich flexibler und kontextabhängig. Das verspricht einen entscheidenden Vorteil gegenüber starren Kernel-Mechanismen.

Der Unterschied zwischen dem klassischen und dem neuen Ansatz lässt sich auf eine grundlegende Verschiebung reduzieren: proaktiv statt reaktiv. Früher reagierte das System auf bereits eingetretene Schäden. Der neue Ansatz hingegen setzt auf Früherkennung und automatisiertes Reagieren. Während xfs_repair eher als „Notfallwerkzeug“ dient, versteht sich der Self-Healing-Ansatz als kontinuierliches Überwachungs- und Reaktionssystem im Hintergrund.

Bedeutung für moderne Systeme

Diese Entwicklung ist besonders relevant für moderne IT-Umgebungen wie Cloud-Infrastrukturen, Container-Plattformen wie Kubernetes und große, hochverfügbare Speichersysteme. In solchen Szenarien ist eine Downtime mindestens teuer, wenn nicht gar inakzeptabel. Systeme müssen in der Lage sein, Probleme selbstständig zu erkennen und möglichst ohne menschliches Eingreifen beheben zu können.

Der neue Self-Healing-Support in XFS ersetzt klassische Reparaturwerkzeuge zwar (noch) nicht, ergänzt sie aber sinnvoll. Während Werkzeuge wie xfs_repair weiterhin für schwerwiegende Fälle notwendig bleiben, ermöglicht die neue Architektur eine deutlich frühere und feinere Reaktion auf Probleme. Damit mausert sich XFS zu einem Dateisystem, das nicht nur Daten verwaltet, sondern aktiv zur Stabilität des Gesamtsystems beiträgt.

Typsicherheit für alte API

Mit Linux 7.0 erfährt eine der zentralsten Schnittstellen des Kernels eine grundlegende Modernisierung: kmalloc(). Dabei handelt es sich nicht um eine komplette Neuentwicklung der Speicherverwaltung, sondern um eine gezielte Weiterentwicklung für robusteren Code. Typische Fehlerquellen in der C-Programmierung sollen systematisch vermieden werden.

Es ist ein altbekanntes Problem. Traditionell arbeitet kmalloc() größenbasiert: Entwickler geben explizit an, wie viele Bytes reserviert werden sollen. Zumeist kommen Konstrukte wie sizeof(...) zum Einsatz. Diese Flexibilität hat jedoch ihren Preis. Fehler wie die Verwendung von sizeof(ptr) statt sizeof(*ptr) sind syntaktisch korrekt, führen aber zu kleinen Allokationen. Die Folgen zur Laufzeit sind potenziell schwerwiegend. Wenn der Speicherbereich zu klein ist für die aufzunehmenden Daten, überschreiben diese andere. Ein klassischer Überlauf (Overflow) ist die Folge. Solche Bugs gehören seit Jahrzehnten zu den klassischen Problemfeldern im Kernel.

Objektbasierte Allokation

Linux 7.0 führt daher eine Reihe neuer Makros ein, darunter kmalloc_obj() und kmalloc_objs(). Statt die Größe manuell zu berechnen, beschreibt der Entwickler direkt den gewünschten Objekttyp. Die benötigte Speichergröße wird automatisch abgeleitet. Gleichzeitig stellt der Compiler sicher, dass Rückgabetyp und Zielvariable zusammenpassen.

Dieser Wechsel von einer größenorientierten zu einer typbasierten Denkweise erhöht nicht nur die Lesbarkeit des Codes, sondern erkennt Fehler bereits zur Compile-Zeit.

Ein weiterer Fortschritt betrifft Strukturen mit flexiblem Array am Ende. Ein häufig verwendetes Muster im Kernel. Mit kmalloc_flex() steht im neuen Kernel ein spezialisiertes Makro zur Verfügung, das die korrekte Gesamtgröße solcher Objekte automatisch berechnet. In Kombination mit modernen Compiler-Erweiterungen wie __counted_by() lässt sich sogar die zugehörige Längenangabe passend setzen. Dadurch werden Inkonsistenzen zwischen Speichergröße und Metadaten deutlich reduziert.

Weniger Boilerplate, mehr Sicherheit

Neben der Typsicherheit wurde auch die Bedienung verfeinert. In vielen Fällen kann das bislang obligatorische Allokations-Flag GFP_KERNEL entfallen, da es implizit angenommen wird. Das reduziert redundanten Code und macht typische Allokationen kompakter und übersichtlicher.

Die Einführung der neuen Makros blieb nicht auf neue Codepfade beschränkt. Große Teile des bestehenden Kernels wurden damit automatisiert angepasst. Die Änderung ist damit weniger ein punktuelles Feature als vielmehr eine breit angelegte Qualitätsverbesserung der gesamten Codebasis.

Die Überarbeitung von kmalloc() in Linux 7.0 ist ein typisches Beispiel für evolutionäre Kernel-Entwicklung. Statt neue Funktionalität zu schaffen, wird die bestehende Infrastruktur sicherer und klarer gestaltet. Durch typsichere Makros, bessere Unterstützung komplexer Datenstrukturen und reduzierte Fehleranfälligkeit trägt die Neuerung maßgeblich zur langfristigen Stabilität und Wartbarkeit des Linux-Kernels bei.

Ruhe in Frieden, Laptop-Mode

Der neue Sprössling der Linux-Kernel mottet den Laptop-Mode ein. Diesen Modus erhielt der Kernel in Version 2.4 (als Backport, offiziell kam er in 2.6.6 dazu). Er holte über die Jahre so manches Wättstündchen mehr aus dem Akku des Laptops heraus. Damit ist nun Schluss.

Der Laptop Mode im Linux-Kernel ist eine Energiesparfunktion, die vor allem für Systeme mit mechanischen Festplatten entwickelt wurde. Dabei werden Schreibzugriffe auf den Datenträger gezielt verzögert und gebündelt, sodass die Festplatte seltener aktiviert werden muss und länger im stromsparenden Ruhezustand bleiben kann. Technisch geschieht dies durch Anpassungen im Writeback-Verhalten des Kernels (steuerbar über /proc/sys/vm/laptop_mode). Der Nachteil ist ein erhöhtes Risiko von Datenverlust bei Abstürzen, da Daten länger im RAM verbleiben.

Auf modernen Systemen mit SSDs spielt der Laptop Mode kaum noch eine Rolle. Da auch die Zeiten von intern verbauten mechanischen Festplatten bei modernen Notebooks vorbei sind, fällt der Laptop-Mode aus dem Kernel heraus. Zu aufwendig ist das stetige Nachziehen im Code für ein nicht mehr zeitgemäßes Feature.

SELinux hält eBPF im Zaum

Die Integration von eBPF in das Sicherheitsmodell von SELinux erweitert die bislang primär technische Absicherung durch den Verifier um eine umfassende Zugriffskontrolle. Im Linux Kernel wird damit nicht mehr nur geprüft, ob ein eBPF-Programm sicher ist, sondern auch, ob ein Prozess es gemäß definierter Richtlinien überhaupt nutzen darf.

Kern der Erweiterung ist die Einbindung von eBPF in das Mandatory-Access-Control-Modell. Prozesse benötigen explizite Berechtigungen, um Programme zu laden, an Kernel-Hooks anzuhängen oder mit bestehenden BPF-Objekten zu interagieren. Gleichzeitig können Programme, Maps und andere eBPF-Strukturen mit eigenen Sicherheitskontexten versehen werden, wodurch sich Zugriffe und Datenflüsse gezielt einschränken lassen.

Diese Kombination aus Verifier und SELinux schafft ein zweistufiges Sicherheitskonzept: Während der Verifier die Korrektheit von Programmen sicherstellt, kontrolliert SELinux deren zulässige Verwendung. Dadurch wird eBPF deutlich besser in bestehende Sicherheitsarchitekturen integriert und für den Einsatz in sicherheitskritischen Umgebungen geeignet.

Der neue Kernel bietet wieder viele neue Treiber und Unterstützung von neuer Hardware. Auch gibt es viele Detailverbesserungen, beispielsweise bei eBPF und Rust. Allein durch das Self-Healing bei XFS und das verbesserte kmalloc() rangiert der neue Kernel nicht mehr als reines „Wartungsrelease“. Damit wird er auch abseits der „Phobie“ vor langen Nummern von Linus Torvalds einem Release-Sprung auf 7.0 gerecht.

Alle Änderungen im neuen Kernel finden sich im ChangeLog. Linux 7.0 steht wie üblich unter www.kernel.org zum Download bereit. Die Entwicklung an Kernel 7.0 startet Linus Torvalds zwei Wochen, nachdem der Kernel 6.19 Anfang Februar 2026 das Licht der Welt erblickte.


(dmk)



Source link

Weiterlesen

Entwicklung & Code

Apples früherer KI-Chef John Giannandrea verlässt das Unternehmen


Es war ein denkwürdiger Auftritt am Nachmittag des 11. Juni 2024: Apples damaliger KI-Chef John Giannandrea und Software-Chef Craig Federighi demonstrierten auf der Bühne des Steve Jobs Theater im Apple-Hauptquartier in Cupertino den großen Schulterschluss. Die von Apple-Chef Tim Cook eingeleitete Fragestunde mit YouTuberin iJustine sollte die kurz zuvor vorgestellte Apple Intelligence inhaltlich vertiefen und vermutlich ein Signal der Einmütigkeit in der Apple-Chefetage ausstrahlen. Jetzt, nicht einmal zwei Jahre danach, wird Giannandrea das Unternehmen zur Monatsmitte verlassen.

Weiterlesen nach der Anzeige

Das Schicksal des früheren Google-Mitarbeiters ist eng verknüpft mit den KI-Bemühungen Apples. Damals angekündigte Grundfunktionen der Apple Intelligence wie das Zusammenfassen von Texten oder maßgeschneiderte Emojis erreichten zwar binnen weniger Monate einen großen Teil der Apple-Kundschaft. Der Blick der Fachwelt richtete sich allerdings mehr auf das, was nicht kam: Siri sei kein Sprachassistent mehr, sondern ein Geräteassistent mit tieferem Verständnis dafür, was auf dem Gerät passiert, tönte Giannandrea in der damaligen Fragestunde. Zwei Jahre später gibt es immer noch nur die Ankündigung, dass Siri besser werden soll. Zuletzt verdichteten sich jedoch Berichte, wonach Apple für iOS 27 eine eigene Siri-App sowie einen Chatbot-Modus plant.

KI-Weichen neu gestellt

Giannandrea kam im Jahr 2018 zu Apple. Bei Google war er zuvor acht Jahre lang tätig. Seine Expertise in Machine-Learning passte gut zu Apples Ambitionen, die mit der Neural Engine auch in Hardware gegossen wurden. Doch als mit ChatGPT von OpenAI Jahre später die generativen Sprachmodelle einen Hype auslösten, wirkte Apple wie auf dem falschen Fuß erwischt. Die Vorstellung der Apple Intelligence, 2024, sollte der Befreiungsschlag werden. Die „AI for the rest of us“ (KI für den Rest von uns) sollte mit dem Datenschutz-Vorrang punkten. Stattdessen machte Apple Schlagzeilen damit, dass die KI-Siri offenbar gar nicht funktionierte und das Projekt offenbar komplett zurückgesetzt werden musste. Intern gilt die Dauerbaustelle Siri bereits seit Längerem als Problemfall, da versprochene Funktionen immer wieder verschoben wurden.

Die diesjährige Entwicklerkonferenz WWDC am 8. Juni soll nun den Trubel der vergangenen Jahre vergessen machen. Apple ist eine Kooperation mit Google eingegangen, um deren KI-Modell Gemini zu verwenden. Vor allem aber wurden erhebliche Veränderungen in der Leitung vorgenommen. Dabei gilt Federighi intern als Verfechter eines eher pragmatischen KI-Kurses mit Fokus auf Budgets und Partnerschaften. Der ehemalige Vision-Pro-Chef brachte für den Umbau der Siri-Abteilung zahlreiche Experten aus seinem alten Team mit. Weitere erfahrene Kräfte, die es richten sollen, sind Eddy Cue und Sabih Khan. Erneut ist ein Ex-Googler mit in der Verantwortung: Neuzugang Amar Subramanya soll als Vice President of AI aber deutlich weniger Eigenständigkeit genießen als sein Vorgänger. Er berichte an Federighi.

Eine letzte Aktienprämie

Giannandrea war in den vergangenen Monaten nur noch Berater für Apple. Sein Rückzug wurde im Dezember 2025 angekündigt, nachdem zuvor bereits laut geworden war, dass es zwischen den Ressortleitern bei Apple geknirscht hat. Bereits im März 2025 habe Cook Giannandrea deshalb die Leitung des Siri-Teams entzogen, hieß es in Medienberichten. Es war ein Rückzug in Raten. Sein Verbleib bis Mitte April erklärt Bloomberg-Reporter Mark Gurman mit den üblichen Gepflogenheiten in börsennotierten Unternehmen, um Giannandrea noch eine letzte Aktienprämie auszahlen zu können.

Weiterlesen nach der Anzeige

Nach Apple will der frühere KI-Chef laut Bericht in verschiedenen Unternehmensvorständen mitwirken und als Berater für Start-up-Unternehmen tätig werden. Wie stark Apples stotternder KI-Motor tatsächlich mit seiner Person verknüpft war, wird sich in den nächsten Monaten zeigen. Finanziell profitiert der Konzern trotz technischer Rückstände massiv: Erwartungen zufolge wird Apple bald eine Milliarde US-Dollar durch KI-Apps im App Store verdienen.

Lesen Sie auch


(mki)



Source link

Weiterlesen

Beliebt