GNOME developer proposes removing the X11 session The two changes are just proposals at present, but GNOME's Wayland-only future is on the horizon. Whether that's a good or bad sign is less clear. Jordan Petridis' two merge requests in the GNOME's source code in Gitlab are the most definite signs yet that GNOME is getting close to dropping support for running on what its …
OR (which I prefer)
the GNOME project to go TITSUP for good.
IMHO, they lost the plot with V3 and have only gotten worse since. They (IMHO) seem to be trying to outdo MS in their crazyness.
The devs and more importantly, the management can go suck on this [see icon]
"Choice is not an option..."
Or, as those great philosophers Rush once sang, "If you choose not to decide, you still have made a choice"
I suspect what will really happen is that a very few die-hards will switch to an X.org or a Wayland based desktop and everyone else with stick with their desktop of choice and deal with whatever issues arise from having the display manger changed out from under them.
Personally, I'll be sticking with X.org because I like the client/server model so I can run remote GUI programs[*] on my local display without the remote box having to run an entire desktop that I have to remote into. AFAIK, Wayland has no intention whatsoever in building that option.
* I like to have access to all the programs on my desk top up in the attic/office while still being able to sit down in the lounge with small laptop with my wife. She won't let my have the big desktop and three screens in the lounge.
This post has been deleted by its author
While I am not a big fan of Wayland, there are solutions for using distributed sessions using it. The primary one is XWayland, which allows you to run X sessions to a local Wayland client that is a full X.org server, just using Wayland as a compositor. The other is waypipe which tunnels Wayland protcol across the network, so the remote Wayland client thinks it is talking to a Wayland compositor on it's local system, but is in fact talking to one across the network to your local server (a bit like SSH X11 tunnels).
I had a brief play with both of them, and although there are some slight problems with fonts and capturing some window related events with XWayland, both seemed to work enough so that I could use them.
I'm sticking with X.org for the moment though. All the time I'm working with legacy UNIX systems, I will want to retain the X11 functionality of cross platform graphical sessions.
Personally I use very little of the capability of any desktop manager. I just don't need them in my usage pattern. What I do need is knowing that any problems I encounter in my code are likely my fault, and not the fault of some other huge, unsafely-written blob of code that insists on having read-write access to my address space. In other words, I insist on talking to a display system only through sockets. Unless there is some other mechanism that allows the communication without granting it any access to stuff I care about?
Last time this topic came up, I think I heard about something called "X-Wayland"(?) that sits on top of Wayland and provides the X socket interface to clients to use the desktop. That I can put up with, although it sounds like a kludge and a resource hog.
XWayland is basically lightened X-server without the things that Wayland does, namely rendering.
Wayland itself is much lighter than X since it has no "drawing" commands and such - these are explicitly in the client toolkits.
Here's the thing: most X-clients already use client-side drawing in their toolkits, but X carries a lot of legacy baggage to keep backwards compatibility with ancient applications. Not that they are ever used these days..
Wayland is designed so that applications can't see each other: something that X never enforced but trusted that application developers "play nice" with it. X11 was rather horrid thing that is often misunderstood these days..
I know I'm incredibly old-fashioned, but it seems to me to be more efficient if there is only one set of "drawing commands" on the system, rather than umpteen. There has to be at least one, and it makes more sense to me to have it in the server, which is closer to the hardware, than in each client. The clients, or at least the huge libraries they use, have to have a lot of code to find out from the server what the hardware is like and what facilities it has. Why implement/duplicate all that?
You and I differ over "lightweight". Lightweight to me concerns the total amount of code involved in accomplishing something safely and correctly. Adding bloated stuff with its own untyped programming language is just plain wrong to me.
If X clients are communicating with the server via sockets, how on earth can they see what other clients are doing? They can likely infer a bit based on what the window manager tells them, but that's about it.
With a system using shared memory between the server and its clients, visibility is much higher, and it is that which I very strongly dislike.
Have you guessed that I have no need whatsoever for high performance games and fancy rendering?
More efficient than one set of "drawing commands" is to have no drawing commands at all. This is what practically every implementation uses these days - including X. The drawing commands for X11 were designed in the 1980s and seemed like a good idea at the time. Soon afterwards people started sending bitmaps instead of commands for performance reasons. And then there are all the various needs that software like electronic design tools and word processing want different commands. These days with DRI-interface all of the old X11 drawing is bypassed but it is still carried along to be able to say that the protocol is supported.
Another example are the fonts. Back when X emerged (with all the terminals and thin clients) it was though of as a good idea to have a font server. When personal computers were used the fonts were on the same computer so that wasn't needed. Instead, fontconfig appeared and clients choose what fonts they want to use directly. There's of course all kinds of fonts these days like OpenType, TrueType, PostScript etc. in addition to the X fonts and some use bitmaps and some use vectors and so on. So clients can pick the library they want to use and render the fonts with that instead of expection X server to have support for every case.
Having a single place to do everything (like a server) sounds good until people start to come with ideas of how they want to do things differently. And there are tons of different GUI toolkits that all want to draw in different ways.
The main reason why X11 did not shunt bitmaps around is because at the time, the network infrastructure would not support it. Back in the days of 10Mb/S CSMA/CD thinwire Ethernet, which is where X was developed, shunting large pixmaps around was a real no-no, as it tended to hog the network. The X protocol meant that you could send the graphics primitives between the client and the server in a way more network efficient manner than rendering the window locally, and blitting it across the network. It was an elegant solution for the time, and worked really well, enabling work between different OSs and different vendors.
Even the font handling, so criticised nowadays, was hugely more efficient, sending the glyph number rather than it's pixmap.
Things are different now, with switched Gb network, so it is actually possible to throw large pixmaps around. Whether it's the way I would want to go for a new client server model, I'm not sure, but it is possible.
The comment above about application and window separation is a valid one, however. The thing is that X11 defined a window hierarchy that allows one process to effectively insert itself between another application's window and it's parent, and see all events that happen in on the other window. This is how the X.org screen readers, collaborative screen sharing tools and other things like Xprobe work. All you needed was the ability to create a connection to the server, and the server itself was the mechanism for reading the other data.
There is quite limited security, and each application talking to the X server can traverse the tree of window hierarchies to see exactly what is being displayed by the X server. Look at the output of "xwininfo -tree -root" and "xprop -id id", I think that these between them allow you to see the entire tree and the full properties of a single window.
"it makes more sense to me to have it in the server, which is closer to the hardware, than in each client"
This makes no sense. Both the server and clients are running on "the hardware". Any program using a shared library (like for rendering) is using the same binary in RAM (hence the name). If you specifically mean using the GPU for rendering, or SIMD on the CPU, that has nothing to do with whether it's happening in a process called "the server" or "the client". The GPU doesn't care who asks it to draw a triangle.
"If X clients are communicating with the server via sockets, how on earth can they see what other clients are doing?"
They just ask the X server. It's happy to tell any client what anyone else is doing. X11 is perhaps the least secure system of all time. It makes telnet look like Fort Knox.
"They can likely infer a bit based on what the window manager tells them, but that's about it."
The window manager has no special privileges just because its process name ends in "wm". Anything that your window manager knows, all the other clients know just as easily, and through exactly the same channels. They don't have to ask the window manager to "infer" it.
"With a system using shared memory between the server and its clients, visibility is much higher, and it is that which I very strongly dislike."
X11 has been using XSHM since 1991. What do you mean by "visibility is much higher", and what is there to dislike about this? It's a huge performance boost for a relatively small increase in complexity -- it was worth it even back in 1991.
It sounds like you want worse performance and worse security, in favor of the principle of "lightweight" software, which you say means minimizing the "total amount of code". Why are you using a GUI at all? I didn't think FORTH required one, Chuck.
It made sense when the server and client were running on different pieces of hardware, with a piece of damp string linking them together.
Of course having both client and server on the same system meant that the X11 protocol running over sockets became a little bit of a bottleneck, but that is why they developed the shared-memory communication model, which still used the X11 protocol, but without the networking stack.
What it gives you is network transparency. It really did not matter what implemented it, X11 would run over any bi-directional datapath. This is the killer feature compared to Wayland. Things like waypipe are supposed to implement similar functionality, but does not feel like it's really mainstream yet. And not all platforms will get Wayland clients.
"XWayland is basically lightened X-server without the things that Wayland (sic) does, namely rendering"
If that were true, i'd expect an api-compatible library that simply stubbed out the rendering calls. Then you could run pretty much the same application level testing for both.
XWayland does support the X11 clients. The difference is that it isn't interfacing with the hardware, but it is simply Wayland-client.
So, you can use all the testing you use otherwise.
X11 was always a message-based protocol over sockets. So you can use the Xlib-library that sends the commands to Xwayland.
You never called X-server directly since it was supposed to be "network transparent" (in practice that required a lot of low-level code to do that but that was what user saw).
Wayland does the same thing: it is message-based but the protocol is different.
Why is the protocol different? Imagine you are switching to a modern locomotive (a train) from a coal-powered one: what can you re-use? Not a lot.
"most X-clients already use client-side drawing in their toolkits" - @ilpr - I'm willing to remain relatively neutral in the Wayland vs X argument as I have never used Wayland but also, I have never personally had any first-hand experience of an architectural limitation of X11 in over 20 years of using Solaris and Linux. However I do struggle with this 'modern' idea of client-side drawing.
The predominant GUI toolkits behind Linux applications are either GTK (GNOME) or Qt (KDE), and I believe that GTK has by far the majority share. You state that clients are already using client-side drawing but is this not because it's the way being enforced by GTK?! RedHat is massively invested in Wayland and is pushing GNOME towards Wayland supremacy but GNOME is based on the GTK library and so they have been steering GTK towards client-side drawing/decorations to achieve their own ends. I don't know where Qt stands on this basis but it sounds like it could be following a similar path. Thus I question whether 'most X-Clients' are really making a conscious choice to use client-side drawing or whether (as I suspect) they are being forced into this by the very same people with the Wayland agenda.
My focus is on user choice and particularly 'consistency' - Throughout my career it has always been the case until recent years, that any desktop system works in a consistent way - that is to say that the application menus, titles, buttons, scrollbars, etc typically appear in the same place and in the same style for all applications. Changing the Desktop's theme (be it a Linux environment, Windows or Mac) is reflected throughout all program windows.. Yet with client-side, we now have flat borderless applications which are often hard to distinguish from a neighbouring/overlapping window - there's a big focus on mobile/touch devices to the detriment of mouse+keyboard interface and every app potentially looks inconsistent from every other. The gap between how a 'modern' GNOME GTK application looks vs a modern Qt one could not be wider and now an increasing number of applications completely ignore the system theme. I hate this...
The worst part is that GNOME GTK has decided that their UI should spill out to anything build on the GTK library, which is just about everything - most notably all main stream web browsers. So now there is no escape. I use MATE Desktop but that has been infected with ugly CSD hamburgers and buttons inside grey titlebars which belong only in the GNOME Desktop Environment.... I know that XFCE has ended up embracing this despite being a traditional and minimal desktop.
If Wayland can work reliably without losing any key features from X then I'm going to be pretty agnostic about using it, but it is driving a much more sinister and practically irreversible change to the end user interface and I cannot accept this.
The ongoing divide between the classic do-one-thing and fashionable all-singing-all-dancing approaches continues. Personally, I am looking forward to the day that the dancers get out of my hair and leave the classic ecology clean and undisturbed. No doubt they cannot wait to see the back of us grumpy old gits.
I do wonder how long Devuan can continue building off a SystemD/Wayland/Pulseaudio/GNOME/etc-only ecology, before it has to fork irrevocably. That will be a sad day, but I guess it's inevitable sooner or later.
I'm trying to think of a situation where you'd be so heavily invested that a move to one of the BSDs wasn't possible and the only things I can think of are hardware support, because there are Linux drivers for pretty much everything; a heavy Docker/Kubernetes environment. For servers the differences are marginal and the BSDs consistency and stability would be a welcome change.
But as this isn't really my area, I'm interested to learn more.
The difficulty is that this rot is really wide spread throughout the stack.
When you consider a non-graphical server and stripping out things like SystemD there are probably enough alternative and actively maintained components that you can fairly easily swap them out and end up with a sane, stable system.
When you have a graphical application this will typically be based on a graphical toolkit rather than trying to implement its own GUI from scratch. There are various toolkit libraries out there but the most predominant one on Linux/UNIX platforms is GTK which underpins the GNOME desktop, followed by Qt (the main basis of KDE). What happens if RedHat/GNOME decides that the next version of GTK will not support X11?
This is a serious situation because right now all of the major Linux applications are built on one of those two libraries. LibreOffice and GIMP for example. But then the Web Browser market has now boiled down to either Firefox or one-of-many based on Chromium - Yes, there are a number of other browser projects but none of them come close to having full support for modern day webpages; so the sad reality is that if you've chosen a BSD for your desktop, you've managed to find drivers for your hardware and X.org is up and running with no Wayland anywhere to be seen. But then you need a decent web browser and if it turns out FireFox and Chromium/Chrome are based on GUI Libraries which have ditched support for X then you're going to be back to square one unless there's a community that is willing to create and maintain a forked version of the GUI and/or the Browser :-(
I'm not strictly against Wayland itself but I fear that the misguided crusade which is being led by those in the RedHat/GNOME/Weyland camp is going to have some very long-lasting detrimental effects on all Linux/UNIX/POSIX desktops.
Uhhhh...you're aware that Wayland is very much the "classic do-one-thing" approach, and X.org was very much "all-singing all-dancing", right? This is literally the biggest reason the people who develop and maintain *both*, no longer want to develop and maintain X.org.
There does seem to be a dirigiste strain running through the Gnome team.
Take for the example of the reduction in the utility of Nautilus. All in the name of simplifying the file manager. Or the imposition of Adwaita on Gnome users, no ifs no buts. So the devs handing down diktats on the use of Wayland despite reports that it is not a complete replacement for X does not come as a surprise
Still with Linux there are alternatives and if you piss off your users enough they have somewhere else to go. You can only push your luck to a certain degree and then people start to walk away.
We shall see.
It's not dirigiste, it's just a simple echo chamber.
It's what happens when you put management in charge of engineering decisions.
Personally, GNOME lost what little credibility it had left when they intentionally dropped all ties to GNU. They are trying to monetize the shit out of it, and we will all lose if we allow them to succeed. Shun GNOME, and those who sing its praises.
[Author here]
> So does this increase or decrease the likelihood of us seeing the year of the Linux desktop in our lifetimes?
Like I keep saying...
It was 2017. That's the year ChromeBooks outsold Macs for the first time.
Note, in $ in the USA. Given that the typical Mac/MacBook costs several thousand, and a ChromeBook several hundred, this means that was when ChromeBooks outsold Macs _a lot_.
A year or so later it was worldwide.
But exactly as you'd expect from the Linux folks, it's _the wrong kind of Linux_ so they don't count it.
Frankly, realistically, honestly, Linux is a server (and mobile) OS and the percentage of Linux boxes _on the desktop_ are tiny. It is funny though that when it finally made it, it was in commercial form. It's the only numbers anyone can measure but it looks like there are in the ballpark of 10x as many ChromeBooks as all other desktop Linuxes put together.
*Possibly* that is just outside China, though, where there may be as many again.
Why do these developers insist on removing functionality? Do they ever stoop so low as to talk to us mere users? Gnome only works okay with extensions, Wayland is obviously never going to have the missing functionality mentioned in this article and Nautilus has been crippled. I opted for Cinnamon a few years ago, first on Ubuntu, then LM, then Fedora and now LMDE 6. Other desktops seem less versatile and less refined.
This was my problem a few months ago.
The KDE desktop kept on crashing, so i lost work as the windows/program failed.
On another machine i was upgrading the system from the command line where it crashed, and i was not able to to get to a command line prompt from booting. Had to do a clean install.
Here is the problem reporting link i used :
https://retrace.fedoraproject.org/faf/reports/560635/
I have been using X11 since and no issues. The link shows that there are still issues with Wayland,
"Why do these developers insist on removing functionality?"
Because they're the ones doing the work, so they get to decide. It's pretty simple.
"I opted for Cinnamon a few years ago"
Good for you. The Cinnamon devs exercised their ability to choose to make a desktop that's different from GNOME, and you exercised your ability to choose it. So why on earth do you care what the developers of GNOME do? If you looked at a Ford car and a Toyota car and decided you liked the Toyota more, would you then come back years later and yell at Ford for not building a Toyota? Why? What would be the point?
Unfortunately GNOME doesn't exist in a vacuum, so the decisions made there do affect the rest of us, which is why people get disproportionately frustrated. Hamburger menus and client side decoration are now infesting previously sane distros. (Again, hamburger menus have their place, but I'd argue that a text editor is not such a place; client side decoration isn't a huge deal except that window appearance and behaviour is now inconsistent between old-style and new-style windows.)
I was reading something on the GIMP website recently about the work they put in to port the app to GTK3 (yes, 3) - it's somewhat depressing how much time and effort they had to expend creating their own replacements for now-missing functionality.
See title.
Until then I'll be on xfce.
(I could be moving in the future to a Chromebook/Gnomebook for wasting time on the Web and an air-gaped old Thinkpad with Slackware 14.2/gtk-2 applications like OpenOffice(*) for writing and stuff - [Slackware 14.2 is EoL 31st Dec by the way])
PS: the backwash of Gnome is of course the GTK libraries (and the QT libraries with KDE) together with the whole loginctl/dbus shenanigans. The *.bsd world will need to work with those unless they do a plan 9/suckless tools thing and head off in their own direction. Its the upstream dictating to the downstream.
Icon: for all those who toil in the fields of software.
* Yes, I know and I don't care.
I wouldn't care whether I was using Wayland or X if it wasn't that some really basic essential features in Wayland were still not working and if there weren't Wayland related bugs in things as simple as text editors (which would appear to be Gnome Wayland bugs).
I used Wayland by default with Ubuntu 22.04 until I got tired of having to log out and log back in with X whenever I needed to use an application which wasn't supported under Wayland. Now I just use X all the time and don't miss anything that Wayland supposedly offers.
I don't care about remote desktops. I don't care about multi-monitor support. I do care though about basic features which Wayland developers have acknowledged for many years as being something they needed to address but never seemed to get around to for no discernible reason.
I suspect that what will happen is that Gnome will follow their usual practice and just make Wayland non-negotiable whether it's ready or not. Then Fedora will adopt the new Gnome while nearly everyone else sticks with an older version of Gnome. Most application developers will go with the majority market share and do whatever most distros do, which will be to stick with an older version of Gnome.
Red Hat was able to ram Systemd and Pulse Audio down everyone's throats because they didn't affect most desktop users directly. For Wayland though, the deficiencies are serious enough to be absolute show stoppers for many people.
I've been using Devuan Linux for the last seven years or so
And FreeBSD..
Sadly, my virtualisation servers (Proxmox) *do* use systemd. And I've had several instances where I've had to reboot a node because I get a "timeout waiting for systemd" error trying to start or stop a VM.
Proxmox - *please* migrate off the bloatware that is systemd. It's (in my case) actively harmful to me using proxmox.
When I played around with Ubuntu, it ran XWayland in the background without me setting anything up. All the X11 clients I was using worked without me doing anything, with just a very small number of problems to do with some input events when the cursor was not in an X11 window (and I think warping the pointer didn't work either).
I found that very few applications on Ubuntu 22.04 are Wayland native. Most work through XWayland
I still tend to log in using X.org, but I decided I could work with Wayland and XWayland if I had to.
I updated a PI4 yesterday to RaspiOS bookworm and it now defaults to Wayland on PI 4's and higher.
It started up fine, but as I have the official RPI Touchscreen on that machine the touch didn't work.
In the end I had to disable a driver which then broke Wayland. I had to revert to Xorg to get a working machine with touch.
A lot of people keep pushing Wayland but to me it's nowhere near ready for a lot of people with specific usecases.
Answer 1) Because they like it?
Answer 2) Because it is what their corporate desktop uses?
Answer 3) Because it was default when they installed/were given the machine and it enables them to do stuff?
PS: Fedora 39 beta passes the legacy hardware test. Live iso will boot and run on a Thinkpad T61 (2008) with 2G ram, while running Gnome 45/Wayland, and I was able to run Firefox and LibreOffice Writer OK. But top was showing the OOM reaper hovering around the fifth or 6th line.
1) Because I like it.
Tried KDE and gave up - too cluttered and awkward to navigate. Cinnamon etc are (to me) basically Windows/Gnome2 environments.
Gnome in its current form does exactly what I want from a desktop.
I don't bang a drum for it, and it makes absolutely no difference to me if others prefer a different desktop. It's good that a choice exists.
I can live with Wayland and work around the issues that affect me (sharing a window rather than whole screen, and remote desktops in browser windows being 4 pixels out of alignment*)
So I stick with Ubuntu LTS versions. (I do find snaps irritating though.)
* Special case: AWS Appstream running RDP session in Firefox on a 175% scaled 28" monitor. Mouse clicks have to be 4-pixels right & down from the actual point on the screen)
"I don't bang a drum for it, and it makes absolutely no difference to me if others prefer a different desktop. It's good that a choice exists."
Excellent, that's the spirit. Linux should be 'a space of freedom'.
Alas the backwash of the decisions that the Gnome project makes affect a significant number of other projects. I suppose it is a case of "no project is an island" (especially if it publishes a popular graphical toolkit).
Sigh.
That's what Patrick Volkerding did in March 2005 when he removed the GNOME desktop from Slackware, it being a "moving target" that was too hard to follow for his small team. Removing the GNOME desktop, however, still leaves us with GNOME's GTK widget toolkit, that is being used all over the place, like in the XFCE desktop. They lost me when they incorporated GTK's client-side decorations in XFCE's dedicated window manager, fouling up existing applications. That's when I went back to my simple, well behaved window manager from back when: Blackbox. Let others frob with the Heath Robinson contraption / Rube Goldberg machine that is a desktop environment.
I use Nvidia GPUs because they are fast and stable. The GPU debugger provided is really really good.
I have a number of use cases that Wayland is never going to provide a solution for.
I need to start applications and reorder where the applications full screen rendering appears.
So a background application, then first video, second video as an insert then a partial overlay.
To do this I use xlib to find the window IDs and reorder the order. I capture keyboard & mouse events and redirect to the main app.
I can only do the above if I use window manager specific extensions under Wayland. Life is too short.
I'm running the video display as separate applications as I found that I get minimal latency of ~100ms per frame total, from camera capture, transmission, receipt, decode to display. Tying everything into a single app caused way too much complexity and resulted in higher latency and very inconsistent playback.
If you are using Linux for colour critical tasks (i.e. you need your display colour calibrated and profiled), then this is a sign that you may not be using Linux/GNOME for much longer. There is zero prospect of display colour calibration and profiling applications supporting Linux/Wayland in the foreseeable future.
Fedora 39 beta default gnome / wayland session on a Thinkpad L440 (2011, 8Gb, SSD and all)
https://askubuntu.com/questions/1097080/ubuntu-18-04-mouse-on-lenovo-thinkpad-x240-not-working-after-suspend-hibernate
Still the case that suspending and waking up results in no trackpad. Both on Xorg and wayland.
So like 30% of laptops will require some kind of script to be written and placed in a specific location just to get the track pad to work after you open the lid. And we are arguing about the subsystem that manages the graphic desktop?
JWZ may have had it correct. Google CADT.
Icon: old man waves his fist at the skies after expecting basics to just work.
Actually use Openbox these days but it appears to depend on some (i)gnome-ous stuff so it might be terminal too.
(Many) years ago I ran 9wm and 9menu (X11) but had to move to Oroborus I think when the Netscape browser wouldn't display its menus.
By the time I discovered Cwm my gray cells were too old to remember all the key sequences :( - not big on emacs either.)
9front might be suckless but when compared with an angry penguin or a wicked daemon their mascot which resembles demented if not homicidal bunny isn't a compelling advertisement.
The tactic worked, so Microsoft did it again, with the new .DOCX format in Office 2007… presumably realizing that its new "ribbon" UI would hinder adoption.
No, Microsoft was proposing a new DOC version for Office 2007, but was forced by several governments to switch to an "open" file format that would become OOXML, which is essentially an XML version of the previous BIFF one. Though it should also be recognised that Office 2007 and later did need a format to support some of the new features, such as much much bigger worksheets in Excel.
I think the Gnome fuckery is closer to Microsoft's fiddling around with APIs and desktop layouts in Windows, so MFC to .NET to whatever it is today. A royal PITA for a lot of developers.
As far as I am concerned Wayland will be ready under Linux the day it enables me to do everything I can already do with X, and at least as efficiently. Until then I have no use for Wayland. Now when is this going to happen? These people have been at it for over ten years already. Is it going to take another ten years?
Quite frankly, sometimes I wonder whether this Gnome/Wayland push is being subsidized by some entity with a vested interest in making sure that the global presence of Linux in the desktop remains negligible.
"This plan seems to The Reg's FOSS Desk to be strong-arming people into adopting Wayland. To us, it's reminiscent of the sort of moves proprietary software vendors execute to compel users to upgrade, such as file format changes."
Have you not used open-source before? They do this all the time, too. Linux itself has "fs/ext2" and "fs/ext4" -- ext and ext3 already having been removed. X11 has not been immune: it's right in the name! It's been through 10 incompatible upgrades. GNOME is primarily built on GTK4, which is incompatible with GTK3, GTK2, and GTK1. There's precious few software systems in this world, with any license, which never make incompatible upgrades.
"As an example, Microsoft has done it twice with Word alone. From MS Word 1.0 in 1983 up until Word 6 and the almost entirely cosmetic change of Word 95 in Office 95, it used one file format, called .DOC. Then, the buggy and troubled Word 97 brought in a new one, to muddy the waters still called .DOC, which remained until Office 2003. There was little new functionality in Office 97 aside from Outlook and, of course, the universally loved Office Assistant, by default the famous Clippy."
Typically, Microsoft is held up as an example of bad architecture surviving because of their obsession with backwards compatibility. Word never removed the ability to read old DOC files, did it? How is that remotely the same? You're just ragging on them for Clippy -- again. It's been 25 years. Get over it. It's not even the same people working at that company any more.
Do you realise just how long ago X10 transitioned to X11? It happened even before Linux was a thing. I started using X11 at X11R3 on AIX in 1989 (prior to that, I was using CLI based UNIXes), but I did see both X10 and X11R2 running on some old hardware.
The various releases of X11 were much more compatible. I'm not sure whether I still have anything around to try, but I would expect that X11R2 clients would still work with modern X servers, even with some of the things they've removed from the X.org server.
Wayland is just one more brick in the wall of "Why we hate Gnome". Having tried Gnome several times after it went bad, I go to sleep every night praying for its demise. The Gnome developers threw away every good thing it once had. Where do these people come from, and why do the distros favor it so heavily?
Exactly!
This is the same short-sighted, self-serving thinking by Gnome devs that has turned a well-loved desktop and toolkit into small cult offerings. Another solution in search of a problem that doesn't exists. There is no practical reason Gnome cannot continue to provide and support and Xorg compatibility. The '+' is definitely gone from GTK...
io_uring is getting more capable, and PREEMPT_RT is going mainstream The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
