Canonical Details Ubuntu 24.04 Desktop Plans + Ongoing X11 Sunsetting Discussions

[oiaohm]

nvidia works just fine with wayland apps btw. The only things that dont work with nvidia on wayland is intentionally disabled by the wayland protocol, and afaik there is no discussion by anyone to get them working.

Absolutely not true.

https://download.nvidia.com/XFree86/Linux-x86_64/535.146.02/README/wayland-issues.html

Indirect GLX does not work with Xwayland because the Glamor rendering engine is not compatible with our EGL implementation.

When AMD Intel and everyone else EGL works with glamor this is Nvidia fault. This issue with Glamor is also why xepher when using Nvidia has not had opengl acceleration when using Nvidia gpu but you have it with everything else.

Virtual reality displays, such as the SteamVR platform, require support for DRM display leasing which does not currently work.

Works with AMD and Intel .

Lot of Nvidia driver issues left that are not Wayland protocol fault. Its that Nvidia needs to expose things using the normal DRI/DRM kernel interfaces instead of what they have been doing.

[mSparks]

That incorrect presume.

https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html

https://fedorapeople.org/groups/schedule/f-42/f-42-key-tasks.html

Fedora 41 will be released before RH10. And F42 will most likely released before RH10

RH10 will not be a fork off F40. Instead RH10 will be off either F41 or F42 and possible mix between 41 and 42 (this has happened before).

You forgot Fedora releases twice per year.

May 27, 2025 Yes 5 month that the marked RH10 release date. Target date 2025-04-22 for F42 this is one month before RH10 release date.

The release dates of RH10 are lined up to be based off F42.

definitely forking FC40 according to the devel list

https://lists.fedoraproject.org/archives/list/[email protected]/thread/IXNTPGKHWTW7H7XVMZICSJRUDOHO2KJC/

The fork will be Fedora 40 (2024-02-06)
All the major versions will then stay the same for the life of RHEL10.

[mSparks]

Absolutely not true.

https://download.nvidia.com/XFree86/Linux-x86_64/535.146.02/README/wayland-issues.html

When AMD Intel and everyone else EGL works with glamor this is Nvidia fault. This issue with Glamor is also why xepher when using Nvidia has not had opengl acceleration when using Nvidia gpu but you have it with everything else.


Works with AMD and Intel .

Lot of Nvidia driver issues left that are not Wayland protocol fault. Its that Nvidia needs to expose things using the normal DRI/DRM kernel interfaces instead of what they have been doing.

xwayland is a completely different topic, it provides very limited support for a small number of X11 applications and is not intended for use in production. As long as you want to use X11 applications instead of wayland applications it is best to stick with an X11 desktop.

EGL is basically unsupported by wayland, which is all about doing everything with vulkan. nividia has no known issues there.

[oiaohm]

definitely forking FC40 according to the devel list

Someone need to learn to read because that does not say RHEL 10. You have jumped to incorrect idea with the CentOS Stream 10.

That is https://en.wikipedia.org/wiki/CentOS_Stream

That is CentOS Stream 10 not RHEL 10 they are very different things and there is something critical about CentOS Streams you have overlooked its a Rolling Release.

CentOS Stream 10 will be used to work out what needs to be fixed up in FC41 and F42 before RHEL10 release and merged back into CentOS Stream 10 so completely changing it make up.

RHEL 9 is not based on first day release CentOS Stream 9. CentOS Stream is a Rolling-Release so it packages will keep on being updated for the complete time it exists.

Think of CentOS Stream like a Debian testing how most the the packages that are in Debian testing at the start of it cycle are not there at the end of debian testing when debian testing comes a debian stable release because they have been replaced..

Yes CentOS Stream 9 forked off at one version of Fedora but by the time Rhel 9 released there was not a single package of the version of Fedora CentOS Stream started from was left.

CentOS Stream covers multi editions of Fedora and this has happened with CentOS Stream 8 and 9 we have no reason to suspect CentOS Stream 10 will be any different. CentOS Stream is going to cover FC40-42 before RHEL10 releases. With packages most likely FC41 based by the time Rhel10 releases but there could be some from FC40 and some from FC42 as well.

There is more in-depth quality control checking as packages get merged into CentOS Stream than getting into Fedora.

[oiaohm]

EGL is basically unsupported by wayland, which is all about doing everything with vulkan. nividia has no known issues there.

That wrong.

Weston's hardware acceleration (GL-renderer) depends on EGL

https://wayland.freedesktop.org/building.html

Wayland protocol was first created before Vulkan existed. Vulkan is from 2016 as you have said Wayland is older. Wayland is design to be on EGL implementation to Khronos Group specification.

Nvidia has been attempting to push Wayland compositors like KDE and Gnome to have vulkan backends.

EGL is well supported under Wayland if you are using any GPU other than Nvidia one.

[mSparks]

Someone need to learn to read because that does not say RHEL 10. You have jumped to incorrect idea with the CentOS Stream 10.

That is https://en.wikipedia.org/wiki/CentOS_Stream

That is CentOS Stream 10 not RHEL 10 they are very different things and there is something critical about CentOS Streams you have overlooked its a Rolling Release.

CentOS Stream 10 will be used to work out what needs to be fixed up in FC41 and F42 before RHEL10 release and merged back into CentOS Stream 10 so completely changing it make up.

RHEL 9 is not based on first day release CentOS Stream 9. CentOS Stream is a Rolling-Release so it packages will keep on being updated for the complete time it exists.

Think of CentOS Stream like a Debian testing how most the the packages that are in Debian testing at the start of it cycle are not there at the end of debian testing when debian testing comes a debian stable release because they have been replaced..

Yes CentOS Stream 9 forked off at one version of Fedora but by the time Rhel 9 released there was not a single package of the version of Fedora CentOS Stream started from was left.

CentOS Stream covers multi editions of Fedora and this has happened with CentOS Stream 8 and 9 we have no reason to suspect CentOS Stream 10 will be any different. CentOS Stream is going to cover FC40-42 before RHEL10 releases. With packages most likely FC41 based by the time Rhel10 releases but there could be some from FC40 and some from FC42 as well.

There is more in-depth quality control checking as packages get merged into CentOS Stream than getting into Fedora.

You dont seem to understand how they changed it.

FC40 gets forked into CentOS streams 10, then any bugs they find in centos streams 10 goes into closed source RHEL10. Major versions (especially the kernel and glibc) all stay the same at whatever FC40 is at on the 2nd of June, with only security patches and bug fixes, no breaking changes.
FC41 and 42 etc will continue with the same cadance as always. RH9 from streams 9 was FC34 iirc.

This is more or less exactly what ubuntu LTS does with debian, except that of all the things you can say about conanical, they at least arent software pirates.

[oiaohm]

FC40 gets forked into CentOS streams 10, then any bugs they find in centos streams 10 goes into closed source RHEL10. Major versions (especially the kernel and glibc) all stay the same at whatever FC40 is at on the 2nd of June, with only security patches and bug fixes, no breaking changes.

That no breaking changes you need to take with a serous grain of salt. Redhat has taken out fake CVE before to give reason to replace complete packages in RHEL9 and
RHEL8.

Yes if you have RH9 and look the package versions you find a lot are not FC34 package versions but FC35 package versions. No breaking changes allows replacing packages with newer versions with no ABI breakage.

The RHEL releases looking at package versions are always a mix of 3 FC versions. RHEL9 if you look at the xserver and xwayland package versions they were FC35. So RHEL10 xwayland being FC41 would not be surprising.

Centos Stream 10 is not a 100 percent lock down preventing package version changes. Yes the packages in RHEL9 that are FC36 were replaced on security grounds and there are not many of these.

Remember how you said especially kernel and glibc. Why did you have to write especially. Fairly much at Centros Stream 10 release that the two parts of RHEL 10 that you can say is nailed down. History with RHEL8 and RHEL9 tells you that quite a bit sill can be changed after that point.

[mSparks]

That no breaking changes you need to take with a serous grain of salt. Redhat has taken out fake CVE before to give reason to replace complete packages in RHEL9 and
RHEL8.

Yes if you have RH9 and look the package versions you find a lot are not FC34 package versions but FC35 package versions. No breaking changes allows replacing packages with newer versions with no ABI breakage.

The RHEL releases looking at package versions are always a mix of 3 FC versions. RHEL9 if you look at the xserver and xwayland package versions they were FC35. So RHEL10 xwayland being FC41 would not be surprising.

Centos Stream 10 is not a 100 percent lock down preventing package version changes. Yes the packages in RHEL9 that are FC36 were replaced on security grounds and there are not many of these.

Remember how you said especially kernel and glibc. Why did you have to write especially. Fairly much at Centros Stream 10 release that the two parts of RHEL 10 that you can say is nailed down. History with RHEL8 and RHEL9 tells you that quite a bit sill can be changed after that point.

well, we are talking hyperthetically since they can of course do things that haven't happened yet differently than they did in the past or planned for the future.)

what mostly gets locked down is the glibc version, because even minor versions of that is very breaking changes.

Im quite interested to see how releasing an OS with only something like 3 working applications and zero developer interest works out for them tbh. I suspect that maybe doesnt work out for them, and lots will change. Canonical/Ubuntu seem to agree

AIUI, this is also why we are now seeing so many commits to xwayland on x.org - they are desperately upstreaming all the fixes they made for RH9 so they don't get lost in RH10.

[oiaohm]

well, we are talking hyperthetically since they can of course do things that haven't happened yet differently than they did in the past or planned for the future.)

what mostly gets locked down is the glibc version, because even minor versions of that is very breaking changes.

https://blog.centos.org/2022/09/how-updates-work-in-centos/

https://composes.stream.centos.org/stream-10/

This is where things get interesting. Technically cantos stream 10 has already started it build cycle.
https://blog.centos.org/2022/09/how-...ork-in-centos/ Yes FC40 is not release yet.

Up until the official release changing kernel version and glibc version is absolute allowed. Before stream there was one case of a glibc updated to a newer version of fedora than what the version of kernel was from. So this cannot be taken as 100 percent set in stone. RHEL developers don't publish the exact list of what locked down at what point.

There is talking hypothetically and there is over guessing. The reality here is Centos Stream is not as set in stone as your were making out. RH10 will have a lot newer parts include that what will be in Centos Stream when its version 10 releases. Of course some part will be from day one but history of RH8/RH9 tells that this may not be alot.

Centos Stream has not done this yet but by its release policies it can technically point release with a ABI breaking change where they replace the kernel or glibc on security grounds. This section of the release policies of Centos Stream for 8 and 9 was not used.

I would say end of 2024 looking at Centos Stream might be able to give a clear picture what RH10 is going to be. The early Centos Stream 10 release at the start of 2024 is likely to lead you up the garden path on what the limitations are going to be.

AIUI, this is also why we are now seeing so many commits to xwayland on x.org - they are desperately upstreaming all the fixes they made for RH9 so they don't get lost in RH10.

This is you wild guessing again without looking at history to find out what normal development rate for x.org xserver has been..

https://www.phoronix.com/news/XServer-2022-Development-Pace

You have to remember in 2022 that was 156 commits and that was classed as a bad year for xserver development. Yes 2021 was over 300 commits.

200~ commits is still in the range of low development for the xserver project. So you would say xwayland number of commits is in the normal range for a X11 server with active development.

Xserver branch at under 30 commits in 12 time frame is very low. You have to go back to 2002 to see development on xserver that less than 100 commits in a year.

I would not say your statement is 100 percent wrong that Redhat might be up-streaming slightly more patches than normal but from the historic numbers you are saying that is maybe 10-30 commits more.

Redhat normal alteration rate to x.org xserver master branch since 2004 is between 100 to 500 commits per year. The number of commits on Xwayland is not really that high or really that low compared to Redhat developer normal rates.

Yes there have been past years when Redhat had a release coming and they were desperately getting alterations into the xserver before release that when we have see the 300-400+ years out of redhat.

The xserver branch that at under 30 commits for year that insanely low. With majority of those being redhat. The reality here is if redhat was still working on xserver branch at their normal rate it would have been over 100 commits. No one stepping up to fill Redhat shoes with xserver branch for bare metal.

mSparks so by Redhat historic commit numbers don't support the argument that they are desperately up-streaming in any major way. Its more likely to be Redhat normal rate of upstreaming with xwayland than anything else. xserver branched slowed down is part that Redhat has stopped really working on it.

[partcyborg]

Absolutely not true.

https://download.nvidia.com/XFree86/Linux-x86_64/535.146.02/README/wayland-issues.html

This list is incredibly old and terribly out of date. Nearly all of the issues listed here have been fixed since the 545.29.02 driver.