Linus Torwalds: kritisiert auch 2025 die Fragmentierung des Linux Ökosystems

[DavidXanatos]

Also was ist denn Vorschlag, wie man das erreichen kann. Also jetzt abseits von "Forderungen" und dieses "die Leute müssten doch einfach nur mal ...".

Wie könnte man das erreichen , na z.b. in dem die linux fundation nicht nur den kernel macht sondern auch ein referenz userspace und für den verspricht auch dafür zu sorgen das die API über mehrere Jahrzehnte mindestens abwärtskompatibel bleibt.

Warum trittst Du also an die Distributionen heran und stellst Forderungen und nicht an die Softwarehersteller? Die leiden doch (Deiner Meinung nach) am meisten darunter. Also überzeug doch die!

Nein am meisten leiden die Nutzer die keine Software bekommen können.

Die Sache ist die
1. für linux komerzielle software an zu beiten ist ein krampf in A***
2. es nutzen zu wenige leute linux das es wirtschaftlcih wäre sich diesen krampf an zu tun.

Wäre es kein krampf in A*** sondern sehr einfach worden komerzielle software anbieter es eher machen weil einpaar % mehr nutzer sind einpaar % mehr nutzer und wen es nicht messbahr kosten/zeit verschlingt wieso nicht.

Ist ja nicht so, das es keine Standards gibt oder so. Klar. Da gibts noch Verbesserungspotential. Aber es ist ja nun nicht so, das es da gar keine Gemeinsamkeiten gibt.

Solange ein und die selbe biary auf manchen distris läuft und auf andren segfaulted sind die Gemeinsamkeiten bei weitem nicht ausreichend.

OSS hat am wenigsten Probleme damit, weil sich ja die Distributionen i.d.R. um die Anpassungen kümmern.

Das ist zu kurz gedacht, aktiv entwickelte OSS ja, aber de facto gibt es doch unter Linux kein lauffähigen back Katalog an nicht mehr unterstützter Software. Hat ein packet mal kein maintainer mehr ist nach wenigen Jahren nicht mehr lauffähig.
Während ich unter Windows selbst irgendwelche obskuren Tools von 1999 und davor ausführen kann und die laufen und funktionieren.

Wie bereits beschrieben, davon wurde sich verabschiedet. Da eine Weiterentwicklung von Protokoll und Standardimplementierung so oder so zu einem X12 und Xorg2 geführt hätte mit tierischen Verrenkungen X11 kompatibel zu halten. An der Stelle hat man sich gesagt, ab mit den alten Zöpfen und für X11-Anwendungen gibt es eine Kompatibilitätsschicht.

Also wie den nun was den nun eine Kompatibilitätsschicht ist doch genau was ich ja fordere nur eine die noch um die paar fehlenden Aspekte erweitert wird.

Optionale Sicherheit ist ein Antipattern der Sicherheit.

Usability kommt für die meisten Nutzer nun mal vor Sicherheit.
Und das oft auch zurecht, weil Sicherheit kann wirklich immer nur im Kontext von konkreten Bedrohungsszenarien definiert werden, so was wie abstrakte Sicherheit gibt es nicht.
Die Notwendigkeit Desktop Anwendungen von einander abzuschotten verbessert nur in bestimmten Szenarien die Sicherheit, in anderen ist es schlicht und ergreifend irrelevant aber für den Nutzer störend.

z.B. würde ich so weit gehen zu sagen jeder PC auf dem man kein Banking, Crypto Wallet oder dergleichen macht und keine geschefts geheimnisse speichert da ist es jacke wie hose, scheixx egal so zu sagen. Man stellt sich nur zwei Beine und verhindert damit aber keinen nennenswerten missbrauch.

Andererseits gebe ich zu bedenken das unter Linux (wie unter Windows) ein prozess von einem user alle anderen prozesse von des selben users debugen kann.
Wozu brauche ich screenshots und maus steuern wenn ich einfach in dein passwort manager oder crypto wallet code direkt injizieren kann?

Die sicherheit von Wayland ist stand heute deswegen eigentlich nutzelos.
Die macht nur sinn wenn man im nächsten schritt jede anwendung als eigener nutzer ausfphrt (so ähnlich wie es afaik android macht) oder die anwendungen anderwaltig containerisiert.

Und für dieses ncihts werden millionen menschen die workflows kaputt gemacht, das ist doch Murks.

Zudem hätte X11 mit Namespaceerweiterung das Problem, dass es in den Händen von Applikationsentwicklern gelegen hätte, bevor es in den Händen der Nutzenden wäre. Denn die Applikationsentwickler müssen ihre Anwendungen auf die nicht im Protokoll vereinbarte Lösung hin anpassen. Was mehr Fragmentation der Unterstützung einer solchen, optionalen Erweiterung bedeutet.

Eben nicht wenn man es richtig implementiert würde out of the box alles funktionieren und sich wie X11 verhalten keine extra sicherheit die (sihe oben) keienr braucht (weiles noch einfachere angrifs vektoren gibt) Applikationsentwicklern könnten aber wenn sie es unterstützen wollen ein mehr an sicherhiet für ihre anwendungen aktivieren. Resp der nutzer hötte ein hacken um das system weit dennoch zu unterdrücken oder ausnahemn zu generieren.

Er sagt deutlich, dass die Fragmentierung nachteilig für Entwickler kommerzieller Software sei. Und im Nachsatz relativiert er das wieder, indem er die Situation als sehr vorteilhaft für Open-Source-Entwickler bezeichnet.

Was willst du uns also mit deinem halben Torvalds-Zitat eigentlich mitteilen?

Nun sein erster impuls war erlich er hat ziemlsihc shcnell und energtisch kritikausgeteilt und zurecht festgehalten das die fragmentiereung alles ausbremmst.
Dan her er erst zurück gerundern und um Open-Source herumgeschwurbelt.
Da kan jeder selbst zwischen den zeien lesen wie das zu verstehen ist.

 

[GrillSgt]

Er ist auch nur ein Mensch.

Und einer mit nem Hang zur Cholerik dazu.

Das Problem in vielen OpenSource Projekten ist eben, dass oft ein loser Haufen Menschen miteinander arbeitet die zwar grundlegend, grob, das selbe Ziel, aber eben auch alle ihre Vorstellungen davon haben in welche Richtung sich das entwickeln soll bzw. wie diese Ziele genau aussehen sollen und sie zu erreichen sind. Sind die Hürden dann unüberwindbar, gibt's nen Fork. (zu viele Köche etc.).

In nem Unternehmen herrscht ne Art von Autokratie. Da ist in Erster Linie das zu tun, was das Unternehmen vorgibt. Mit der Ausrichtung mag der ein oder andere zwar auch nicht einverstanden sein, aber die Spielregeln bestimmt halt der Brötchengeber.

 

[Stovi]

Anders formuliert: Der eigentliche Grund für die geringe Menge an proprietärer Desktop-Software ist nicht die Vielfalt der Distributionen, sondern die geringe Marktverbreitung von Linux.

Henne-Ei-Problem.
Für die 0815-Heimanwender geht es doch nur darum von welchem Distro wird (wann) ihre Hardware unterstützt.
Da kommt es einem schon so vor, als seien die verschiedenen Distros eigentlich nur aus dem Streit entstanden, wann man nun welche Pakete bereitstellt und wer wollte sich alles als Erfinder einer Distro einen Namen machen.
Die Vielfalt verteilt eben auch die endlichen humanen Ressourcen auf immer mehr Distros. Dadurch müssen Entwicklungsschritte in jeder Distro priorisiert werden. Würden mehr Entwickler für weniger Distros zur Verfügung stehen, so stünden mehr Ressourcen für eine schnellere und qualitativ hochwertigere Entwicklung zur Verfügung.
MS muss bei dem Mitbwerber Linux nichtmal das Prinzip teile und herrsche anwenden, um ihn klein zu halten, das macht die Linux-Community schon von ganz alleine.

 

[SirSinclair]

Bestes Zitat von Torvalds aus diesem Video:
"I don't understand why people don't require ECC Memory in their PCs because being able to trust your machine is like the numer one thing"

Ja ich verstehe das auch nicht, seit den 90er Jahren hatten alle meine Desktop PCs immer ECC Speicher, ich würde keinen PC ohne ECC Speicher akzeptieren.
(bei Laptops muß ich leider eine Ausnahme machen da es fast keine Laptops mit ECC Speicher gibt).

 

[Uzer1510]

Naja denke mit Opensource gibt es immer Distros

Irgendjemand wird halt wie jetzt eine komplett auf Gaming optimierte Distro bauen und irgendwer anders evtl eine die auf extrem schwacher Hardware läuft und der nächste eine die für AI Training durchoptimiert ist etc.

Weil bis ans Maximum optimieren auf einen Zweck halt auch Spass macht - das wird es immer geben und so eine Distro wird auch immer seine Fans haben.

Ich find das eigentlich gut.

 

[SavageSkull]

Bei den tausenden Distros ist es doch viel zu oft so, dass der Unterschied doch "nur" darin besteht, dass man eine Unterschiedliche Basis (Arch, Fedora, Debian) nimmt, einen DE nach Wahl draufpackt und eine handvoll Voreinstellungen getroffen hat.
Wirklich große einschneidende Unterschiede hat man doch selten. Wenn man im Desktop Anwender Bereich unterwegs ist und Mint, Ubuntu, Debian, Fedora, Manjaro, Pop!_OS und die nächsten 3 beliebten Distros anschaut sind abseits von DE Umgebung und entsprechend der gewählten Voreinstellung der DE für den Laien in seinem Anwendungsfall kaum Unterschiede. Wenn ein Programm auf X läuft, wird es sehr wahrscheinlich auch auf Y laufen.
Das ein Programm mal nicht im Repository auftaucht ist ja nichtmal ein Beinbruch und ggfls muß die Flatpak Kompatibilität erstmal eingerichtet werden.

Ich finde es wird zuviel Aufhebens um die Unterschiede bei den Distros gemacht.

@SirSinclair
Wie oft passiert den ein Bitflip im Speicher? Ist das heutzutage am Client überhaupt relevant? Wieviel Fehler bleiben noch übrig, wenn DDR5 mit on Die ECC benutzt wird?
Wenn mein PC statistisch 4 Monate am Stück dauerhaft rechnen muß, bis ein Bitflip stattfindet, hat ECC nachher für mich in der Praxis keine Relevanz.
Das hat halt auch was mit der Nutzung zu tun. Selbst beim Homeserver im Keller sehe ich jetzt noch nicht zwingend den Anwendungsfall.

 

[SirSinclair]

Wie oft passiert den ein Bitflip im Speicher? Ist das heutzutage am Client überhaupt relevant? Wieviel Fehler bleiben noch übrig, wenn DDR5 mit on Die ECC benutzt wird?

Laut Torvalds häufiger als du meinst, klar wenn der PC nur zum Spielen gedacht ist ist es egal, ich kompiliere aber auch viel (nein nicht den Linux Kernel wie Torvalds ) und wenn beim kompilieren ein Bitflip passiert dann ist danach das Binary fehlerhaft ohne das du es weißt.
Außerdem ist ECC Speicher im allgemeinen nicht nennenswert teurer das es sich lohnen würde ihn nicht zu kaufen.

 

[SavageSkull]

Laut Torvalds häufiger als du meinst

Kann man das auch in Zahlen fassen? Ich meine, irgendwer hat doch sicher eine wissenschaftliche Statistik zu dem Thema erstellt?

 

[SirSinclair]

Deine bevorzugte Suchmaschine kann dir sicher weiterhelfen.

 

[DavidXanatos]

Das Problem in vielen OpenSource Projekten ist eben, dass oft ein loser Haufen Menschen miteinander arbeitet die zwar grundlegend, grob, das selbe Ziel, aber eben auch alle ihre Vorstellungen davon haben in welche Richtung sich das entwickeln soll bzw. wie diese Ziele genau aussehen sollen und sie zu erreichen sind. Sind die Hürden dann unüberwindbar, gibt's nen Fork. (zu viele Köche etc.).

In nem Unternehmen herrscht ne Art von Autokratie. Da ist in Erster Linie das zu tun, was das Unternehmen vorgibt. Mit der Ausrichtung mag der ein oder andere zwar auch nicht einverstanden sein, aber die Spielregeln bestimmt halt der Brötchengeber.

Naja aber bei Android, VLC, Firefox, etc. pp. scheint es ennoch zu funktionieren es gibt meoste 1 oder 2 haupt branches und sonst nix und nciht wie beim desktop linug 1000 un 1 distris.

@SirSinclair ja das sehe ich genau so ECC ist ein muss

Ergänzung (1. Dezember 2025)

Also um mal bildlich zu verdeutlichen was ich von dem "mehr an Sicherheit" welches Wayland bittet halte:
Das ist so als würde man sich zuhause an jede Tür zu jedem Zimmer ein Schloss montieren wie man es normalerweise nur an den Eingangstüren hat.
Ist es sicherer, ja wen ein Verbrecher zum Fenster einsteigt kann er nur das eine zimmer ausrauben.
Aber wie viel umständlicher macht es einem den Alltag und das leben?
Dann doch lieber Einbruchssicherefenster und wenn man mal Gäste hat diese einfach nie aus den Augen lassen.

 

[Piktogramm]

Wie könnte man das erreichen , na z.b. in dem die linux fundation nicht nur den kernel macht sondern auch ein referenz userspace und für den verspricht auch dafür zu sorgen das die API über mehrere Jahrzehnte mindestens abwärtskompatibel bleibt.

Wie soll das irgendwer sicherstellen, vor allem über Jahrzehnte in der IT?
Über die Dekaden wurden die Normen (RFS) der IETF teils drastisch geändert.
Die Software Dritter erfuhr ebenso deutliche Änderungen mit mehreren Generationen an APIs.
Hardware(-interfaces) kam auf und ist nahezu komplett wieder verschwunden.

Du forderst schlicht Rückständigkeit in einem absurdem Ausmaß.
Mir würde dabei noch nichtmal einfallen, was eine Referenz Distribution beinhalten würde. Desktop, Server, Hackerkiste, Embedded, Realtime, .. Die Schwäche der Fragmentierung ist halt auch eine Folge dessen, dass die Anpassbarkeit des Kernels und folgend Distributionen viele, valide Anpassungen hergibt.

Eine Distribution wie du sie dir zu wünschen scheinst, mit technischen Schulden die weiter reichen als meine Jugend.. Ich würde sowas nicht mit dem Arsch anschauen. Mir ist das bei Windows schon zu übel, und da versucht Microsoft auch Zöpfe abzuschneiden.

Solange ein und die selbe biary auf manchen distris läuft und auf andren segfaulted sind die Gemeinsamkeiten bei weitem nicht ausreichend.

Software, die in Segfaults rennt, weil sie auf spezifische Hacks irgendwelcher weiteren Komponenten angewiesen ist, ist halt grundlegend Scheiße.
Der Xorg-Server ist da ein prägnantes Beispiel, der auf seine eigenen Hacks, Hacks in Treibern und die Treiber auf die Hacks vom X-Server angewiesen war/ist.

Das ist zu kurz gedacht, aktiv entwickelte OSS ja, aber de facto gibt es doch unter Linux kein lauffähigen back Katalog an nicht mehr unterstützter Software. Hat ein packet mal kein maintainer mehr ist nach wenigen Jahren nicht mehr lauffähig.
Während ich unter Windows selbst irgendwelche obskuren Tools von 1999 und davor ausführen kann und die laufen und funktionieren.

Was auch nur für Programme gilt, die einen Großteil bis Alle ihrer Abhänigkeiten statisch linken. Was besonders "lustig" wird, wenn man dann irgendwelche OpenSSL Komponenten findet, die grob so alt sind wie mein Abschlusszeugnis der Grundschule. Was ein gutes Zeichen dafür ist, dass Verschlüsselung/Hashing der Software nicht annähernd zeitgemäß ist.

Bei den typischen Repositories der Distributionen wird dynamisch gelinkt und wenn da passt dann im Gegenzug die Abhänigkeit mitunter nicht zu dem, was das Repo liefert. Dafür vergammeln die Abhänigkeiten eben nicht so gnadenlos wie unter Windows bzw. teils Flatpack, Docker, Snap..

So Schwarz und Weiß ist das nicht.

Also wie den nun was den nun eine Kompatibilitätsschicht ist doch genau was ich ja fordere nur eine die noch um die paar fehlenden Aspekte erweitert wird.

Ne, du forderst Sicherheitskonzepte kaputt zu machen, was mit Kompatibilitässchichten nichtsorecht klappt.

Usability kommt für die meisten Nutzer nun mal vor Sicherheit.
Und das oft auch zurecht, weil Sicherheit kann wirklich immer nur im Kontext von konkreten Bedrohungsszenarien definiert werden, so was wie abstrakte Sicherheit gibt es nicht.

Das widerspricht gängiger BestPractice und Lehrmeinung.

z.B. würde ich so weit gehen zu sagen jeder PC auf dem man kein Banking, Crypto Wallet oder dergleichen macht und keine geschefts geheimnisse speichert da ist es jacke wie hose, scheixx egal so zu sagen. Man stellt sich nur zwei Beine und verhindert damit aber keinen nennenswerten missbrauch.

Optionale Sicherheit ist und bleibt ein Antipattern.

Andererseits gebe ich zu bedenken das unter Linux (wie unter Windows) ein prozess von einem user alle anderen prozesse von des selben users debugen kann.
Wozu brauche ich screenshots und maus steuern wenn ich einfach in dein passwort manager oder crypto wallet code direkt injizieren kann?

Keine der großen Distributionen im Bereich Server/Desktop erlaubt es meines Wissens nach einfach so Speicherbereiche anderer Prozesse des selben Nutzers zu lesen, noch zu verändert. Da braucht es schon eskalierte Rechte.

Die sicherheit von Wayland ist stand heute deswegen eigentlich nutzelos.
Die macht nur sinn wenn man im nächsten schritt jede anwendung als eigener nutzer ausfphrt (so ähnlich wie es afaik android macht) oder die anwendungen anderwaltig containerisiert.

Sehr viel an Kritik an Wayland kommt aus aus Unwissend um Wayland und Linux. Die Aussage fällt ja auch in sich zusammen..

Und für dieses ncihts werden millionen menschen die workflows kaputt gemacht, das ist doch Murks.

Zugegeben ist nicht alles rosig. Remote Desktop geht, X-Forwarding wird über waypipe emulierbar, Screenrecording geht, Anwendungen die nur für X11 geschrieben sind laufen mit XWayland. Welcher Anwendungsfall geht denn bitte nicht?
Großartig kann ich mir nur vorstellen, dass es da um Softwareworkflows geht, die irgendwo aus dem Zeitraum der französischen Revolution stammen.

Wie oft passiert den ein Bitflip im Speicher? Ist das heutzutage am Client überhaupt relevant? Wieviel Fehler bleiben noch übrig, wenn DDR5 mit on Die ECC benutzt wird?
Wenn mein PC statistisch 4 Monate am Stück dauerhaft rechnen muß, bis ein Bitflip stattfindet, hat ECC nachher für mich in der Praxis keine Relevanz.
Das hat halt auch was mit der Nutzung zu tun. Selbst beim Homeserver im Keller sehe ich jetzt noch nicht zwingend den Anwendungsfall.

Ohne ECC zwischen Speicher und CPU erfährt man einfach überhaupt nicht ob/wann ECC nötig war. OnDie ECC nutzt da vergleichsweise wenig. Die Fehler schlagen meines Wissens in keinem Log auf und der Übertragsungsweg zwischen Ram und CPU ist heutzutage schnell genug, dass die Fehlerrate relevant über 0% liegt.

Bei Daddelkisten ist es egal. Das LinusT ist die Anwendung nur Größenordnungen kritischer und ein Bitflip über die gesamte Laufbahn als Maintainer ist ärgerlich genug.

 

[SirSinclair]

@DavidXanatos
Genau, Sicherheit ist immer ein Kompromiss, der Grad an Sicherheit muß im Verhältnis zum Risiko und zum Aufwand passen.

 

[Piktogramm]

Also um mal bildlich zu verdeutlichen was ich von dem "mehr an Sicherheit" welches Wayland bittet halte:
Das ist so als würde man sich zuhause an jede Tür zu jedem Zimmer ein Schloss montieren wie man es normalerweise nur an den Eingangstüren hat.
Ist es sicherer, ja wen ein Verbrecher zum Fenster einsteigt kann er nur das eine zimmer ausrauben.
Aber wie viel umständlicher macht es einem den Alltag und das leben?
Dann doch lieber Einbruchssicherefenster und wenn man mal Gäste hat diese einfach nie aus den Augen lassen

Naja aber bei Android, VLC, Firefox, etc. pp. scheint es ennoch zu funktionieren es gibt meoste 1 oder 2 haupt branches und sonst nix und nciht wie beim desktop linug 1000 un 1 distris.

Du meinst Android, welches mitunter für jedes Gerät eines jeden Herstellers ein eigener Fork ist, damit DeviceTress, proprietäre Treiber, GUI und Bloat angepasst sind? Wobei Android AOSP selbst mit Lineage, GraphenOS, /e/ div. Ableger hat?!

Firefox, geforkt zu TorBrowser, LibreFox, IceWeasel, Fenec, FireFox for iOS, Waterfox, IronFox, Pale Moon, FireFox Focus, IceCat, ...

Bei VLC fallen mir keine Forks ein, nur eine Liste an div. GUIs die mehr oder minder grafische wrapper für ffmpeg sind.

 

[andy_m4]

Wie könnte man das erreichen , na z.b. in dem die linux fundation nicht nur den kernel macht sondern auch ein referenz userspace und für den verspricht auch dafür zu sorgen das die API über mehrere Jahrzehnte mindestens abwärtskompatibel bleibt.

Wie bereits gesagt: Wir haben solche Systeme. Also auch Open-Source-Systeme. Das hatte offensichtlich keinen signifikanten Impact auf deren Verbreitung/Erfolg.
Und wie auch schon gesagt, gibt es übergreifende Standards.

Das grundlegende Problem ist halt, Linux und deren Ökosystem ist stark vom building-blocks-Ansatz geprägt. Du hast an vielen Stellen mehrere Lösungen für ähnliche Probleme. Das hat den Vorteil der Anpassbarkeit auf eigene Bedürfnisse und auch ein Wettbewerbscharakter der zu einer dynamischen Entwicklung führt.. Nimmst Du das weg und gehst eher in Richtung "Einheitslösung" dann ist es sicher einfacher Software dafür zu machen, aber Du verlierst auch den Vorteil der Anpassbarkeit und die Dynamik in der Entwicklung.

Die Frage die bleibt (und die Du unbeantwortet lässt): Warum sollte man das machen angesichts dessen, das es ja bereits genug unified-Betriebssystemplattformen gibt?

Und selbst wenn man sagt, man begrenzt das Referenzlinux auf einen bestimmten Bereich:
Wo willst Du da genau die Grenze ziehen? Es gäbe sicher unterschiedliche Vorstellungen darüber, wo die zu ziehen wäre.

Wäre es kein krampf in A*** sondern sehr einfach worden komerzielle software anbieter es eher machen weil einpaar % mehr nutzer sind einpaar % mehr nutzer und wen es nicht messbahr kosten/zeit verschlingt wieso nicht.

Die hätten ja die Möglichkeit ihre Software zu containern.
Wird ja übrigens auch in vielen Bereichen gemacht: Stichwort docker.
Das zeigt doch, das Dein Argument nicht haltbar ist.

Solange ein und die selbe biary auf manchen distris läuft und auf andren segfaulted sind die Gemeinsamkeiten bei weitem nicht ausreichend.

Dann hast Du das Binary nicht gut gemacht.
Wenn ich sehe, das das Leute hinbekommen und andere eben nicht, dann liegts vielleicht nicht am System, sondern an den Leuten.

Das ist zu kurz gedacht, aktiv entwickelte OSS ja, aber de facto gibt es doch unter Linux kein lauffähigen back Katalog an nicht mehr unterstützter Software.

Den Punkt gebe ich Dir. Allerdings hat das auch irgendwo seinen Preis. Gerade Microsoft hat in ihrem Windows sehr viel Wert auf Kompatibilität gelegt. Die haben sich dafür aber auch ein massives Komplexitätsproblem eingefangen und eine kaum noch beherrschbare Codebase. Nicht umsonst hat man dann irgendwann angefangen das aufzuräumen und so hatte man in den letzten Jahren auch vermehrt Kompatibilitätsprobleme.

Nicht umsonst ist man dazu übergegangen Kompatibilität mit Hilfe von Virtualisierung zu realisieren (also auch bei Microsoft).

Und alles hat halt so seine Vor- und Nachteile. Du guckst aber immer nur auf die Nachteile und willst auch auf Krampf, das sich das Linux-Ökosystem darauf anpasst.
Und das verstehe ich irgendwie nicht. Wenn Dir das nicht gefällt (und das kann man ja so sehen; dagegen ist ja gar nichts zu sagen) warum gehst Du dann nicht einfach zu einer Plattform, die das bietet?
Warum willst Du stattdessen anderen "vorschreiben" wie sie ihre Software zu entwickeln haben?

Ich bin auch nicht mit allem einverstanden und bin auch insbesondere über dieses Volatile bei Linux-Systemen eher unglücklich. Ich bin aber trotzdem froh, das die das so machen und das ich damit die Möglichkeit habe zu Linux zu greifen, wo deren Vorgehensweise ihre Vorteile haben.
Es wäre ein Verlust, wenn man es bei Linux so machen würde wie überall anders auch.

Mal davon abgesehen kannst Du Langzeit-Stabilität auch bei Linux haben. Du brauchst ja nur zu einem der Enterprise-Distributionen zu greifen. Zum Beispiel Redhat Enterprise Linux hat 10+ Jahre Support. Und Du musst nicht mal Geld dafür ausgeben, wenn Du auf einen der Klone wie Rocky Linux zurückgreifst.
Da wird auch nicht nur ein Stand konserviert, sondern es gibt aktive Produktpflege und neue Features aber mit Augenmerk auf Kompatibilität.

Deine Forderung ist also sogar schon ein ganzes Stück weit erfüllt.

Andererseits gebe ich zu bedenken das unter Linux (wie unter Windows) ein prozess von einem user alle anderen prozesse von des selben users debugen kann.

Das geht aber auch nur, wenn Du das freischaltest.
Generell sind Prozesse voneinander geschützt. Deshalb braucht man ja auch sowas wie Shared-Memory wenn man Daten austauschen will.
Wo Du den Schutz nicht hast ist natürlich auf Dateisystemebene. Aber auch das kannst Du mit Bordmitteln realisieren, so das der Zugriff auf ein Dateisystemobjekt nicht nur von der UID abhängt, sondern auch vom Programm.

Anyway, der Grund für Wayland liegt ja am wenigsten bei der Sicherheit. Xorg ist einfach ein großer Haufen Software, der nicht nur veraltet ist (die Ursprünge liegen in den 80er Jahren!), sondern auch in der Zeit jede Menge Code aufgesammelt hat. Damit lässt sich nicht mehr vernünftig umgehen.

Und klar. Man könnte Xorg radikal entschlacken und damit wieder auf einen Stand bringen, wo man es mit vertretbaren Aufwand weiter entwickeln kann. Aber das würde dann aber auch die Kompatibilität brechen.

Und dann hätte man das gleiche Problem, was Du auf Wayland vorwirst: Mangelnde Kompatibilität und Programme von annodazumal laufen nicht mehr.

 

[gimmix]

Schade, dass hier weniger über den Auftritt von Linus Torvalds bei Linus Sebastian geredet wird, als über die speziellen Ansichten des Threaderstellers.

Ein anderer Thread über das LTT-Video wurde deshalb schon geschlossen, mit dem Verweis auf diesen Wusel hier.

 

[andy_m4]

Schade, dass hier weniger über den Auftritt von Linus Torvalds bei Linus Sebastian geredet wird, als über die speziellen Ansichten des Threaderstellers.

Naja. Aber der Thread wurde ja vom Threadaufsteller genauso aufgezogen.

Der hat ja nicht gesagt: "Schaut mal. Ein tolles Video. Lasst uns über den Inhalt reden".
Sondern das Video war ja nur ein Aufhänger, um zu sagen: "Lasst uns mal über meine Meinung zu Linux reden".

Insofern tut der Thread genau das, was eingangs versprochen wurde.

 

[gimmix]

Ja genau: Weil TE das Thema gekapert hat, kann man es jetzt nicht mehr hier diskutieren.

 

[garfield121]

Finde das Video mit Linus wenig aussagekräftig, eher langweilig.
Die Fragmentierung ist ja vorhanden, es gibt diverse Ein-Person-Distros, während gleichzeitig die etablierten Projekte an Personalmangel leiden. Wie könnte man das ändern?

 

[RedPanda05]

sagen, Linux erlebt den Durchbruch am Desktop 2027. Das sagen wir alle.

Xd die 800€ 1080p Maschine wird es bestimmt richten

 

[andy_m4]

Weil TE das Thema gekapert hat, kann man es jetzt nicht mehr hier diskutieren.

Achso. Jetzt verstehe ich erst, was Du meinst.

Und ja. Da stimme ich Dir zu. Das ist echt doof.

Die Fragmentierung ist ja vorhanden, es gibt diverse Ein-Person-Distros, während gleichzeitig die etablierten Projekte an Personalmangel leiden. Wie könnte man das ändern?

So richtig gar nicht.
Freie Software (und da ist Linux inkludiert) ist ja in erster Linie ein Freiwilligen-Projekt.
Sprich: Jemand hat Lust was zu machen und macht das dann auch.

Von daher sind diese ganzen Dinge die so in die Richtung gehen a-l-a: "Wenn nur alle an einem Strang ziehen würden...." obsolet.

Um mal bei dem Distributionsbeispiel zu bleiben, ums konkret. Wenn jemand Lust hätte bei Debian mitzumachen, dann könnte er das ja tun. Hindert ihn ja kein Mensch daran. Der hat also seine Gründe eine eigene Distribution zu starten. Die müssen wir auch nicht logisch oder nachvollziehbar finden.

Das Ding ist aber, wie willst Du den jetzt dazu bringen dann doch bei Debian mitzuarbeiten ohne das das was von Zwang hat oder ihm die Fähigkeit abzusprechen für sich seine eigenen Entscheidungen zu treffen?