Fedora 40 Eyes Dropping GNOME X11 Session Support

[mSparks]

If you want to run it inside a GRID or other based cloud solution where you cannot export graphics out over network instead have to use a virtual network card. Dynamic VM placement inside a cloud means you don't have a fixed IP address to connect to so destroys using ssh and X11 over network and xpra. You have to use the virtual KVM of the solution to control the guests.

https://ubuntu.com/security/notices/USN-6168-1

Also the old libx11 that on those old installs is horrible security broken.

You are going wanting to run a xpra proxy between those old machines and the outside world. xpra uses own network protocol that blocks stack of X11 protocol/libx11 issues. Yes there is a reason why different cloud services disable ssh -X in the provided images. There are things that a modern client X11 server will reject that a RH4 or a sunos 2.0 will expect to be allowed todo that where the xpra proxy comes in. Yes having to deal with old RH3 and RH4 instances I am very aware of these problems.

X11 protocol is not perfectly compatibility.

meanwhile, in the real world unlike X11, much wayland stuff really is completely resourceless and completely broken.

e.g.

https://community.st.com/t5/stm32cubeide-mcus/any-plans-to-fix-stm32cubeide-wayland-bug/m-p/304920

so which image do you think most everyone adopted?

https://github.com/STMicroelectronics/meta-st-openstlinux

the weston one, or the x11 one.

[oiaohm]

so which image do you think most everyone adopted?

https://github.com/STMicroelectronics/meta-st-openstlinux

the weston one, or the x11 one.

Neither openstlinux-eglfs is more common with a Qt custom wayland compositor in the embedded space than X11 or Weston. Yes raw qt eglfs is more common than the wayand compositor on eglfs and weston and X11 combind. Its all about ram consume mSparks.

STMicroelectronics did in fact publish stats on this.

[mSparks]

Neither openstlinux-eglfs is more common with a Qt custom wayland compositor in the embedded space than X11 or Weston. Yes raw qt eglfs is more common than the wayand compositor on eglfs and weston and X11 combind. Its all about ram consume mSparks.

STMicroelectronics did in fact publish stats on this.

EGL already replaced wayland..... interesting.
EGL only gnome when?

[oiaohm]

EGL already replaced wayland..... interesting.
EGL only gnome when?

No EGLFS is not EGL.
EGLFS is a QT application running without X11 or Wayland you would call this straight to KMS,

https://doc.qt.io/qt-6/embedded-linux.html

https://www.youtube.com/watch?v=mIg1P3i2ZfI

Yes writing your own wayland compositor in qt for embedded use like a car dash and the like has been around for a while.

Lot of uses of openstlinux are single application devices where having a display manager or compositor really makes no sense. In fact that is the dominate use case. Yes and a lot of the cases of Wayland compositor in qt with them are what you can feature creep they started off with a single qt application the feature creeped and now it come simpler to put in like a wayland video player program or the like. Yes these are some quite mess wayland compositors that cannot make up their mind if they are application or a compositor because they started life as a application and had the compositor bit tacked on.

[mSparks]

Lot of uses of openstlinux are single application devices where having a display manager or compositor really makes no sense.

The historic use for X11. multiple realtime applications running on discrete dislocated cpus that all talk to a single central display server, aka how to run a bread factory, each machine in the factory runs its own X11 client, managed from a central location on a master display server, probably a backup or two.

You seemed to be saying this would be done with wayland for the last few months.

In fact, the whole premise of this thread is the assertion wayland is ready to develop this now.

[oiaohm]

The historic use for X11. multiple realtime applications running on discrete dislocated cpus that all talk to a single central display server, aka how to run a bread factory, each machine in the factory runs its own X11 client, managed from a central location on a master display server, probably a backup or two.

That model is dead in the embedded world.

https://github.com/Etrnls/qthtml

Meet the replacements. Toolkits be it gtk or qt having html5 backend. xpra html5 for legacy X11 applications.

https://github.com/udevbe/greenfield

Above is the fun one. Yes that greenfield is that old X11 model done with Wayland but with the client only needing a webbrowser.

You seemed to be saying this would be done with wayland for the last few months.

No I have not been. I have said these items have already been done but you never been asking question why not developing. I have been saying the Wayland protocol does not need to the network feature. X11 network protocol is basically dead and has been dead for a lot of uses cases for a very long time.

Wayland using solutions where you have a local Wayland compositor of some forward with some form of forwards will be used. Also HTML5 lot of things will just use this directly.

Why require a user to install a X11 server on a computer for remote applications when the computer has a perfectly functional webbrowser with HTML5 that is more feature rich than the X11 protocol. Remember HTML5 was released in Jan 2008 before the wayland protocol exists. Remember the X11 protocol was released before HTML as a protocol exists.

Waypipe demos that Wayland applications can be sent over network if wish. Problem is do you really want to.

It would help if you were asking for something that makes sense.

Take that historic bread factory example and bring in a 1 modern things. Lets say a CEO just got iphone who wants to monitor the factory individual parts from his phone while walking around the factory. Yes you install Mocha X11 but it does not work well. Why factory makes a lot of radio noise making the signal to the iphone unstable. Also this starts going counter to the single central display server because the parties running the factory and the CEO want to access the same things.

X11 protocol networking was designed for hard wired lossless networking not wifi/radio based networking that losses packets. X11 protocol network part is not design for cases where the output of the application need to go in multi different directions. Once you have to start designing for a lousy network that losing packets left and right things changes a lot.

HTML5 is design for radio based networking with issues and is designed to allow for the case you need to send multi copies of the same output to many different clients.

Next mSparks what happens if the master display server in your bread factory example crashes. That right all the X11 client programs around the bread factory will die hopefully they were not doing anything important. The reason why xpra exists in the first place is so you don't have a single point of absolute failure.

mSparks basically once SOD law kicks in the bread factory model you just proposed is not safe to use and factories doing what you have described have had human fatalities due to that single point of failure of the X11 display server.

X11 networking part of the X11 protocol simple makes no sense in any factory setting because it is not safe to use. Factories that have X11 have been using local xpra with the X11 client application so that X11 master display server crashes nothing bad happens. Of course since they are already using xpra and xpra has HTML5 option these days lot of those factories are now full HTML5 setups where mutli people can be looking at the monitoring output at the same time. Yes xpra permissions with HTML5 you can be looking but unable to control. Yes new versions of the monitoring solutions in factories are web applications so no X11 and no Wayland.

In fact, the whole premise of this thread is the assertion wayland is ready to develop this now.

For the desktop use case where Wayland makes sense. Fedora is a bleeding edge thing. So the path Fedora going does not have to be 100 percent ready.

X11 protocol network design for a lot of use cases absolutely makes no sense.
1) does not make sense in factory its unsafe you have to run local xpra that basically local X11 server to X11 client app so that this is safe.
2) Cloud provided virtual machines where the cloud provider may be moving your instance between servers without notice. Yes GRID where you are using a virtual GPU out(html provides KVM) works but ssh and X11 protocol network bits don't work in this case. Lot of HPC dynamically move workloads around. Think about it how well does X11 server cope with its IP address changing.

There are features people attempt to demand to be in Wayland protocol for reasons that when you check them out don't make any sense any more. We are no longer in a world of lossless networking for many use cases that use to be lossless networking.

HTML5 has encryption authentication compression and tolerance of unstable networking. Does Wayland protocol really need to reinvent the HTML5 wheel for remote? What feature does HTML5 need out of wayland that right running as a local compositor to provide HTML5 data.

[mSparks]

That model is dead in the embedded world.

https://github.com/Etrnls/qthtml

Meet the replacements. Toolkits be it gtk or qt having html5 backend. xpra html5 for legacy X11 applications.

https://github.com/udevbe/greenfield

Above is the fun one. Yes that greenfield is that old X11 model done with Wayland but with the client only needing a webbrowser.



No I have not been. I have said these items have already been done but you never been asking question why not developing. I have been saying the Wayland protocol does not need to the network feature. X11 network protocol is basically dead and has been dead for a lot of uses cases for a very long time.

Wayland using solutions where you have a local Wayland compositor of some forward with some form of forwards will be used. Also HTML5 lot of things will just use this directly.

Why require a user to install a X11 server on a computer for remote applications when the computer has a perfectly functional webbrowser with HTML5 that is more feature rich than the X11 protocol. Remember HTML5 was released in Jan 2008 before the wayland protocol exists. Remember the X11 protocol was released before HTML as a protocol exists.

Waypipe demos that Wayland applications can be sent over network if wish. Problem is do you really want to.

It would help if you were asking for something that makes sense.

Take that historic bread factory example and bring in a 1 modern things. Lets say a CEO just got iphone who wants to monitor the factory individual parts from his phone while walking around the factory. Yes you install Mocha X11 but it does not work well. Why factory makes a lot of radio noise making the signal to the iphone unstable. Also this starts going counter to the single central display server because the parties running the factory and the CEO want to access the same things.

X11 protocol networking was designed for hard wired lossless networking not wifi/radio based networking that losses packets. X11 protocol network part is not design for cases where the output of the application need to go in multi different directions. Once you have to start designing for a lousy network that losing packets left and right things changes a lot.

HTML5 is design for radio based networking with issues and is designed to allow for the case you need to send multi copies of the same output to many different clients.

Next mSparks what happens if the master display server in your bread factory example crashes. That right all the X11 client programs around the bread factory will die hopefully they were not doing anything important. The reason why xpra exists in the first place is so you don't have a single point of absolute failure.

mSparks basically once SOD law kicks in the bread factory model you just proposed is not safe to use and factories doing what you have described have had human fatalities due to that single point of failure of the X11 display server.

X11 networking part of the X11 protocol simple makes no sense in any factory setting because it is not safe to use. Factories that have X11 have been using local xpra with the X11 client application so that X11 master display server crashes nothing bad happens. Of course since they are already using xpra and xpra has HTML5 option these days lot of those factories are now full HTML5 setups where mutli people can be looking at the monitoring output at the same time. Yes xpra permissions with HTML5 you can be looking but unable to control. Yes new versions of the monitoring solutions in factories are web applications so no X11 and no Wayland.



For the desktop use case where Wayland makes sense. Fedora is a bleeding edge thing. So the path Fedora going does not have to be 100 percent ready.

X11 protocol network design for a lot of use cases absolutely makes no sense.
1) does not make sense in factory its unsafe you have to run local xpra that basically local X11 server to X11 client app so that this is safe.
2) Cloud provided virtual machines where the cloud provider may be moving your instance between servers without notice. Yes GRID where you are using a virtual GPU out(html provides KVM) works but ssh and X11 protocol network bits don't work in this case. Lot of HPC dynamically move workloads around. Think about it how well does X11 server cope with its IP address changing.

There are features people attempt to demand to be in Wayland protocol for reasons that when you check them out don't make any sense any more. We are no longer in a world of lossless networking for many use cases that use to be lossless networking.

HTML5 has encryption authentication compression and tolerance of unstable networking. Does Wayland protocol really need to reinvent the HTML5 wheel for remote? What feature does HTML5 need out of wayland that right running as a local compositor to provide HTML5 data.

absolute nonesense, the RT guys are some of the most significant contributors to the Linux kernel in recent years.
e.g.

https://www.linrt.com/

The PREEMPT_RT stuff eclipses anything RH has contributed in its entire lifetime.

[oiaohm]

absolute nonesense, the RT guys are some of the most significant contributors to the Linux kernel in recent years.
e.g.

https://www.linrt.com/

The PREEMPT_RT stuff eclipses anything RH has contributed in its entire lifetime.

Really absolute noneense. Lets go though that companies image list.

• LinRT headless tiny image

This is command line and http server so no X11 or Wayland Here.

• LinRT tiny qt5 image
• LinRT tiny video capture image
• LinRT full multimedia image
• LinRT video capture image
• LinRT full multimedia Qt 5 image
• LinRT HTML5 image

All direct KMS/DRI so 6 of those and some of those have http servers as options like the tiny video capture(think network webcam). No Wayland or X11 here. In the applications built on top of these you might see qt wayland being used to provide a wayland server inside the applications.

• LinRT Wayland/Weston full multimedia Qt 5 image

One Weston.

• LinRT X11 full multimedia Qt 5 image
• LinRT X11/Sato full multimedia Qt 5 image
• LinRT X11 HTML5 image

Yes 3 X11 mostly for legacy solutions and these are direct output not over network X11. Yes the X11 on them is built with TCP X11 disabled as built option..

• LinRT Debian11 “Bullseye” image for i.MX6Q/DL, i.MX8M-mini and i.MX8M-Plus (with NXP Linux kernel 5.4 PREEMPT-RT BSP

Yes this Debain 11 image is a Weston default for graphical as well. So 2 Wayland possible 4 X11 but 7 without either.

I have used linRT based software mSparks I know their product line. It was their product line that made me wake up that hang on the embedded space is not going Wayland or X11. Instead the dominate cases are KMS/DRI direct and http.

LinRT don't make items for the following described model:

The historic use for X11. multiple realtime applications running on discrete dislocated cpus that all talk to a single central display server, aka how to run a bread factory, each machine in the factory runs its own X11 client, managed from a central location on a master display server, probably a backup or two.

Yes this model is dead for new projects completely.

[mSparks]

LinRT don't make items for the following described model:


Yes this model is dead for new projects completely.

lol,
RT is the industries second largest growth area after AI

jeez.

https://ubuntu.com/blog/what-is-real-time-linux-i

[mdedetrich]

One of the reasons NetFlix using FreeBSD on the caches is why Sony uses FreeBSD on the playsation 5. We don't want clients asking for source code and that we might have to hand over something business critical.

No its not, Netflix publicly said the reason they used FreeBSD is that at the time Linux's networking stack was shit which was definitely true. There are no relevant clients here for Netflix because these video content caching machines just sit in ISP's, there isn't going to be any clients asking for the source in this case.