Supportende für X11?

Für mich als WM-User ist Cosmic ein Segen!

Was ist Cosmic überhaupt? Es unterstützt ja beides. Für die Desktop-Messies interessant, selbst Icons kann man darauf ablegen. Desktop mit Tiling-Option...

Cosmic wirkt auf mich wahnsinnig durchdacht, funktional und wunderbar zurückhaltend. Ich bin von den Optionen die mir ein Plasma liefert einfach Überfordert 😆.

Hyprland und Sway wären noch interessant. Aber gut, fürs erste reichts...
 
  • Gefällt mir
Reaktionen: RedPanda05
Als ich damals mein EOS (mit KDE Plasma) installiert und damit ein weiteres Linux-Kapitel in meinem Leben begonnen hatte, hatte ich von Beginn an auch X.Org genutzt, weil ich auch gelesen und gehört hatte, dass Wayland noch viele Baustellen haben soll. Lief auch sehr ordentlich, bis ich dann irgendwann festgestellt hatte, dass der Thunderbird-Prozess immer dann gestorben ist, als ich ein Fullscreen Game beendet habe. Da war vollkommen egal welches Game; wenn es im Fenstermodus war, passierte das nicht. Wo das auch nicht passierte, war unter Wayland. So bin ich dann irgendwann im Frühjahr dieses Jahres von X.Org auf Wayland geswitched. Überraschend lief auch alles von mir unter Wayland (mal abgesehen von gewissen Konfigurationsdateien) von KDE und ich musste bspw. meine Taskleiste neu machen.

Wann es war, kann ich gar nicht mehr rausfinden; mir fehlt in meinen Chats das entsprechende Datum. Ich weiß ich nicht mehr, ob es noch auf meiner alten Mühle war oder schon auf meinem neugebauten PC. Auf jeden Fall hatte ich dann später mal die X.Org-Pakete wieder installiert, die ja bei KWin inzwischen gesplittet wurden und kwin auf Wayland verweist, während kwin_x11 für X.Org ist sowie plasma-x11-session. Dann hatte ich mich mal von meinem Profil abgemeldet und mit X.Org wieder angemeldet.

Interessanterweise wurde das Profil mit dem Laden gar nicht wirklich fertig. Es wurde nur das Wallpaper angezeigt sowie der per Strg+Alt+Entf erreichbare Session-Bildschirm sowie Win+Tab. Aber darüber hinaus wurde nichts weiters angezeigt; kein Maus Cursor, keine Taskleiste, kein Startmenü, keine Desktop Icons, kein Kontextmenü, Nichts.
Das gleiche passiert auch bei einem nagelneuen Benutzerprofil, mit dem noch gar nichts gemacht wurde. Zur Sicherheit auch mal PC neu gestartet, sicher ist sicher, aber auch dann war das Problem vorhanden.
Zurück bei Wayland war alles so wie immer.

Ich habe daraus geschlussfolgert, dass die Zeit für X.Org allmählich aber sicher gekommen ist. Da Wayland und Xwayland aber bei mir ohne Probleme funktionieren und tun, was sie sollen und die Anwendungen dies auch tun, bin ich mit Wayland zufrieden und habe bisher auch keinen Grund, dem auf den Grund zu gehen, warum X.Org-Sessions bei mir nicht mehr funktionieren.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Piktogramm
Hyourinmaru schrieb:
Interessanterweise wurde das Profil mit dem Laden gar nicht wirklich fertig. Es wurde nur das Wallpaper angezeigt sowie der per Strg+Alt+Entf erreichbare Session-Bildschirm sowie Win+Tab. Aber darüber hinaus wurde nichts weiters angezeigt; kein Maus Cursor, keine Taskleiste, kein Startmenü, keine Desktop Icons, kein Kontextmenü, Nichts.
Das war ein Problem von deiner Distro bzw. deiner Installation, nicht von Xorg an sich.
 
Ich bleibe bei X11, solange ich noch keine neue Hardware habe, und auch beim alten Synaptics Treiber. Mein SynPS/2 Touchpad ist alte Technik. Keine echten Pressure-Werte, nur Koordinaten und Finger an/aus. Da bietet Wayland/libinput einfach viel zu wenig. Hänger, kleine Gedenksekunden, der Cursor bleibt bei schnellen Bewegungen kurz stehen oder bremst einfach weg. Unter X11 läuft das Touchpad dagegen rund. Kann den ganzen Touchpad Bereich verwenden, passt. Was Wayland außerdem fehlt, ist echte Konfiguration. Bei Xorg kann ich mein Touchpad so konfigurieren wie ich es will. Z.B. ganz klassisch mit Softbuttons:

Code:
Option "SoftButtonAreas" "66% 0 80% 0 33% 66% 80% 0"

Deshalb bleibe ich noch dabei. Die neuen HID/I2C Touchpads machen dagegen mit Wayland/libinput keine Probleme.
 
Da gibts gar keine Konfigurationsmöglichkeiten? ich meine bei Soundkarten und co gibts ja auch, wenn für eine Gerätegruppe der selbe Treiber da ist Variantionsspezifische Anpassungen. Natürlich erst immer wenn die Geräte bekannt/die Eigenheiten/Probleme auftauchen und gemeldet werden.

Das müsste do ch an sich solch ein Fall sein oder?
 
Doch gibt es. libinput-Quirks, Device Profiling usw..
Diese setzen aber voraus, dass das Touchpad ausreichende Sensordaten liefert.
Aber bei alten PS/2 Synaptics Touchpads fehlen diese Infos.
 
Ist ja auch alles kein Problem, da Xorg noch eine Weile erhalten bleiben wird.
Allerdings darf man halt nicht erwarten, das sich an Xorg noch viel tut (und auch Xlibre wird daran vermutlich nicht viel ändern; wie auch? Xorg wurde ja aufgegeben, weil es unerneuerbar ist).
Neue Features werden es also eher nicht nach Xorg schaffen. Gleichzeitig wird die Abhängigkeit von Wayland steigen, da irgendwelche Xorg-Backends nicht mehr die Zuwendung kriegen werden wie bisher (wenn sie nicht gar ganz gedroppt werden).

Ist aber gar nicht so problematisch, da irgendwelche legacy die noch an Xorg hängt, wird ja auch eher weniger werden.
Und X11-Programme selbst werden ja dank xwayland auch weiterhin laufen (von ein paar Schrott-Apps mal abgesehen).

Insofern besteht gar kein Grund zur Sorge.
Und in ein paar Jahren wird da kein Mensch mehr drüber reden. Nichts wird am Ende so heiß gegessen, wie es die ganze Zeit in Mailinglisten und Foren hochgekocht wurde.
War doch bei systemd ähnlich. Da gabs auch große Diskussionen. Und inzwischen gehört das einfach mit dazu und interessiert niemanden mehr. :-)
 
andy_m4 schrieb:
War doch bei systemd ähnlich. Da gabs auch große Diskussionen. Und inzwischen gehört das einfach mit dazu und interessiert niemanden mehr. :-)
systemd gehört bei den Distros die es verwenden "einfach dazu", gleichzeitig gibt es aber eine wachsende Anzahl von Distros die es nicht verwenden und die funktionieren genauso gut wenn nicht sogar besser wie die Distros die es verwenden.
Devuan (mit SysV init) bootet laut meiner Erfahrung z.B. schneller als die Debian Version von der es abstammt.

Genauso wird es mit wayland <> xorg auch kommen, es wird Distros geben die nur Wayland anbieten, andere die beides anbieten und wieder andere die nur xorg/xlibre anbieten.

Also der Albtraum all derjenigen die sich ein einheitliches Linux wünschen weil sie mit der Auswahl überfordert sind. :D
 
SirSinclair schrieb:
gleichzeitig gibt es aber eine wachsende Anzahl von Distros die es nicht verwenden
Das das wirklich eine wachsende Anzahl?
Oder ist es nur ein Nebeneffekt dessen, das die Gesamtanzahl der Distributionen zunimmt und da auch Nicht-Systemd-Distributionen geforkt werden, wächst zwar die Absolutzahl aber im Verhältnis tut sich da eher nichts?

SirSinclair schrieb:
Devuan (mit SysV init) ... bootet schneller ....
Kann sein. Aber systemd wurde ja auch nicht damit begründet, das es schneller bootet.

SirSinclair schrieb:
es wird Distros geben die nur Wayland anbieten, andere die beides anbieten und wieder andere die nur xorg/xlibre anbieten
Wahrscheinlich. Wobei die Lage bei Xorg/Wayland etwas anders ist.
Denn letztlich steht und fällt viel damit, was Upstream supportet wird.

Die Kopplung ist bei systemd loser. Also so einem Daemon ist es letztlich egal, von wem er gestartet wird.
Bei X11 und Wayland sind die Abhängigkeiten da etwas stärker.

Es reicht dann ja nicht allein Xorg ein bisschen zu pflegen.
Wenn beispielsweise GNOME/Gtk, KDEPlasma/Qt, Firefox, whatever die X11-Unterstützung droppt, dann müsstest Du auch das mitziehen. Der Aufwand ist sehr viel höher, als ein paar Init-Skripte zu schreiben.
 
andy_m4 schrieb:
Das das wirklich eine wachsende Anzahl?
Oder ist es nur ein Nebeneffekt dessen, das die Gesamtanzahl der Distributionen zunimmt und da auch Nicht-Systemd-Distributionen geforkt werden, wächst zwar die Absolutzahl aber im Verhältnis tut sich da eher nichts?
Ich meine die absolute Anzahl.

andy_m4 schrieb:
Kann sein. Aber systemd wurde ja auch nicht damit begründet, das es schneller bootet.

Doch das war ganz am Anfang eines der primären Argumente mit dem die Entwicklung von systemd gerechtfertigt wurde.

andy_m4 schrieb:
Wenn beispielsweise GNOME/Gtk, KDEPlasma/Qt, Firefox, whatever die X11-Unterstützung droppt, dann müsstest Du auch das mitziehen. Der Aufwand ist sehr viel höher, als ein paar Init-Skripte zu schreiben.
Gnome interessiert wohl die wenigsten die X11 bevorzugen, aber KDE wurde schon mal geforkt (TDE) und der Fork wird seit über 15 Jahren weitergepflegt, insofern ist es gut möglich das das auch bei Plasma passiert wenn sich jemand für einen X11 Fork interessiert.

Bei GTK und QT gehe ich davon aus das die geforkt werden falls sie wayland only werden, die sind viel zu wichtig insofern wird es da mit Sicherheit Leute geben die die X11 Varianten weiter pflegen.

All dieses Forking ist in der Linux Welt nichts ungewöhnliches, es ist schon X Mal passiert, siehe KDE3->TDE, Gnome2->Mate, Openoffice->Libreoffice, Mysql->MariaDB, usw...
 
Zuletzt bearbeitet:
Ja, ganz genau, und da braucht man sich auch nicht um Zahlen zu streiten, solange genug Menschen bedarf haben wird es weiter leben. Und so soll das auch sein.
 
  • Gefällt mir
Reaktionen: Freedstorm und SirSinclair
SirSinclair schrieb:
Doch das war ganz am Anfang eines der primären Argumente mit dem die Entwicklung von systemd gerechtfertigt wurde.
Die Grundidee bei systemd ist, das Init-System dynamischer zu gestalten. In dem man auf Ereignisse (Events) reagiert und Abhängigkeitsverhältnisse integraler Bestandteil sind.
Bei Sys-IV-Init wird dagegen einfach nur sequentiell Skripte abgearbeitet. Daraus kann natürlich ein Geschwindigkeitsvorteil resultieren, da Dinge die nicht voneinander abhängen parallel gestartet werden können. Der muss sich aber nicht zwangsläufig ergeben. Das ist also wenn überhaupt, dann nur ein Nebeneffekt.

SirSinclair schrieb:
Gnome interessiert wohl die wenigsten die X11 bevorzugen
Das Argument war an der Stelle nicht GNOME, sondern das Du in zunehmenden Maße mit Software konfrontiert sein wirst, die nur unter Wayland (optimal) läuft.

Und klar kannst Du das versuchen mit forken usw. aufzufangen: Das Ding ist, Du wirst realistischerweise nicht alles forken können. Vor allem weil Du ja dann auch immer dem hinterherhecheln musst, was der jeweilige Upstream vorgibt. Und irgendwann werden das auch Funktionalitäten sein, die sich mit X11/Xorg nur schwer implementieren lassen.

Das heißt: Du musst eh schon damit rechnen, das Du nicht die Ressourcen hast, die in die ganze Upstream-Entwicklung fließen, Du hast dann sogar noch u.U. Mehraufwand um Features zu bauen.

SirSinclair schrieb:
aber KD3 wurde schon mal geforkt
Ja. Es gibt immer mal Projekte, die geforkt und weiter geführt werden oder was auch immer. Du kriegst auch jetzt immer noch GUIs für DOS und auch DOS selbst wird in Form von FreeDOS weitergeführt.

Sowas gibts alles. Aber meine Behauptung war ja auch nie, das das völlig verschwinden wird. Im Gegenteil. Ich hab ja sogar bezüglich Xorg explizit eingeräumt, das es das noch eine ganze Weile geben wird.

Die Frage ist doch eher, welche Größe und Bedeutung wird das haben. Und meine Einschätzung ist, das das eher klein sein wird. Heute dürfte schätzungsweise die Verteilung zwischen Xorg und Wayland bei 50% liegen. Ich denk mal, in 5 Jahren ist das spürbar in Richtung Wayland gerutscht.

Was auch vollkommen logisch ist. Weil sowohl von den Programmen her geht der Trend dahin Wayland besser zu supporten als Xorg als auch von der Hardwareseite (Treiber) her.

Und auch bei Xorg selbst muss man schauen, wie es wird. Auch beim Grafiksystem gehen die Entwicklungen weiter. Xorg ist ja da ein gutes Beispiel für. Wie oft wurden da Dinge schon dran geändert usw.
Die Frage ist, inwieweit das bei der Codebasis noch machbar ist. Vor allem unter der Maßgabe, die Kompatibilität nicht zu brechen.

Und da hatten die Xorg-Entwickler selbst(!) ja schon gesagt, das das halt nur noch mit Schmerzen geht.
Nicht umsonst ist ja Xorg seit Jahren im reinen Maintance-Mode. Und wer es besser weiß, der hätte sich dem ja annehmen können. Das geschah aber bisher nicht. Und das aus gutem Grund.

Ob Xlibre daran grundsätzlich was ändert, würde ich erst mal bezweifeln.
Wenns dann irgendwann vielleicht mal in den Repositorys der bekannten Distributionen auftaucht, die X11 noch weiter supporten, dann können wir da vielleicht mal drüber reden.
 
andy_m4 schrieb:
Kann sein. Aber systemd wurde ja auch nicht damit begründet, das es schneller bootet.
Aus dem Gedächtnis. Bei Systemd war es seitdem ich davon mitbekommen habe durchaus Ziel Bootzeiten zu verkürzen. Das erklärte Ziel war, dass Systemd Abhänigkeitsgraphen von allein baut und Pfade die nebenläufig laufen können entsprechend parallel abfackelt. Das klappt anfangs weniger gut, ist aber seit ein paar Jahren[1] stand der Ding.

Tendenziell ist Systemd seit Jahren aber auch schneller als SysV init bei vergleichbarer Umgebung. Die Differenzen sind aber eher klein. [2] Hat da div. Tests mit Yocto Linux auf einem ARMv7 mit entsprechend langen Bootzeiten. Da sind im Schnitt 9,5% bessere Ladezeiten für SystemD herausgekommen. Bei sowieso langen Bootzeiten, weil das System lahm ist.
Auf einem N305 basiertem Notebook schaut es dann eher so aus:
boot.png

Wer da +/-10% als Grundlage nimmt um übers Initsystem zu entscheiden statt anderer Fakoren (Stabilität, Verfügbarkeit von kompetentem Personal/Support, ..), dessen Entscheidungsfindung würde ich in Frage stellen.


[1] Lies: Ich bekomme es zeitlich nicht eingeordnet, es ist also irgendwann vor 3..15Jahren passiert.
[2] https://reliableembeddedsystems.com/blog/bootchart-to-analyze-systemd-and-sysv-boot-time/
 
  • Gefällt mir
Reaktionen: andy_m4
andy_m4 schrieb:
Die Frage ist doch eher, welche Größe und Bedeutung wird das haben.
Das ist dem einzelnen Nutzer doch völlig egal, wer KDE3 liebte und behalten wollte ist vor über 15 Jahren auf den TDE Fork umgestiegen und benutzt auch heute noch ein weitergepflegtes KDE3 (als TDE), ob das nur 1000 oder 10.000.000 andere Menschen auch tun ist völlig egal, denn bei solchen Projekten geht es ja nicht um Profit, die Entwickler selber machen das ja auch nur weil sie es selber nutzen und Spaß dran haben.

In anderen Worten das sind echte Community Projekte, im Gegensatz zu den FOSS Projekten der Konzerne wo immer nach Kosten/Nutzen geschaut wird und wo die Interessen der privaten Nutzer eher nachrangig sind (falls sie überhaupt beachtet werden).

"Größe und Bedeutung" sind bei echten Community Projekten ziemlich irrelevant, sonst gäbe es längst kein TDE, Slackware, PCLinuxOS usw. mehr.
 
Zuletzt bearbeitet:
andy_m4 schrieb:
Die Frage ist, inwieweit das bei der Codebasis noch machbar ist. Vor allem unter der Maßgabe, die Kompatibilität nicht zu brechen.
Bei Xorg ist es nicht nur der Code, beim X11-Protokoll ist schon die Weiterentwicklung kaum möglich. Also kann man optionale Extensions außerhalb des eigentlichen Protokolls implementieren in der Hoffnung, dass dagegen irgendwer implementiert (Xlibre Xspace extenion wäre ein Beispiel dafür). Oder man entwickelt das Protokoll weiter, welches immernoch bei freedesktop liegt. Spätestens für HDR wird das ja nötig, da X11 nur 32bit für Farben vorsiehr (rgba mit je 8bit). Da kann man dann 3x10bit mit 2bit alpha draus machen (wurde bei Xlibre diskutiert, HDR mit 2bit Alpha 😅 ) oder aber muss 40bit bzw. dynamische Farbformate vorsehen. Beides ist halt kein X11.

SirSinclair schrieb:
"Größe und Bedeutung" sind bei echten Community Projekten ziemlich irrelevant.
Erfahrung aus dem Ehrenamt: Die Ressource "Jemand macht es zuverlässig, kompetent" ist extrem rar und schwer beizukommen als Geld. Entsprechend ist die Frage "Was bewirkt die Arbeit" essentiell und endet meist zwangsweise darin, dass man alte Zöpfe abschneiden muss.
Alternativ hat man Personen mit viel Zeit, die eine Form von "Wer macht hat recht" ausleben und das Meritokratie nennen. Was aber eigentlich nur ein Diktat von "ICH habe das halt so gemacht".
Viele der Forks sind leider so und XLibre ist ja auch so entstanden.
 
  • Gefällt mir
Reaktionen: andy_m4
Piktogramm schrieb:
"Jemand macht es zuverlässig, kompetent" ist extrem rar und schwer beizukommen als Geld.
Tja, die Realität in der FOSS Welt ist aber eine andere, sonst gäbe es nicht weiterhin unzählige Forks und reine Community Projekte die schon seit vielen Jahren aktiv sind und zuverlässig kompetente Software herausgeben.

Bei den Konzern FOSS Projekten sieht das eher schlecht aus, da werden Projekte abrupt aufgegeben nur weil irgend ein Manager Geld sparen möchte oder was anderes für die Profite des Konzerns wichtiger ist.

Ich benutze Linux seit 30 Jahren und bin bisher fast immer nur von Konzern FOSS Projekten enttäuscht worden weil die plotzlich eingestellt wurden oder radikal negativ verändert wurden (IBM/Redhat sticht da besonders hervor), bei reinen Community Projekten nicht wirklich.
 
Piktogramm schrieb:
Das erklärte Ziel war, dass Systemd Abhänigkeitsgraphen von allein baut und Pfade die nebenläufig laufen können entsprechend parallel abfackelt.
Das mit dem parallel abarbeiten hab ich schon genannt.

Anyway: Wenn es mir um schnelle "Bootzeit" geht, dann bin ich doch mit nem aufwachen aus einem Suspend/Standby immer schneller. Dafür lohnt doch gar nicht ein komplexes Init-System zu entwickeln.

btw bietet ja Sys-IV-Init genug Ansatzpunkte zur Optimierung. Allein schon bei der Shell für die Skripte, wo man dann irgendwann angefangen hat statt der schweren Bash etwas leichtgewichtigeres einzusetzen usw.

Piktogramm schrieb:
Wer da +/-10% als Grundlage nimmt um übers Initsystem zu entscheiden statt anderer Fakoren (Stabilität, Verfügbarkeit von kompetentem Personal/Support, ..), dessen Entscheidungsfindung würde ich in Frage stellen.
Eben.

SirSinclair schrieb:
Das ist dem einzelnen Nutzer doch völlig egal,
Natürlich ist das dem einzelnen Nutzer egal. Hab ich doch auch so durchklingen lassen.

SirSinclair schrieb:
denn bei solchen Projekten geht es ja nicht um Profit, die Entwickler selber machen das ja auch nur weil sie es selber nutzen und Spaß dran haben.
Dagegen hab ich doch auch nie was gesagt. Du sagst häufig irgendwelche Sachen und tust so, als wäre ich dagegen. Dabei hab ich das in keinster Weise so gesagt.

Bleib doch mal bei dem, was ich sage anstatt Dich an Strohmännern abzuarbeiten.

SirSinclair schrieb:
im Gegensatz zu den FOSS Projekten der Konzerne wo immer nach Kosten/Nutzen geschaut wird und wo die Interessen der privaten Nutzer eher nachrangig sind
Klar verfolgen Konzerne ihre eigenen Interessen. Auch hier hab ich nie was gegenteiliges anklingen lassen.

SirSinclair schrieb:
Größe und Bedeutung" sind bei echten Community Projekten ziemlich irrelevant,
Das war ja auch gar nicht der Punkt. Abseits davon gibts natürlich Größe und Bedeutungen. Siehst Du auch schön nebenan im Desktop Environment Umfragethread.

Piktogramm schrieb:
Bei Xorg ist es nicht nur der Code, beim X11-Protokoll ist schon die Weiterentwicklung kaum möglich.
Ja. Mich meinte beides.

SirSinclair schrieb:
reine Community Projekte die schon seit vielen Jahren aktiv sind und zuverlässig kompetente Software herausgeben.
Ja. Das ist so. Trotzdem sollte man auch mal anerkennen, das ohne Kommerz die ganze Linux-Landschaft nicht dort wäre, wo sie heute ist.
Ja ja, die machen das nicht aus altruistischen Motiven, sondern da stehen knallharte Geschäftsinteressen hinter. Und ja, beileibe nicht alles davon läuft in eine Richtung die Gefallen kann.
Nichtsdesotrotz muss man auch anerkennen, das auch ein gewisser Nutzen für die Linux-Gemeinschaft dahinter steht.
Auch Du wirst Programme benutzen, wo Konzerne mitgearbeitet haben. Auch Du wirst nicht alles aus dem Linux-Kernel rauspatchen, was von Redhat, Microsoft und Co kam. Und das nicht, weil Dir das zu anstrengend ist, sondern weil auch einige Dinge ganz nützlich und brauchbar sind.

SirSinclair schrieb:
bei reinen Community Projekten nicht wirklich.
Selbst reine Community-Projekte nehmen dankbar an, was aus der Industrie kommt.
 
andy_m4 schrieb:
Anyway: Wenn es mir um schnelle "Bootzeit" geht, dann bin ich doch mit nem aufwachen aus einem Suspend/Standby immer schneller. Dafür lohnt doch gar nicht ein komplexes Init-System zu entwickeln.
Jain. Bei Einzelsystemen bei denen das Initsystem allenfalls wenige Sekunden Differenz beim Booten bedingt, ist es halbwegs egal. Bei Clustern, Hosts für VMs, bedingt embedded[1] und anderweitig komplexeren Gebilden sind ein paar Sekunden schnelleres Booten dann eben doch die Nachkommastellen bei der Verfügbarkeit, Kosten für Laufzeit, oder schlicht weniger Nervfaktor beim Kunden.
Aufwachen ist da auch nicht immer eine Option. Selbst mit Kernelhotpatches, gelegentlich muss man doch mal neu starten.

[1]Denk an Kfz, an sich will man da den Schlüssel umdrehen bzw. Startknopf drücken und der Boardcomputer hat bereit zu stehen, selbst wenn da die Batteriesteuerung Last abgeworfen hat um die Entladung zu begrenzen. Oder schlicht der Umstand, dass die Branche ohne Memoryleaks keine Software bauen kann :/
 
Zurück
Oben