LWN: Comments on "GNOME 46 puts Flatpaks front and center"

Bad estimates for the share of users of DEs on Linux

jafd — Tue, 30 Apr 2024 08:15:05 +0000

Cage + rootful XWayland?

Bad estimates for the share of users of DEs on Linux

daenzer — Tue, 23 Apr 2024 07:14:30 +0000

You seem to find it strange that nobody else has done what you think should be done.

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.

Bad estimates for the share of users of DEs on Linux

ceplm — Sun, 14 Apr 2024 23:17:36 +0000

Few comments:

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

farnz — Mon, 08 Apr 2024 10:16:32 +0000

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.

Bad estimates for the share of users of DEs on Linux

paulj — Mon, 08 Apr 2024 09:55:11 +0000

I.e., I understand your point, but I disagree the user-facing side of X11 can be removed any time soon. However, the graphics hardware side /could/ be, if someone just makes XWayland a little more capable.

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.

Bad estimates for the share of users of DEs on Linux

paulj — Mon, 08 Apr 2024 09:52:38 +0000

Sure, I already understood that.

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?

Bad estimates for the share of users of DEs on Linux

farnz — Fri, 05 Apr 2024 15:22:51 +0000

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.

Bad estimates for the share of users of DEs on Linux

paulj — Fri, 05 Apr 2024 15:10:41 +0000

Though, if there's someone out there who knows the XWayland code and thinks they could implement what I was talking about reasonably quickly, I will do so at reasonable engineering consultancy rates (e.g., order days of coding and testing). Ping me if that's you ;)

Bad estimates for the share of users of DEs on Linux

paulj — Fri, 05 Apr 2024 15:04:36 +0000

The developers who were working on the graphics code - in Xorg DDX before and Wayland now - are surely not the GNOME/KDE devs?

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.

Bad estimates for the share of users of DEs on Linux

farnz — Fri, 05 Apr 2024 13:13:15 +0000

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.

Bad estimates for the share of users of DEs on Linux

paulj — Fri, 05 Apr 2024 12:47:45 +0000

Ack. That's exactly what I was speaking to.

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.

Bad estimates for the share of users of DEs on Linux

farnz — Fri, 05 Apr 2024 12:03:45 +0000

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.

Bad estimates for the share of users of DEs on Linux

paulj — Fri, 05 Apr 2024 11:43:01 +0000

Yes, I've done the former. Obviously though, I mean the latter. Having XWayland basically run like Xorg, offering the whole screen for the X11 environment. Transparently, so the user can't even tell.

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.

Bad estimates for the share of users of DEs on Linux

farnz — Fri, 05 Apr 2024 11:18:58 +0000

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.

Bad estimates for the share of users of DEs on Linux

paulj — Fri, 05 Apr 2024 11:13:26 +0000

Seems to me that should be fixed, before any distro should consider deprecating Xorg.

I still like to run WindowMaker sometimes.

Bad estimates for the share of users of DEs on Linux

farnz — Fri, 05 Apr 2024 11:05:12 +0000

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.

Bad estimates for the share of users of DEs on Linux

paulj — Fri, 05 Apr 2024 10:57:33 +0000

Thanks for pointing out that Xfce are working on Wayland support.

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!).

Bad estimates for the share of users of DEs on Linux

h2 — Thu, 04 Apr 2024 19:33:43 +0000

I'm not surprised at all. I run i3 on my laptops and figured I'd try sway on one of them last month.

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.

GNOME 46 puts Flatpaks front and center

Cyberax — Thu, 04 Apr 2024 16:42:26 +0000

> Most actual users are not annoyed, or they would be using something else.

Well, yes. I switched from GNOME to xfce and then to macOS. I know a couple of hardcore Linux people who went down the same route.

GNOME in later releases walked back most of the initial stupidity, and that also helped.

GNOME 46 puts Flatpaks front and center

DOT — Thu, 04 Apr 2024 12:40:15 +0000

Most actual users are not annoyed, or they would be using something else. Gnome 2 users who didn't like v3 have been annoyed for 12 years and don't seem to be happy enough with their new Mate/Cinnamon clone. It's not like anyone is forcing you to use Gnome; that's the whole point of free desktops.

GNOME 46 puts Flatpaks front and center

davidgerard — Thu, 04 Apr 2024 11:28:37 +0000

It'd be nice if Ubuntu didn't do that by default, then (with many interesting breakages following, such as those months when neither Firefox nor Chromium could see system fonts).

GNOME 46 puts Flatpaks front and center

james — Tue, 02 Apr 2024 12:23:14 +0000

The only thing I find unfortunate about using Gnome with a mouse is using the dash (the pinned programs in the Activities overview): you have to go right to the top left of the screen for the Activities button, then down to the very bottom¹ for the dash. And I often use monitors in portrait mode.

With a laptop trackpad, you're more likely to use the super / Windows key to bring up the overview (it's right next to where your hands are).

Other than that, I too have been using Gnome since version 2 and am very content with it.

¹ In recent releases.

GNOME 46 puts Flatpaks front and center

Cyberax — Sat, 30 Mar 2024 18:49:04 +0000

> So GNOME should increase the desktop market share by… doing what the existing, hard core user base of Linux wants

You know, actually yes. Not annoying your _existing_ users is a good first step. When your adoption is driven by word-of-mouth and social networks and not through ads and marketing, alienating your core users will not help you at all.

The other stupid blunder was the belief that people will switch to GNOME because it's so much more different than everything else. Dynamic "Activities" were completely unlike any other environment (Windows or MacOS). Needless to say, it hadn't happened.

GNOME 46 puts Flatpaks front and center

ejona86 — Sat, 30 Mar 2024 18:25:40 +0000

Why do anything special? Instead of ~/.var/app/foo.App/{cache,config,local/share,local/state} flip it to ~/{.cache,.config,.local/share,.local/state}/flatpak/foo.App/ like normal. Downfalls brainstorm: more mounts into the container, Flatpak would create the directories even if unused, Flatpak would need to observe the XDG_ environment variables, uglier documentation[1]. Is there a real impediment to the normal approach?

1. First bullet of https://docs.flatpak.org/en/latest/sandbox-permissions.html

GNOME 46 puts Flatpaks front and center

ebassi — Sat, 30 Mar 2024 14:53:31 +0000

How do you propose to isolate each application's access to their XDG directories, unless you put them into their own location?

Or should each application have access to each other's data, thus defeating part of the containerisation strategy?

GNOME 46 puts Flatpaks front and center

ebassi — Sat, 30 Mar 2024 14:50:08 +0000

So GNOME should increase the desktop market share by… doing what the existing, hard core user base of Linux wants, as opposed to appealing to other, different user bases?

GNOME 46 puts Flatpaks front and center

zblaxell — Fri, 29 Mar 2024 22:53:10 +0000

I can see why many people would have a history of bad touchpad experiences.

At one time I had a Macbook and a netbook, with vastly different sizes and configurations of touchpad. The Macbook's factory touchpad configuration was awesome if the touchpad is the size of a postage stamp, and the netbook's factory touchpad configuration was awesome if the touchpad is larger than a human hand. Both of these would have been intolerable without the Synaptics configuration tools to change the defaults.

For legacy reasons, the netbook default configuration carved up the touchpad into separate scrolling and clicking regions (even though the touchpad had dedicated buttons!), so there was no room left on the pad for moving the cursor around. Touching the device almost anywhere caused unintentional input. Moving the mouse across the screen to a small target without randomly clicking or scrolling something nearby was like a game of Operation--if the game of Operation deleted something important at random whenever you lost the game.

At the time, I was accustomed to the PC convention for larger (but not as large as Macbook) touchpads, so I wanted all the familiar separate scroll and click areas. The Macbook's huge configurable touchpad could easily accommodate all of them, as well as the missing buttons, and still have plenty of space left over for high-resolution, high-speed pointer movement, without using any multi-finger gestures.

Eventually I grew out of scrolling regions in favor of multi-finger gestures, and netbook manufacturers stopped supplying separate buttons, so now every touchpad gets the same configuration. I no longer know what the defaults are. Judging from what is printed on the touchpads these days (is that...a numeric keypad?), I'm certain I prefer ignorance.

These days I mostly use a mouse for CAD, but that's because I usually use a desktop workstation for CAD, and the mouse is still the norm on that hardware configuration. I don't do enough CAD to justify one of the more exotic input devices.

GNOME 46 puts Flatpaks front and center

Cyberax — Fri, 29 Mar 2024 21:28:40 +0000

Completely stagnant Linux desktop market share?

GNOME 46 puts Flatpaks front and center

pizza — Fri, 29 Mar 2024 19:42:29 +0000

> Know your audience.

....What makes you think GNOME doesn't "know their audience"?

In a sense this is actually a circular argument; Gnome's audience is the folks who like the approach that Gnome has taken for the past *fifteen years* [1]

Those that didn't like that approach forked G2 to create Mate, and G3 to create Cinnamon. Neither is anywhere near as popular as upstream G3.

[1] It's much older than that; there's a clear progression going back to the pre-G2 days.

GNOME 46 puts Flatpaks front and center

pizza — Fri, 29 Mar 2024 19:32:20 +0000

> That seems _very_ unlikely, Ubuntu advertised and branded "Unity" desktop pretty heavily as an alternative to GNOME, so anyone who cared either knew they were using Ubuntu and didn't think about GNOME, or knew they were using Unity and not GNOME3.

It's both -- Unity first landed in Ubuntu 10.10, initially as a "lightweight netbook environment", with G2 still on "regular" desktops.

Gnome 3.0 landed six months later, in April of 2011. Fedora 15 was the first distro to formally ship it (May 2011)

Ubuntu completely dropped G2 in favor of Unity-for-everyone with their 11.10 release and due to the way they implemented Unity (by making incompatible changes to core gnome libraries/components) made it impossible for G3+ and Unity to coexist on the same system. This is the same era in which Canonical went down many other partially-baked NIH/EEE rabbit holes aiming to lock folks into "Ubuntu", as opposed to "Linux"; Nearly all were ultimately abandoned when the various wider developer communities refused to sign CLAs or otherwise participate. And Canonical realized it was a lot more profitable to not compete with all of their upstreams...)

Meanwhile, Mate saw its first release in August of 2011, essentially a fork of G2's final codebase. Cinnamon saw its first release in December 2011, recreating the G2 look/feel on top of the G3 codebase. AFAIK they are both actively developed and are packaged for major distros for all users that care enough to do so. Yet neither has more than a fraction of the install base as stock gnome... because most users simply don't care.

GNOME 46 puts Flatpaks front and center

Cyberax — Fri, 29 Mar 2024 15:58:43 +0000

Yes, and it was a pretty conservative change.

Need I remind you, that GNOME3 in its initial form had dynamic desktops that completely upended all kinds of workflows? It introduced "Activities" view instead, made the top bar nearly useless, and removed pretty much all possible customizations.

GNOME 46 puts Flatpaks front and center

raven667 — Fri, 29 Mar 2024 15:30:19 +0000

This is becoming a tangent, but with GNOME it's far more likely to be in front of a nerd than an office drone, so while I do appreciate the commitment to design and simplicity, the user stories should maybe be weighted toward Developer/Operations workstations, without losing the usability that allows other office workers and home users to share in the experience. Know your audience.

GNOME 46 puts Flatpaks front and center

raven667 — Fri, 29 Mar 2024 15:24:38 +0000

There was a long stretch where Apple was shipping top-of-the-line trackpads and drivers (from Synaptics I think) and most other vendors were shipping lower spec trackpads with worse drivers (eg using PS/2 mouse emulation) but I think most higher-end laptops are shipping trackpads and drivers (Precision Touchpad?) that are equivalent to what Apple uses. My Dell Precision work laptop touchpad seems to work as well as the MacBook Pro it replaced.

GNOME 46 puts Flatpaks front and center

raven667 — Fri, 29 Mar 2024 15:14:37 +0000

> I'd wager far more people used (and reacted badly to) Unity than "true" Gnome3

That seems _very_ unlikely, Ubuntu advertised and branded "Unity" desktop pretty heavily as an alternative to GNOME, so anyone who cared either knew they were using Ubuntu and didn't think about GNOME, or knew they were using Unity and not GNOME3. This seems like an attempt to recontexualize the criticism of GNOME3 by creating a "no true Scotsman" scenario. I'm not sure that people really disliked Unity, my assumption is that Canonical doesn't have the resources to maintain a whole desktop environment on their own, so they needed to share resources with GNOME to be able to ship anything at all.

Personally I like GNOME3 and the aggressive commitment to visual simplicity, but lets not pretend that other opinions don't exist or are laughably mistaken.

GNOME 46 puts Flatpaks front and center

malmedal — Fri, 29 Mar 2024 15:12:59 +0000

> If you're design something to operate a certain way, of course you're going to ignore the feedback that demands you operate differently.

Much of the feedback I'm seeing seems motivated to help Gnome achieve its stated goals. I'm sure the criticism will abate if Gnome clarifies what these are.

GNOME 46 puts Flatpaks front and center

Wol — Fri, 29 Mar 2024 14:35:30 +0000

I use an ergonomic keyboard and trackball, I find an ordinary keyboard and laptop trackpad very unpleasant to use.

The disappearance of things like scroll bars and obvious ways to scroll is a real pain. And at work with gmail, I often have to export images in email because I can't find anyway of scrolling at all!

Cheers,
Wol

GNOME 46 puts Flatpaks front and center

ejona86 — Fri, 29 Mar 2024 14:26:07 +0000

Comingling xdg dir-complient app's .config, .local, .cache and app download into a single .var is the issue.

GNOME 46 puts Flatpaks front and center

ejona86 — Fri, 29 Mar 2024 14:19:47 +0000

In my post I mention the benefit of allowing applications to add restrictions as they adapt to the sandbox. But don't show that to the user. The theater is mostly the UI in how permissions are displayed (or not!) and upgraded. Only a highly technical user can determine if the permissions are safe (and can't do it from the UI), and who knows the state after an upgrade. You can't trust the sandbox; you can only trust the publisher and reviewer.

GNOME 46 puts Flatpaks front and center

pizza — Fri, 29 Mar 2024 14:03:27 +0000

> If anything, Unity was a pretty conservative change compared to G2.

"Change the look/feel to be much more like MacOS than Windows" is not a "pretty conservative change"

GNOME 46 puts Flatpaks front and center

gioele — Fri, 29 Mar 2024 13:52:51 +0000

> > Although Flatpak itself doesn't adhere to XDG base directories; it puts everything under ~/.var.
>
> That's just because XDG_STATE_HOME hasn't been formalised in the base directories spec, even if it has been discussed multiple times:

XDG_STATE_HOME is in version 0.8 of the basedir specs (released in May 2021): https://specifications.freedesktop.org/basedir-spec/based...