Welches BSD ist systemd und Wayland frei?
- Ersteller rrbs
- Erstellt am
Früher oder später wird es was Ähnliches (... siehe z. B. den systemd-fork "initware"), auch in den BSDs geben, oder?
lme
FreeBSD Committer
Alle. systemd gibt's nicht und Wayland ist ein "kann", kein "muss". X11 läuft auf allen BSDs.
Sogar original mit globalem Message Bus. Wie 1995, für die extra Portion Nervekitzel.
pit234a
Well-Known Member
dafür habe ich aber gerade labwc oder vielmehr sfwbar in labwc (also auf wayland) gefunden. Kann auch ganz munter machen...
FreeBSD, nur davon will ich reden, weil ich die anderen BSDs lange nicht angesehen habe, aber im Grunde verhält es sich mit denen sehr ähnlich und ist in etwa das, was man unter einem GNU/Linux versteht.
Linux ist ein Kernel, GNU läuft darauf als "Unix-Ersatz".
FreeBSD hat einen Kernel und auch einen "Unix-Ersatz".
Alle weitere SW muss zusätzlich installiert werden und das bedeutet, dass man sehr viel Freiheit hat, was die Wahl seines Systems und erst recht des Desktops angeht. Es bedeutet aber auch, dass FreeBSD nicht mit einem vorinstallierten und vorbereiteten Desktop daher kommt, wie man das ja von vielen GNU/Linux-Distributionen kennt. Das muss man selbst machen.
Nunja. Eine neue sytemd-Diskussion will keiner: FreeBSD ist her sehr altmodisch und nutzt quasi ein rc-init-Modell, das man wohl auch schon in den 90ern hatte oder sogar schon früher. Das wird sicher eines Tages auf die Agenda kommen und erneuert werden.
Bis dahin leben wir altmodisch.
Viel eher interessieren mich Argumente, die gegen Wayland sprechen.
Ich bin gerade dabei, meine ersten Schritte im Wayland zu gehen und finde das so viel besser und geiler, als das total veraltete und nicht mehr lange supportete X.
Was kann man denn dagegen haben?
Ich gebe ja zu, dass ich oben etwas getrollt habe
Andy_m4
Well-Known Member
Die Ursprünge liegen in den 80er Jahren.
Die Variante, die im Grunde bis heute in FreeBSD enthalten, kam (2003) ursprünglich von NetBSD.
siehe dazu auch die Release-Notes von FreeBSD 5.0:
Ob da FreeBSD altmodisch ist ... also ja. Zum Teil. Man muss aber auch sagen, das bei Linux der Leidensdruck größer war. Die hatten ja bis dato im Wesentlichen Sys-V-Init, wo auch nur sporadisch mal was dran weiter entwickelt wurde. Da waberte also schon länger mal die Idee rum das zu ersetzen und es gab ja auch einige Kandidaten. Mit Upstart hat das Thema dann auch spürbar an Fahrt aufgenommen. Und gipfelte dann (Stand heute) in systemd. Welches ja nicht nur ein Init-System ist, was Daemons startet, sondern auch andere Augaben übernimmt (Daemon-Supervision) und Dinge erleichtert (deklarative Init-"Skripte") und vor allem ja auch ein distributionsübergreifendes Framework darstellt.
Gerade letzteres spielt eine durchaus eine wichtige Rolle, glaube ich. Da es bei Linux ja üblich ist, das man (viele) Distribution hat, sind Linux-Systeme sehr heterogen. Und systemd hilft die sich daraus ergebenen Probleme so ein bisschen abzumildern. Für die BSDs wäre ein solcher Effekt ohne Belang, da es hier das Distributions"problem" gar nicht gibt.
marmorkuchen
Well-Known Member
Auch wenn ich persönlich mittlerweile meinen Frieden mit SystemD geschlossen habe, ich muss halt täglich damit arbeiten, so finde ich noch immer SMF von Solaris die eindeutig bessere Variante. Sollte FreeBSD also mal de Meinung sein aufschließen zu müssen, dann bitte liebere SMF adaptieren
Andy_m4
Well-Known Member
Ich kenne jetzt Solaris' SMF nicht in der Tiefe. Welche Dinge würdest Du Dir denn wünschen, die in FreeBSDs Init-System einfließen sollten?
Ich selbst muss sagen, das ich mit rc-init im Großen und Ganzen zufrieden bin. Es ist einfach und robust und unauffällig und macht seinen Job.
Ok, es bootet nicht besonders schnell was auch der fehlenden Parallelität geschuldet ist. Allerdings bedeutet keine Parallelität ja auch, das es sich deterministisch verhält. Das ist mir also nicht so wichtig. Ein funktionierendes Resume bei Standby wäre mir wichtiger und dann braucht man auch keine schnellen Bootzeiten.
Wobei sich sowas wie Parallel-Startup vermutlich noch relativ leicht implementieren könnte. Weil Abhängigkeitsdeklarationen hat man ja eh und mit rcorder(8) kann man das ja auch bequem auswerten. Das sollte man also eigentlich schnell hinkriegen.
Deklarative Startup-Konfigs sind nett. Aber im Grunde hat man das ja schon fast. Ein einfaches rc-Script besteht im Wesentlichen aus Variablendeklarationen.
So was wie Service-Supervision ist auf jeden Fall nett. Kriegt man hingebastelt, indem man zum Beispiel daemon(8) verwendet. Aber ja, das im rc-System integriert zu haben, wäre nett.
Wobei natürlich jedes Feature auch ein Stück von der Einfachheit des rc-init weg nimmt. Da ist dann immer die Frage, ob man das wirklich will.
Sowas wie Socket-Activation wie es systemd oder auch launchd hat, wäre auch nett. Die Idee dahinter ist ja, das wenn ein Daemon auf einen Socket (e.g. Netzerkport) lauscht, das das das Init-System (bzw. ein leichtgewichtiger Sub-Prozess) das macht. Und wenn da Daten rein kommen, werden die schon mal gepuffert während der eigentliche zugehörige Service gestartet wird, und an dem dann die Daten und der Socket übergeben.
Auch 'ne nette Sache, weil dann ein Daemon nicht immer laufen muss, sondern erst dann, wenn er wirklich gebraucht wird.
Ist ja auch so eine Art von ereignisgesteuertes Verarbeiten. Das ist ja auch so einer der Kerngedanken bei systemd. Ereignissteuerung bis so richtig weitgehend mache und auf Events reagieren egal, ob die nun vom User bzw. einem Programm angeschubst werden oder von einem dev-Event oder Socket-Activation. Und das mit all dem anderen Kram wie Dependency-Managment. Im Grunde ist systemd ein Framework für Ereignisbehandlung.
Und dieser Grundgedanke an systemd ist ja im Prinzip auch nicht verkehrt und nicht wirklich kontrovers. Das ist ja mehr oder weniger das drumherum und die Komplexität, die es hat. Und viel hängt sicherlich auch an den Personen, die da so involviert sind und deren Auftreten und Umgang mit Feedback. Will sagen: Eine große Rolle (wenn nicht gar die Größte?) spielt da sicherlich der menschliche Faktor und nicht nur das Technische.
Alle und ich glaub nicht, dass rc.d auf absehbare Zeit ersetzt wird. Anders als bei nicht-OpenRC Systemen unter gibt's da keinen Grund und die OpenRC-Linux-Systeme (Gentoo und Alpline) sind auch dabei geblieben.
Aals Bonus kommst du übrigens unter OpenBSD und ich glaube wenn du Ports/Packages selbst kompilierst auch unter FreeBSD ohne Pulseaudio und Co aus, sondern bekommst tatsächlich funktionierenden Sound. (Potentiell halt ohne Bluetooth
)
Ich arbeite seit Ewigkeiten tagtäglich mit systemd, kenne es recht gut, auch dezidiert Software die da drauf aufbaut gebaut und finde es immer noch Schrott. Wobei der Init-Teil noch eher das kleinste Problem daran ist. Unit-Files überschreiben ist im Vergleich zu Optionen wie unter FreeBSD aber auch doof und fehleranfällig. Und das daemon(8) Tool macht die meisten Sachen die Leute von systemd wollen (restart- und signal-handling und logging).
Xorg hast du auf allen BSDs. Wayland gibt's glaub ich mittlerweile auf allen inoffiziell.
Ich glaube auch, dass Replacements für rc.d eher inoffiziell kommen würden, aber eigentlich will und braucht das niemand.
Wie ja schon erwähnt wurde war ja bei Linux ein großer Grund dass die großteils nix anständiges hatten, sondern SysV style Init, das einfach ein Frickelding ist/war. OpenRC hat immer gemacht was es sollte und war leicht zu verwenden und flexibler.
Aber das Problem sind ja die ganzen anderen systemd-Dinge. Journald, hostnamed, resolved, timesyncd, networkd, tmplfiles, etc. Systemd kommt passend dazu ja mittlerweile auch mit einem systemd-bsod.
EDIT: Oh jetzt war das doch ein systemd-Rant. Oops.
The inetd utility appeared in 4.3BSD. Das ist 1986 rausgekommen. socat geht auch in die Richung.
Aals Bonus kommst du übrigens unter OpenBSD und ich glaube wenn du Ports/Packages selbst kompilierst auch unter FreeBSD ohne Pulseaudio und Co aus, sondern bekommst tatsächlich funktionierenden Sound. (Potentiell halt ohne Bluetooth
)Ich arbeite seit Ewigkeiten tagtäglich mit systemd, kenne es recht gut, auch dezidiert Software die da drauf aufbaut gebaut und finde es immer noch Schrott. Wobei der Init-Teil noch eher das kleinste Problem daran ist. Unit-Files überschreiben ist im Vergleich zu Optionen wie unter FreeBSD aber auch doof und fehleranfällig. Und das daemon(8) Tool macht die meisten Sachen die Leute von systemd wollen (restart- und signal-handling und logging).
Xorg hast du auf allen BSDs. Wayland gibt's glaub ich mittlerweile auf allen inoffiziell.
Ich glaube auch, dass Replacements für rc.d eher inoffiziell kommen würden, aber eigentlich will und braucht das niemand.
Wie ja schon erwähnt wurde war ja bei Linux ein großer Grund dass die großteils nix anständiges hatten, sondern SysV style Init, das einfach ein Frickelding ist/war. OpenRC hat immer gemacht was es sollte und war leicht zu verwenden und flexibler.
Aber das Problem sind ja die ganzen anderen systemd-Dinge. Journald, hostnamed, resolved, timesyncd, networkd, tmplfiles, etc. Systemd kommt passend dazu ja mittlerweile auch mit einem systemd-bsod.
EDIT: Oh jetzt war das doch ein systemd-Rant. Oops.
The inetd utility appeared in 4.3BSD. Das ist 1986 rausgekommen. socat geht auch in die Richung.
Zuletzt bearbeitet:
pit234a
Well-Known Member
Und auf die Schnelle möchte ich das ergänzen, damit man das nicht falsch versteht: wenn ich sage, dass FreeBSD hier sehr altmodisch ist, meine ich das absolut nicht negativ!
Für mich ist es gut, wie es gerade ist und ich möchte es gar nicht anders haben.
Naja, einige Dinge wünscht man sich immer und es geht ja auch dauernd voran, aber dass man bisher nicht ins Auge gefasst hat, das komplette BootSystem (und noch viel mehr) neu zu machen, um einige Zehntel-Sekunden schneller am Start zu sein, passt gut zu mir. Ich boote nämlich nur selten und würde so etwas gar nicht zu würdigen wissen, hingegen schon, dass ich eben nicht für jeden Firlefanz neu starten muss.
Leider gibt es nicht den großen Plan eines Multimilliardärs, der FreeBSD unabhängig erhalten will und weil fast alles nur kompatibel zum Linux-Land gebaut wird, fürchte ich hier einfach dessen Einfluss auf die zukünftige Entwicklung.
Ich fürchte das, ich heiße es nicht willkommen. Ich bin altmodisch und lebe gut mit altmodischem FreeBSD.
Irgendwas wird sich der TE mit dieser Frage ja gedacht haben?
Aber was, das interpretieren wir alle in den vorhergehenden Beiträgen nach unsrer Neigung.
Ich habe das so verstanden, dass der TE diese beiden Dinge nicht mag. Ob technologisch oder ideologisch motiviert, konnte ich nicht erkennen. Was ich dann bezwecken wollte, war es, diese Frage ein wenig herunter zu brechen und klar zu machen, dass es kein gutes technologisches Argument gibt. Davon abgesehen, dass man bei FreeBSD in Punkto systemd gar keine Wahl hat.
neeh, das hört sich ja nach Drogen an: Wayland (und zugehörige Anwendungen) sind vollkommen legal und offiziell für FreeBSD zu haben und meist sogar als Binär-Paket vorhanden. Wenn die anderen BSDs mit ihren Sicherheits-Bedenken nicht so schnell nachkommen, wird sich das in absehbarer Zeit drastisch ändern müssen. X ist tot, endlich und Gott sei Dank!
Sorry, aber das ist kompletter Stuss was du da redest. Wayland unterstützt offiziell Linux und sonst nichts. Dass FreeBSD und auch Haiku das unterstützen und die Software portiert haben ändert daran nichts. Das mit Legalität hast du herfantasiert, davon hat niemand was geredet. Siehe Wikipedia, Wayland Readme, das große weite Web. Ich hab mal den restlichen Unfug den du so schreibst weggelassen, aber ist alles genauso absoluter Schwachsinn.
pit234a
Well-Known Member
das hat mich verleitet.
inoffiziell ist natürlich nicht illegal!
Aber was für eine Aussage ist das denn?
Bei FreeBSD ist das Wayland doch im Handbook, das ist doch nichts 0,0 inoffiziell oder so?
Bei OpenBSD ist es in den Ports & Packages weil einige Programme das inzwischen als abhängigkeit haben, aber dafür muss es nicht laufen.
Was OpenBSD auch noch nicht macht, aber sicher irgendwann machen wird. Mittelfristig wird kein weg um Wayland herumkommen. Ich empfinde das aber als eine komplett andere Problematik als das SystemD krams.
Wenn ich @Yamagi richtig verstanden sind an Wayland auch viele X entwickler beteiligt, die einfach festgesteltl haben das X aufgrund des sehr hohen alters einfach nicht mehr allen modernen Anforderungen genügt und haben deshalb einen sinnvollen nachfolger entwickelt. Ich glaube Yamagi hat das hier ganz gut eigentlich dagelegt und das lässt sich denke ich auch kaum weg diskutieren:
Einige von den "Limits" sind mir z.B. auch aufgefallen, wie z.B. zuverlässiges, gut aussehendes Scaling insbesondere wenn man mehrere Monitore mit unterschiedlichen Auflösungen gleichzeitig betreibt. Und Wayland funktioniert bei mir seit Sommer letzten Jahres absolut zuverlässig (Unter Archlinux mit Systemd)
-Nuke-
Well-Known Member
Xorg (oder sollte ich sagen XFree86?) hatte halt eine lange Historie von "Every problem is solvable with another layer of indirection" (Jedes Problem ist mit einem weiteren Abstraktionslayer lösbar).
X11 war eigentlich schon vor ~25 Jahren (weiter) abgehängt. Apple hatte mit Mac OS X und Microsoft mit Vista komplett hardwarebeschleunigte Oberflächen eingeführt, während man unter BSD/Linux noch froh war, wenn der Grafiktreiber hier überhaupt derartigen Support für dieses "neumodische 3D" hatte.
Es gab darum natürlich auch hier Bemühungen aufzuschließen (haha). Es wurde nicht nur an Xgl bzw. Xegl gearbeitet, sondern auch natürlich auch Versuche es doch noch irgendwie mit Xorg (bzw. damals Xfree86) hinzubekommen. Daraus entstand dann die AIGLX Extension, die dann auch der Sargnagel für eine ordentliche Reimplementieurng von X11 war. Ganz nebenbei am Rande startete auch die Planung von diesem ominösen "Wayland".
Aber naja, AIGLX hatte das Problem dann doch irgendwie umschifft und man konnte mit dem alten Kahn doch irgendwie noch hardwarebeschleunigte Oberflächen erzeugen. Es sprudelten eine Reihe von Xorg Compositoren hervor, die allesamt recht mies waren. KDE hatte z.B. bis zuletzt eher empfohlen den Compositor aus Performancegründen abzuschalten (z.B. beim Gaming) bzw. tat dies sogar automatisch. Grundlegende Probleme blieben erhalten. Multimonitor und Tearing sind z.B. bis heute ungelöste Probleme. Der einzige Vorteil war, dass der Bedarf an ordentlichen Grafiktreibern stieg und auch einer passenden Rendering-Infrastruktur darüber.
Hier kam dann natürlich auch Nvidia ins Spiel, die so ziemlich alles blockiert haben, was irgendwie dazu führen würde, dass ein Linux Desktop auch auf Nicht-Nvidia Hardware gut laufen würde. Auch dieses Konzept dieses ominösen "Waylands" war grundsätzlich auf Nvidia Treibern nicht möglich.
Aber naja, viel Zeit verging. Treiber anderer Hersteller wurden besser. Der Trotz der Community stieg und gipfelte im Stinkefinger von Linus Torvalds vor laufender Kamera Richtung Nvidia. Und das sieht man halt jetzt. Die Leute scheren sich nicht mehr groß darum was Nvidia will. Entweder Nvidia bewegt sich (was sie tatsächlich tun, wenn auch langsam), oder der Zug fährt ohne sie weiter. Und hier kommt nun Wayland ins Rampenlicht.
Fairerweise muss man sagen, dass jetzt auch Wayland nach grob 20 Jahren vom Konzept her auch nicht mehr sehr frisch ist. Man hätte es vor 10 Jahren schon stark fokussieren müssen, aber hier war halt einfach keine Bewegung vom Rest drinnen. Aber Nvidia wollte nicht kompatibel sein und auch Ubuntu meinte, sie würden mit "Mir" lieber was eigenes machen und eine Anti-Wayland Kampagne fahren. Das hat natürlich alles unnötig nach hinten geworfen.
Der Vorteil von Wayland ist aber, dass das Protokoll mehr die Intention der Anwendung definiert, statt sich (nur) auf das Rendering zu konzentrieren. Sprich use-cases lassen sich leichter ablesen und auch ein mögliches "Wayland 2" startet nicht von 0. Also ähnlich wie der Weg PulseAudio -> PipeWire.
Viel Kritik an Wayland ist oft einfach nur grober Unsinn. Es ist natürlich nicht so, dass alles perfekt ist. Aber immerhin sind hier saubere Lösungen möglich. Wer auf Xorg bleiben möchte, kann dies natürlich tun. Aber hier ist es wie immer bei Open Source Entwicklung: Wenn man kostenlos die Arbeit anderer genießt, dann folgt man dem was der Entwickler möchte, oder man muss es selbst tun. Und Support für X11 wird über kurz oder lang aus den Desktop Umgebungen und Anwendungen rausfliegen.
X11 war eigentlich schon vor ~25 Jahren (weiter) abgehängt. Apple hatte mit Mac OS X und Microsoft mit Vista komplett hardwarebeschleunigte Oberflächen eingeführt, während man unter BSD/Linux noch froh war, wenn der Grafiktreiber hier überhaupt derartigen Support für dieses "neumodische 3D" hatte.
Es gab darum natürlich auch hier Bemühungen aufzuschließen (haha). Es wurde nicht nur an Xgl bzw. Xegl gearbeitet, sondern auch natürlich auch Versuche es doch noch irgendwie mit Xorg (bzw. damals Xfree86) hinzubekommen. Daraus entstand dann die AIGLX Extension, die dann auch der Sargnagel für eine ordentliche Reimplementieurng von X11 war. Ganz nebenbei am Rande startete auch die Planung von diesem ominösen "Wayland".
Aber naja, AIGLX hatte das Problem dann doch irgendwie umschifft und man konnte mit dem alten Kahn doch irgendwie noch hardwarebeschleunigte Oberflächen erzeugen. Es sprudelten eine Reihe von Xorg Compositoren hervor, die allesamt recht mies waren. KDE hatte z.B. bis zuletzt eher empfohlen den Compositor aus Performancegründen abzuschalten (z.B. beim Gaming) bzw. tat dies sogar automatisch. Grundlegende Probleme blieben erhalten. Multimonitor und Tearing sind z.B. bis heute ungelöste Probleme. Der einzige Vorteil war, dass der Bedarf an ordentlichen Grafiktreibern stieg und auch einer passenden Rendering-Infrastruktur darüber.
Hier kam dann natürlich auch Nvidia ins Spiel, die so ziemlich alles blockiert haben, was irgendwie dazu führen würde, dass ein Linux Desktop auch auf Nicht-Nvidia Hardware gut laufen würde. Auch dieses Konzept dieses ominösen "Waylands" war grundsätzlich auf Nvidia Treibern nicht möglich.
Aber naja, viel Zeit verging. Treiber anderer Hersteller wurden besser. Der Trotz der Community stieg und gipfelte im Stinkefinger von Linus Torvalds vor laufender Kamera Richtung Nvidia. Und das sieht man halt jetzt. Die Leute scheren sich nicht mehr groß darum was Nvidia will. Entweder Nvidia bewegt sich (was sie tatsächlich tun, wenn auch langsam), oder der Zug fährt ohne sie weiter. Und hier kommt nun Wayland ins Rampenlicht.
Fairerweise muss man sagen, dass jetzt auch Wayland nach grob 20 Jahren vom Konzept her auch nicht mehr sehr frisch ist. Man hätte es vor 10 Jahren schon stark fokussieren müssen, aber hier war halt einfach keine Bewegung vom Rest drinnen. Aber Nvidia wollte nicht kompatibel sein und auch Ubuntu meinte, sie würden mit "Mir" lieber was eigenes machen und eine Anti-Wayland Kampagne fahren. Das hat natürlich alles unnötig nach hinten geworfen.
Der Vorteil von Wayland ist aber, dass das Protokoll mehr die Intention der Anwendung definiert, statt sich (nur) auf das Rendering zu konzentrieren. Sprich use-cases lassen sich leichter ablesen und auch ein mögliches "Wayland 2" startet nicht von 0. Also ähnlich wie der Weg PulseAudio -> PipeWire.
Viel Kritik an Wayland ist oft einfach nur grober Unsinn. Es ist natürlich nicht so, dass alles perfekt ist. Aber immerhin sind hier saubere Lösungen möglich. Wer auf Xorg bleiben möchte, kann dies natürlich tun. Aber hier ist es wie immer bei Open Source Entwicklung: Wenn man kostenlos die Arbeit anderer genießt, dann folgt man dem was der Entwickler möchte, oder man muss es selbst tun. Und Support für X11 wird über kurz oder lang aus den Desktop Umgebungen und Anwendungen rausfliegen.
Andy_m4
Well-Known Member
Ja. Ich kenne inetd natürlich und verwende es sogar für einige Sachen.
Und ja, da gibts gewisse Ähnlichkeiten. Aber Socket-Activation ist etwas anders und vor allem ist es allgemeiner. inetd ist ja vor allem fürs "Netz" gedacht, weshalb es ja auch den Namen hat, den es hat. Socket-Activation ist ein generischer Ansatz, der auch für (lokale) Interprozesskommunikation benutzt werden kann. Also z.B: auch sowas wie der Soundserver oder was man auch alles an Daemons/Services hat.
Das hat dann bezogen aufs bereits erwähnte Abhängigkeitsmanagement zwei Vorteile:
Erstens ist brauche (zumindest in den Fällen wo ich das benutze) Abhängigkeiten nicht mehr manuell zu deklarieren. Ich benutze einfach den "Socket" und der dahinter stehende Dienst wird gestartet. Zweitens kann ich mit zyklischen Abhängigkeiten umgehen. Beispielsweise wird beim Bootup ein mount-Daemon gestartet und der will loggen aber syslog ist noch nicht da. syslog kann aber wiederum nicht loggen, weil die Platte noch nicht da ist, weil der mount-Daemon noch nicht durch ist. Mit Socket-Activation sind solche Szenarien kein Problem, weil dann das Log erst mal gepuffert wird und erst an syslog weitergereicht wird, wenn der der da ist.
Und wenn man mal Richtung MacOS X guckt, dessen launchd setzt sehr stark darauf und macht quasi alles damit.
Wayland selbst ist ja lediglich ein Protokoll und hat somit erst mal keine direkte Bindung an ein System. :-)
Ja. Aber nicht nur das. Wayland ist auch schwerer zu implementieren. In der X11-Welt war der X-Server da, der sich um alles kümmerte und die Komponente hat man ja quasi nicht. Die Desktop-Umgebungen müssen sich also selbst drum kümmern. Und da wären Tools und Bibliotheken sicher hilfreich gewesen (inzwischen gibts die ja; aber lange Zeit gabs die nicht). Die Wayland-Leute haben stattdessen einfach gesagt: Hier ist das Protokoll und ein Demo-Programm wie man das nutzen könnte und nu viel Spaß damit.
Ja. Wobei der Auslöser des "Fingers" gar nicht unbedingt in Richtung der normalen Grafiktreiber ging, sondern konkret um nvidia Optimus, was so vor allem in Notebooks zum Einsatz kam. Aber ja, das war sicher nicht die alleinige Ursache.
Das geschieht ja durchaus auch durch sowas wie XLibre. Sicher muss man gucken, inwieweit das auch von Erfolg gekrönt sein wird, weil die natürlich die gleichen Probleme haben, mit denen auch die Xorg-Entwickler konfrontiert waren. Aber es ist zumindest nicht so, das man nur da sitzt und darüber auslässt, wie schlecht die Welt ist, weil keiner mehr was an Xorg macht.
Mal gucken. Üblicherweise überleben legacy-Technologien teilweise sehr lange.
Da brauchen wir ja nur mal auf das andere Thema des Threads rüberschauen. Sys-V-Init wird ja auch noch von einigen Distributionen benutzt oder zumindest als Option angeboten.
pit234a
Well-Known Member
Eine neue Diskussion über den Zustand von X (so im Sinne der Katze vom Schrödinger) möchte ich natürlich hier auch nicht antreten. Aber ich selbst fand die Funktionsvielfalt von X (also beinahe über alle Versionen hinweg) immer schon für viel zu gewaltig, um nur das bisschen Desktop zu machen. Da hatte ich mir schon lange eine Änderung gewünscht und was ich nun in Wayland mit Xwayland sehe, scheint vollkommen genug X zu bieten. Es gibt nur ganz selten mal Dinge, wo ich mich frage, ob das gehen kann, wenn ich so Späße treiben will und Jemandem auf einem anderen Display eine Nachricht schreiben möchte. Man sieht schon: vollkommen unnötige Dinge.
Weil wir inzwischen typischerweise nur noch Einzelplatzrechner mit Desktop haben (die ein X wollen), teile ich hier die Idee von @Yamagi und denke, dass die Zukunft eher nach Xwayland geht als nach Xorg.
Aber, wie gesagt: mit etwas Glück werden wir das wohl noch sehen können.
Andy_m4
Well-Known Member
Es geht ja bei solchen Dingen nicht zwangsläufig um irgendwelche Ewiggestrigen, die ihren X-Server rein aus Sturheit noch die nächsten 100 Jahre betreiben wollen, wenngleich es die natürlich auch gibt.
Aber nicht selten dürften das auch irgendwelche alten Applikationen geschuldet sei, die eben nicht Wayland-ready sind und nicht alle von denen lassen sich zur Zusammenarbeit mit XWayland überreden, weil die irgendwelche Dinge benutzen die XWayland nicht implementiert.
Und ja. Das ist vermutlich eher nicht die Zukunft. Das würde ich so auch niemals behaupten. Mein "Take" war ja nur, das alte Technologien lange überleben können.
pit234a
Well-Known Member
für solche Sachen ist aber dann schon heute eine VM besser geeignet, die man nicht updaten muss, sondern einfach einen Stand einfriert. Ich selbst habe immer noch ein Win-XP in einer VM, wo ich eine damals gekaufte SW einfach weiter benutzen kann.
Geht halt nur, wenn man das Ding auch gut vom Netz isolieren kann, weil leider je nach Anwendung nicht immer möglich ist. Aber ja, wir haben auch ne RHEL 4 VM im Betrieb, die sich um den Uraltdrucker im Lager kümmert (wurde seit Jahren nicht benutzt, aber falls die anderen ausfallen, oder man mal A2 braucht...).
Ist aber gar nicht mehr so einfach, alte Dinger auf neuen Systemen als VM laufen zu lassen. Ich hatte ja letztens zB das Problem, das ich ein altes FreeBSD brauchte, um meine GELI Verschlüsselte Platte zu öffnen. Hätts zuerst mit 9 probiert, da ich wusste, die Platte wurde unter 9 angelegt, das lief aber schonmal nicht auf Anhieb.
-Nuke-
Well-Known Member
Wobei Weston und libweston auch schon so gut wie immer ein Begleiter der Wayland-Implementierung war. Aber am Ende hat der Rest der Community lieber ihr eigenes Ding gemacht. Was jetzt keine Kritik sein soll.
War jetzt auch nicht in dem Zusammenhang gemeint, sondern einfach gegen die Auflehnung gegen Nvidia an sich.
Also selbst wenn man mal davon absieht, was der Hauptentwickler alles für geistige Störungen so hat, ist er auch fachlich nicht sonderlich gut. Und das fängt schon bei sowas simplen an wie, dass der Ausdruck "2^16" in C nicht "2 hoch 16" bedeutet, worauf man ihn MEHRFACH hinweisen musste. Aber soll er ruhig sein TempleX11 entwickeln.
Also dass uns X11 an sich noch eine ganze Weile begleiten wird ist klar. Was ich meinte ist, dass Desktop-Umgebungen und auch Anwendungen selbst über kurz oder lang (für GNOME bereits angekündigt) nicht mehr mit X11 funktionieren werden. Auch KDE hat schon Features in Entwicklung, die nur mit Wayland gehen.
D.h. sprich selbst wenn du bei Xorg bleiben willst, dir irgendwann die Desktop-Umgebungen und Anwendungen ausgehen werden, die du darauf zum Laufen bekommst. Also zumindest ohne jetzt mit Wrappern wie 12to11.
Andy_m4
Well-Known Member
Ja. Aber eher im Sinne einer Referenzimplementierung.
Also ich kenne mich in der Tiefe damit nicht aus. Könnte mir aber vorstellen, das insbesondere große Desktop-Umgebungen special needs haben, die eben davon nicht passend umgesetzt wurden.
Und ansonsten?
Ich kann nur Sachen beobachten und daraus meine Schlüsse ziehen.
Und ich sehe, das libweston von keinem relevanten Projekt benutzt wird außer weston.
Ich sehe aber, das das später entstandene wlroots, durchaus auch von anderen Projekten (außer SwayWM) benutzt wird. Von daher kann es ja kaum stimmen, das die Community irgendwelche Wayland-Bibliotheken rundweg ablehnt und lieber ihr eigenes Ding macht, nicht ganz stimmen.
Und ja. Es mag einzelne Projekte geben, die unbedingt ihr eigenes Ding machen wollen. Aber so in der Breite? Scheint mir die plausibel.
Vielmehr scheint es ja fast so, als würde sich libweston nicht gut für eigene Projekte adaptieren lassen.
Mag ja alles sein. Es muss ja auch nicht dabei bleiben, das er der einzige Entwickler ist. Die grundsätzliche Idee könnte ja auch andere inspirieren, da mit zu helfen oder eigene Projekte zu starten. Ich bin ja auch selber skeptisch, aber würde trotzdem erst mal abwarten und nicht schon im vorhinein irgendwelche Urteile fällen.
Ja. Ich weiß. Aber selbst da wäre ich erst mal zurückhaltend mit Vorhersagen. Klar wird der Support für X11 schlechter werden, aber das er alsbald bzw. in ein paar Jahren gar nicht mehr da ist, da würde ich nicht unbedingt drauf wetten.
Wir füttern ja auch andere Technologien durch, die "niemand" mehr braucht. Man denke nur an den ganzen 16-Bit-Kram in x86-CPUs. Den braucht auch keiner mehr. Im Gegenteil. Viele Systeme gibts nicht mal mehr als 32(!)-Bit-Variante.
-Nuke-
Well-Known Member
Na jetzt nicht meine Aussagen verdrehen. Es ging um libweston. Also das, was das "offizielle" Implementierung ist. Inwieweit libweston nun benutzbar ist oder nicht sei mal dahin gestellt. Es hat sich im Umkehrschluss, aber auch niemand gefunden, der darauf aufbauen und es verbessern will.
Es entstanden eben neue Implementierungen abseits davon. Also mutter, kwin, wlroots, aquamarin, ... Inwiefern die dann von anderen Projekten weiterverwendet werden war da gar nicht meine Aussage.
Trotzdem sollte man aber z.B. bei wlroots nicht vergessen, dass ein Großteil der Entwicklung von einer Person kommt. Der ist zwar auch Wayland-Protokoll Maintainer (Simon Ser), aber Implementierungen wie mutter und kwin haben halt wesentlich mehr Entwickler dahinter. Sprich auch wenn wlroots ein paar mehr Anwender hat, ist das am Ende nur eine Nutzung und keine Mitarbeit.
Andy_m4
Well-Known Member
Ja. Ich schrieb auch libweston.
Insofern weiß ich gerade nicht, was Du von mir willst.
Das ist doch aber der springende Punkt. Mein Einwand war ja ursprünglich, das die Wayland-Macher das Protokoll gemacht haben und ein Demo-Projekt rausgebracht haben, aber eben keine nützlichen Tools und Bibliotheken die Leuten hilft das dann auch schnell zu benutzen.
Da hilft es dann selbstredend(!) auch nicht zu sagen, das es ja 'ne Bibliothek gab. Wenn die so untauglich ist, das die keine benutzen mag, dann ists das quasi so als gäbe es die nicht.
Das ist doch gar nicht der Punkt. Der Punkt war doch, das es eben nicht nur ein Problem des "Wir wollen alles selber machen" war, sondern es an brauchbare Bibliotheken mangelte. Und der Umstand das wlroots adaptiert wurde, zeigt ja auch, das brauchbare Bibliotheken benutzt werden, wenn sie vorhanden sind.
Das wollte ich eigentlich noch ergänzen - einiges davon ist ja nur "Optional" bei den meisten distries, resolved, timesyncd, networkd z.B. kann man ja problemfrei durch anderes ersetzen bzw. wird von vielen distries auch garnicht verwendet. Ich hab hier auch nicht das Gefühl das systemd dieses ganzen sub-sachen massiv versucht zu pushen.
Ich verwende aber zB.. networkd inzwischen super gerne auf Systemd-Systemen ohne gui weil ich das als deutlich besser empfinde als der meiner meinung nach unsägliche "Network Manager" - und es ist halt gleich mit dabei.
(Ja es gibt noch andere methoden bei den Linux-Distries außer networkd, aber als nun wirklich "besser" im engeren sinne hab ich die alle nicht empfunden, und systemd-networkd scheint auch breit verfügbar zu sein was es mir erspart mehrere Syntax etc zu lernen)
Timesyncd funktioniert bei mir auch ganz