Official stance on dropping X11 from major release 16?

According to https://code.opensuse.org/leap/features/issue/183

We should drop Xorg server from SLFO and only ship Wayland for graphical display, to ensure we don’t have to maintain Xorg server for the lifetime of SLFO.

Is there any official stance on that topic?

Will be X11 kept or dropped in case of major 16 release?

Thanks for clarification.

If X11 is dropped in SLE 16, then the community is going to need to step up to provide the maintenance to keep it alive in Leap 16.x

That’s how it works. I don’t know if that decision has been made for SLE yet.

2 Likes

Although I don’t use Leap, I agree with the comment from ‘cbus’ on that page. Wayland isn’t ready.

I installed Tumbleweed with LXQt the other day, added the Wayland package and tried out three different compositors.

Initial findings:

  • Not all LXQt components work with Wayland. And you’ll find this with most of the other Linux desktops providing experimental Wayland support. Xfce is another.

  • The Kwin compositor provided an invisible mouse pointer, once the openSUSE Welcome window was closed.

At that point, I erased the drive it was installed on.

3 Likes

shrug If SUSE drops Wayland from SLE 16, unless the community support is there to keep X11 maintained, it’s probably going to be dropped.

Software doesn’t maintain itself.

To the best of my knowledge, the next release of RHEL is going to be Wayland only as well, by default.

1 Like

I think saying RHEL is also doing this is not a good argument.
They removed btrfs support.

The part of Shawn’s post that needs emphasizing is the requisite “community support”.

What I now understand that they plan to remove Xorg X-Servers, which means that your GUI frontend (and driver) is always Wayland and thus:

  • your hardware must be supported by Wayland - KMS kernel driver and often Mesa (gnome-shell requires working OpenGL and thus without working Mesa+KMS you will be unable to see even login screen - note that GDM is no longer Login Manager - it just calls gnome-shell with hidden paramter --mode=gdm).
  • older binary NVIDIA drivers (that support only GLX - X11 OpenGL acceleration) will no longer work. Must use nouveau KMS driver
  • X11 only Login Managers/screensavers/lockers will no longer work
  • X11 Desktop Environments will not work - XWayland emulator supports applications but not Window Managers
  • individual X11 apps may work (using XWayland that emulates X-Server under Wayland) but expect problems (for example “xeyes” is unable to track mouse outside its Window, because Wayland restrictions).

My personal experience with Wayland (Fedora 41 Workstation - GNOME) is so far:

  • PC with Intel graphics work fine (tested on Zotac NANO and MSI Cubi)
  • PC with NVIDIA GT218 - catastrophe - some Mesa/KMS kernel versions completely broken, others work only with quirks
  • VirtualBox Wayland guests never works with VMSVGA+3D acceleration enabled (must disable 3D)
  • KVM guests have unexpected issues (Sway/Wayland has lagging mouse - unusable).
1 Like

Correct. And “Oh just because Red Hat is choosing to do something is non-relevant as a factor” is a silly argument.

Developers need to have roofs over their heads, and feed their families just as much as anybody else.

And Red Hat good, or bad, has been one of the driving forces behind enterprise desktop linux, and funding a fair bit of development. And if they drop the X11 Display Server from their enterprise product, that means they have one less software stack to pay developers to maintain. I know it’s fun to pretend that each distribution can do everything all on their own, and what happens in other corners of the FOSS world, or other distributions doesn’t affect our little corner, but it’s not true now, and it never really has been.

The development of the X11 stack has been moribund for years, with the exception of the Xwayland server, and that isn’t likely to change.

And I don’t think people understand just how much work goes into maintaining something like a display server stack. So yes, if Red Hat chooses to drop X11 in the next major release of RHEL, it absolutely does affect us(openSUSE), and while I have no personal knowledge of it, I would have a hard time believing that the decisions of SUSE, with their own Enterprise offerings, weren’t affected by the implications of that decision.

3 Likes

And CPU v2 support is needed… https://github.com/openSUSE/opensuse-migration-tool/issues/22

And CPU v2 support is needed…

Good catch! That CPU v2 nonsense (Linus bashed it nicely on https://www.phoronix.com/news/Torvalds-Mind-Fart-x86_64-Level) puzzles me because:

LTS distributions including:

  • RHEL 9+ requires it
  • (open)SUSE 16+ requires it

But paradoxically - bleeding edge distributions are fine:

  • Arch Linux still works on old CPUs
  • Fedora (including Rawhide) still works on old CPUs

Can anybody explain that paradox: Why LTS distributions (which are supposed to run many years on aging HW) requires v2 or even v3, while bleeding edge distros are fine on old HW?

@hpaluchpe It’s all about the support and also the support process.

The Leap series is a snapshot in time from Tumbleweed. Maintainers by accepting a package submission agree to maintain for the lifetime (well as best they can), with critical bug fixes and CVE’s etc. But NOT version updates unless there is a specific reason…

In a lot of cases it’s easier from a maintenance point of view to submit patches or upstream updates to the rolling release than it is to backport parts to a release under maintenance and test etc.

RHEL and SUSE SLE make money on server market.
X86-64-v3 provides good boost comparing to common AMD64 = x86-64. It is difficult to find modern servers with CPUs without x86-64-v3 support.
RHEL 10 and SUSE 16 will be x86-64-v3 - only.

Developers will recompile packages from SLE 16 to x86-64-v2 for Leap 16. SUSE (openSUSE) developer wants to implement x86-64-v3, but this is too much for community OS.

If someone wants common x86-64 then it is possible to recompile code.

Theoretically yes, but practically it is prohibitively expensive on resources and skills. And it is not that easy - even when using OBS you have to also build install ISO etc…

I know very well from Gentoo, that building chromium takes (tested on Azure VM):

  • 16 hours on 4 cores
  • 8 hours on 8 cores
  • etc…

And remember that to use 8 cores/make jobs you need at least 32GB of RAM for 8 gcc-c++ processes.

Even such basic things as kernel and/or glibc take each around hour to build…

Again, this is all about money.
Some users complain about inavailability of some feature, but they want that feature for free…
Previously similar situation was with dropping i386 (i586, 32-bit) TW.

I think it’s important to provide some clarity into what “Wayland isn’t ready” actually means here…

Wayland is ready, it has been ready. LXQt’s support for it, in this case, is not. Other desktops such as KDE Plasma, GNOME, window managers such as Sway, System76’s COSMIC desktop, etc… all have Wayland sessions that are quite competent.

Wayland can’t continue to be pushed off because of projects failing to adopt it expediently, nor can Wayland be blamed for something that is 100% not Wayland’s issue, but the desktop’s issue.

2 Likes

I think the issue is that X11 shouldn’t be removed, until, or mostly, all of the Linux desktops are able to support it and that it works reasonably well with them.

At least let those users whose desktops aren’t Wayland-ready (yet?), continue to use X11.

My only experience with Wayland is with KDE, but I no longer use KDE because of other issues, not specific to Wayland.

The security issues and dwindling maintenance of X11 is known since ages. Wayland started its developement in 2008. When Linux desktops, as you call it, still don’t support Wayland after 17 years of development…
Instead of riding a dead horse (X11) it is time to smooth the last few wrinkles in Wayland. If a project still doesn’t support the successor of X11 after so long time, you should check if this project lacks maintenance or is simply ignorant towards the developemnt of the last decade.

2 Likes

Once again, you seem to think that there is a ready pool of developers, just sitting around maintaining things, that they don’t even use, for fun and no profit.

It would be irresponsible and dangerous for the project to be shipping software that has no maintainers looking after it.

We only have so many developers and maintainers in the community. And if SUSE decides to drop X11 from SLE 16, and there is no community maintenance of the X11 stack, then X11 is most likely going to get dropped in Leap 16.

Maybe there are people that are willing to step up, and maintain X11 in Leap 16 and onwards, I honestly don’t know, but I’ve seen no evidence of it so far.

Whether you believe Wayland to be “ready” or not, Wayland is actively maintained, X11 is not.

1 Like

Perhaps “Wayland isn’t ready” was an incorrect choice of words to describe the current situation with it.

I agree with your statement regarding it being irresponsible/dangerous to ship certain software without maintainers.

I do want to thank the openSUSE devs and maintainers for what they do for the project. I know it isn’t easy.

1 Like

Dropping X11 by major distributions also mean dropping it for TW.