Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Posted Mar 29, 2024 8:18 UTC (Fri) by karkhaz (subscriber, #99844)In reply to: Bad estimates for the share of users of DEs on Linux by douglasbagnall
Parent article: GNOME 46 puts Flatpaks front and center
"Does anyone have figures (estimates, whatever) for the share of users of DEs on Linux?"Another source of information is the Arch linux package stats, which shows data over time for e.g. desktop environments. Same caveats as for Debian popcon apply. Plasma appears to have become more popular than GDE around 2017. I was slightly surprised to see that i3 has more installations than sway. Sway was installed on more machines until December 2022, when a large number of i3 installations were reported
Posted Apr 4, 2024 19:33 UTC (Thu)
by h2 (guest, #27965)
[Link] (17 responses)
I can tell you one thing, without any doubt: the guys who do sway, despite saving the entire ecosystem for Wayland by creating wlroots library, have no idea what made i3 great, which was: fantastic docs, website, man page. While I have not looked at sway's code, I did look at i3's, and it was fantastic, discipline of i3 project is second to none.
Sway man page to my amazement was basically empty, no content. And sway's claim that it is a drop in replacement for i3, including using i3config if detected, is simply false, it's not, it doesn't even use same syntax for various features, took me a few hours to get most of the stuff running to be similar to i3. It is similar, however, but not realistic since you have to change so much to make it work.
I moved to i3 because I was incredibly impressed by their docs, their man page, which follows the OpenBSD idea that a man page should be complete and answer all questions if you are offline. Sway is only similar to i3 in form, not content. I am going to keep using it in order to run at least one physical wayland install, useful for development and testing, since my demands are very low, but it does not at all surprise me to see that sway is below i3, that's where it deserves to be until they finish the hard work that makes i3 great.
I was heavily influenced by i3's project attitude towards documentation, and try to emulate that completeness, particularly in man pages and other tools conveying information to users about the program.
But I am profoundly grateful to the sway team for making their wayland compositor library fully open to the world, and taking the time to make it be universal, not just for their sway window manager, which is a huge amount of work. I don't think many people out there not familiar with wayland actually understand how extremely important that action is and was, since rather than having endless compositors to debug, now we have only the main ones, kwin, gnome, enlightenment, and wlroots, more or less. Still random compositor projects out there, but that's the main ones in reality now. Xfce is using wlroots in their early wayland compositor work, there's even an attempt to use wlroots as kde compositor instead of kwin.
Posted Apr 5, 2024 10:57 UTC (Fri)
by paulj (subscriber, #341)
[Link] (15 responses)
I do hope though that someone fixes up whatever the issues are that prevent Xwayland from acting completely transparently as an X11 server for existing X11 DEs. And/or that Mate gains native Wayland support. But.. failing those, Xfce on Wayland is hopefully another option.
Yay Desktop Linux and the regular complete-but-never-compatible-wheel-re-engineeering (fixing the lumps at X,Y & Z degrees; while adding new lumps at A,B,C and D degrees!).
Posted Apr 5, 2024 11:05 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (14 responses)
The only reason you can't run a rootful Xwayland as an X11 server for an existing X11 DE is that you need an underlying Wayland compositor to run Xwayland on. You can already run Xwayland :9 -decorate inside an existing Wayland session to get an X11 server that runs entirely inside a decorated Wayland window, and in which you can run an X11 DE, and you can omit -decorate and add -fullscreen if you want that Wayland window to be full-screen, undecorated.
The trouble is that when people talk about "Xwayland … acting completely transparently as an X11 server for existing X11 DEs", they generally mean "Xwayland without a Wayland compositor", and that's not possible.
Posted Apr 5, 2024 11:13 UTC (Fri)
by paulj (subscriber, #341)
[Link] (13 responses)
I still like to run WindowMaker sometimes.
Posted Apr 5, 2024 11:18 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (12 responses)
You can run WindowMaker inside a rootful Xwayland today, atop a Wayland compositor; either inside a window on GNOME, KDE, or whatever else you use as your Wayland session, or fullscreen on top of your Wayland session.
The thing that nobody is willing to put time into is using something like wlroots to run an "empty" Wayland session whose only reason to exist is to let you run fullscreen Xwayland instances for running an X11 DE under. Other than that, all the pieces exist, and it just needs someone who wants to run X11 DEs on Xwayland (rather than porting them to Wayland) to step up and write the needed code.
Or, that same person could decide that they're going to step up and start maintaining the Xfree86 code within X.org, so that you can run a direct-to-hardware X11 server instead of Xwayland atop Wayland. That's a necessary component of keeping the non-Wayland subset of Xorg in distros; someone keeping the codebase in good shape.
Posted Apr 5, 2024 11:43 UTC (Fri)
by paulj (subscriber, #341)
[Link] (11 responses)
That seems like it would allow the Xorg server graphics stuff - which apparently the devs hate - to be superceded by Wayland graphics (which more or less the same Xorg devs created, right?) /today/. And provide a seamless transition to Wayland, today.
It's strange it isn't done, but instead developers are trying to push users down a much less seamless transition path.
Posted Apr 5, 2024 12:03 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (8 responses)
The problem with the hardware Xserver stuff is that nobody wants to maintain it, it's got all sorts of dark corners (some of it is pre-ANSI C, still), and everybody who cares about code quality has already moved onto DEs that have working Wayland compositors, or is using something like Weston and running an existing X11 DE underneath Xwayland, non-transparently.
Fundamentally, this is the problem - the hardware code isn't "hated", it's just that nobody is maintaining it, and if it stops compiling, has serious bugs (security relevant or not), or is otherwise not usable in future, nobody is offering to fix it. And that has the distros nervous, because they don't want to be shipping potentially unfixable code.
Posted Apr 5, 2024 12:47 UTC (Fri)
by paulj (subscriber, #341)
[Link] (7 responses)
The graphics hardware stuff in Xorg Xserver I gather is not liked. And that would be the /easiest/ to obsolete, simply by having XWayland be able give a full X11 root window of the entire screen. Then you could transparently run your X11 DEs in XWayland with Wayland driving the hardware. Right?
And that code in Xorg can die.
It's just strange the people who want that code to die aren't offering this obvious, seamless transition path.
Posted Apr 5, 2024 13:13 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (6 responses)
They are offering a seamless transition path to the users they care about - GNOME and KDE. All the other DEs are refusing to work on this, and saying that they expect Someone Else to fix the problem for them.
And that's the fundamental issue; the hardware support code in Xorg was only maintained because Oracle Solaris and Red Hat Enterprise Linux maintained it as part of their respective GNOME stacks. They have seamless transition paths for their users from GNOME/X11 to GNOME/Wayland, and have stopped maintaining it; this is exposing that no-one from the other DEs is maintaining the Xfree86 code base inside Xorg, but are assuming that Someone Else will maintain that code path for them.
At some point, this entitlement to free support of your dependencies comes to an end - and at that point, you either need to implement a transition path yourself, or step up to the plate and support the things you depend upon.
Posted Apr 5, 2024 15:04 UTC (Fri)
by paulj (subscriber, #341)
[Link] (5 responses)
And even if they are, surely - if they really want to hurry the demise of the Xorg DDX code - they'd be happier to have the other X11 DEs run on top of Wayland via XWayland, than continue with that DDX code? Make it make sense... :)
And yeah, I'm being entitled here I guess. Least, I'm hoping to freeload for a bit longer.
Posted Apr 5, 2024 15:10 UTC (Fri)
by paulj (subscriber, #341)
[Link]
Posted Apr 5, 2024 15:22 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (3 responses)
The devs working on the graphics code in DDXes now just work in Mesa - they've dropped the DDXes a while ago. This is why Glamor exists, to provide a DDX that's backed only by an OpenGL driver (and which is used by Xwayland, too, so is maintained by Red Hat and Oracle people for people running X11 apps on GNOME). The remaining chunks of Xfree86 code were being worked on by people who were paid to do it so that GNOME continued to work; they've moved onto other things now that their employers don't care about GNOME/X11.
And because all the people who care have moved onto other things, nobody cares about the demise of the Xorg DDX code, bar some distros who are scared that Xserver will have a security flaw that needs fixing, and nobody willing to roll up their sleeves and fix the code. Previously, Oracle and Red Hat provided that by paying people to work on this so that GNOME/X11 worked. Now that GNOME doesn't need an X11 server, those people aren't being paid to work on the Xserver code base, and they've moved onto something else because that code is so horrible that people won't work on it unless paid.
Some people who are trying to get Someone Else to carry the maintenance burden of Xorg DDX code portray this as "they want to hurry the demise of the Xorg DDX code", but it's simpler than that - nobody cares enough to become the Someone Else who works on that code for the benefit of X11 DEs. It used to be the case that Red Hat and Oracle cared if there was an exploitable flaw in Xorg DDX code, since that would result in their paid product containing an exploitable flaw in GNOME; now, they don't, and Someone has to step up to the plate for WindowMaker, XFCE, Cinnamon, Trinity and any other DE that depends on X11, or accept that sooner or later, there will be an exploitable flaw in the X server where distros will fix it by removing the X server completely.
Posted Apr 8, 2024 9:52 UTC (Mon)
by paulj (subscriber, #341)
[Link] (2 responses)
But people _are_ working on Wayland, and the graphics libraries that underpin it, right? And someone is working on XWayland, right? So... could someone not add a mode to XWayland to let it present a full screen, undecorated, unmanaged-by-any-wayland-compositor window to X11?
Cause, wouldn't that allow all that unmaintained, unloved, old XFree86^WXorg DDX code to be set aside, and allow seamless transition of the user-facing X11 components (WM, clients) to then run on top of that /maintained/ graphics stack?
Posted Apr 8, 2024 9:55 UTC (Mon)
by paulj (subscriber, #341)
[Link]
Early on in Wayland, it was my understanding that XWayland would basically be the transition strategy - starting as a seamless, full-root-window server. But that, strangely, never happened.
Posted Apr 8, 2024 10:16 UTC (Mon)
by farnz (subscriber, #17727)
[Link]
Xwayland, by design, takes in X11 protocol from its clients, and uses Wayland protocol to render the X11 requests in Wayland window(s) managed by Wayland compositors. It has no ability to present anything on the display itself; it relies crucially on a Wayland compositor doing all the hardware interaction for it.
In this respect, it's the same as Xephyr, XDarwin, X11.app and Xming - it acts as an X11 server for its clients, but implements it by talking to a different window system on the other side, and not to hardware.
It's an essential part of the transition process, since it means that when you move to a Wayland DE, you don't need to throw away all your X11 clients - you can use Xwayland to run them within your Wayland DE, and can use Xwayland in either rootful or rootless mode to run those clients in a way that suits you.
The bit that's missing is an interface between Wayland protocol and what hardware supplies; we call that a "Wayland compositor", and its job is to listen to Wayland clients (including Xwayland), and output commands to the hardware (e.g. via Linux kernel DRM drivers). That's what needs implementing, and that needs to exist outside Xwayland.
The alternative route, which you seem to be describing, is to create a brand new hardware-aware X server, dropping the xfree86 DDX code, using modern mechanism like Wayland does for rendering, and that has its own hardware access code similar to a Wayland compositor. But, unlike a simple full-screen Wayland compositor (which remains useful without Xwayland for things like games consoles), this is very much tied to keeping X11 servers working.
Indeed, if you really want to keep X11 DEs going, you should be able to run gamescope as your Wayland compositor (ignoring its gaming features), and use Xwayland as the X11 implementation.
Posted Apr 23, 2024 7:14 UTC (Tue)
by daenzer (subscriber, #7050)
[Link] (1 responses)
FWIW, Xwayland should already have all the functionality needed to get something like that off the ground. What's left is mostly integration work outside of it, creating a session with a minimal Wayland compositor and non-rootless Xwayland running fullscreen.
Posted Apr 30, 2024 8:15 UTC (Tue)
by jafd (subscriber, #129642)
[Link]
Posted Apr 14, 2024 23:17 UTC (Sun)
by ceplm (subscriber, #41334)
[Link]
1. If you have an empty sway(1) man page, then the problem is with your distribution, not with the sway project. We (OpenSUSE/Linux) have pretty neat man pages (see https://manpages.opensuse.org/Tumbleweed/sway/sway.1.en.html). And there is also https://github.com/swaywm/sway/wiki which is not empty either.
2. If you have problems with sway’s incompatibility with i3 syntax, then it is a bug, and it should be filed in https://github.com/swaywm/sway/issues. It should work.
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux
Bad estimates for the share of users of DEs on Linux