Wayland takes the wheel as Red Hat bids farewell to X.org Red Hat reckons Wayland is now mature enough to take over as the only display server in the forthcoming RHEL 10. A blog post by Carlos Soriano Sanchez, head of the GPU team on RHEL, spells out news that doesn't come as a big surprise: the next version of Red Hat Enterprise Linux, expected in 2025, will drop X.org and will …
As an alternative to X11 and Wayland,p erhaps Apple could open-source Color Quickdraw? That ran in 256KB of ROM (one quarter of one megabyte) and had probably the best documentation ever, in the form of the "Inside Macintosh" series of manuals.
But no... people are too attached to their GPU-accelerated screensavers.
Apparently Weyland doesn't support screensavers.
(elReg writers should ask JWZ for quotes more often; he's got the CV, worked at Mozilla, main dev for XScreenSaver etc. and he always has an opinion that would spice up an otherwise boring article)
Different people have different requirements, the fact they may be quite niche does not negate this.
It's not inconceivable that you wish a system on lock to :
run one or more programs to achieve desired actions
show something specific (say status), alerts etc. If it's less mission critical, let people run their Johnny Castaway.
I do.
I've been compiling the latest xscreensaver on whatever happens to be my current Linux desktop since xscreensaver 1.14 ( I think, the one with nose guy added).
So far I've ran it on convex, sunos, Solaris, irix, whatever the Unix was on a Dec alpha and various Linux flavors.
It also runs on my iPhone but I haven't figured out how to get it to run automatically if
1) it's plugged in
2) not closed ( well the protective cover is not closed)
3) not horizontal
Which is all that I really care about.
I'd be up the proverbial creek without a paddle if it weren't for MATE but it drives me mad that RedHat's sabotage of Linux desktops has now leaked into lots of parts of MATE, e.g. the disk manager and "Simple Scan" which are GNOME applications and use client -side decorations and the horrendous buttons and hamburger menus that get embedded into the fat not-quite-a-title-bar
RedHat has wildly trashed a lifetime's worth of UI concepts and forced it onto just about everybody, removing all the flexible and user choice which we once had. So I'm at the point if thinking that even if Wayland offered me anything that X doesn't, it's got RedHat stamped all over it so I'm out.
MATE on the other hand is run by an awesome bunch of amazing people who continue to deliver worthwhile features and improvements. I really hope that a similarly amazing group of people and companies come together soon to stick two fingers up at RedHat and work either to keep X11 alive or implement something like the X12 idea with sufficient backward compatibility.
Meanwhile I'm going to figure out how to obtain the latest release under Ubuntu 20.04 to get new feature to disable mouse scrolling in the window selector and check out whether Pluma has any kind of automatic recovery yet.
Whilst Wayland basically works (for various definition of works) it's very sad that Wayland is so very obviously oriented towards commercial interests and Linux first, and X for all its many many faults generally worked cross platform and had agreed on some functionality that the vast majority of Xorg implementations feature.
This is written on a fanless FreeBSD system with built in basic Intel GPU running Wayland and the labwc compositor. Firefox works fine, as do OpenOffice, WINE, and various Wayland applications for the most part.
There are still many issues, largely down to the 'open' nature of Unix standards, and the Linux first (let's be honest : anything else very grudgingly considered) attitude to Wayland development.
labwc has an annoying 'snap to edge' feature if windows are placed in a particular position. There's probably a way around this, but even if I find it, it may be different on *every other compositor*.
labwc does feature various Wayland protocol enhancements. Other compositors do not, because even if they're based on a common compositor library, protocol updates in that library do not automatically flow through to updates in the compositor.
Leading from the above, you can't rely on something such a config file to position monitors on startup (as you can in Xorg) as it may not be supported by the compositor, and the syntax differs for each compositor that supports it. Once Wayland itself is fully running, a post startup script can call the protocol enhancement to move monitors, and that *is* compositor agnostic assuming the protocol is supported.
The reference Wayland compositor, Weston, IS LINUX ONLY. There's an old NetBSD port last time I looked, but the only up to date implementation is on Linux. The fact the reference compositor is not tested on a non Linux platform beggars belief.
It's still not clear to me how to position windows that use the overlay plane (such as clocks). I can start the programs, but then can't easily interact with them, because my compositor appears to have no built in support or documentation on this, it's not obvious via a search, and at that point I start to lose the will to live and just look at an actual physical clock instead.
17 years on, things like colour management are still not nailed down.
Driver support for older cards is lacking, particularly on Nvidia.
What it needs, and also what will never happen :
*ONE* compositor base that everything bolts on to. This must be a suitable base for all compositor addons from the largest commercial desktops to the smallest individual offering.
Cross platform first, or at the very least a way of gracefully handling a lack of functionality. If it doesn't built on Linux and BSD, it doesn't get released.
Development driven by design, not commercial interests. So Redhat/Canonical, or Nvidia/AMD/Intel can't move things towards 'oh, your graphics card is old, no support for you' [1]
As it is, things will coalesce around a small number of large desktop based compositors (i.e. GNOME), and any company with sense will insist on their open source supporting software running on : Linux (possibly x64 only), and GNOME Wayland. And nothing else. mmmmm open platforms, and choice. [2]
[1] To be fair this already happened multiple times in Xorg, it's just that most people didn't notice because drivers were re-written to support the new X interface (there are at least three I know of). However, Wayland seems potentially to offer a larger excuse and 'not all the drivers are open, and doing this costs money, so even though your card is easily capable of working with Wayland, it never will'.
[2] Also to be fair, this occurs with poorly written Xorg software also : 'what do you mean my function call to place an icon on the desktop or query desktop stuff is failing, because you're running a window manager with no desktop or icons'
"Driver support for older cards is lacking, particularly on Nvidia"
Not really the fault of Wayland to be fair. NVIDIA seems to have a deep seated hatred of playing on a level playing field. If something exists that supports any cards and their cards look bad on it, they won't support it or provide any compatibility for it.
Technically you're correct, but in this case it's not the best type of correct. If not Wayland, then who? It's yet another human problem where technically it's not the problem of a specific person, but if the community as a whole wants a thing to be a success, then they need to do it anyway.
Just like Microsoft was forced to write some drivers for hardware in versions of Windows where the driver model changed and the manufacturers refused to update the drivers, because the hardware was common and it would have led to bad publicity. The question of course is 'who pays'.
I may be off base here, but I don't think the open source community (and many others) are prepared to pay someone for the drudgery to make things like Wayland a success. A lot of it is thankless, irritating, difficult work that also requires significant co-ordination and people skills.
When Linux and BSD started out they had the advantage of being able to build upon years of compromise between Unix vendors. Now commercial Unix is largely dead, and new technologies are basically : Linux
Technically BSD works too, but this is only because the BSDs added sufficient compatibility layers so BSD looks enough like Linux to make porting drivers easier.
Compositors work on both Windows and Mac OS because Microsoft and Apple have paid several people enough money to code and test the infrastructure until it works and they can enforce their own standards. There's then a reliable infrastructure, generally driven by one large company, that everyone adapts around.
The same is happening in Linux, except it serves the interests of a couple of large commercial Linux vendors and is not oriented around the open source ethos. So what is resulting is technically called 'Linux', and things such as Wayland may technically be 'open source' and 'cross platform' but the reality is a long, long, way from the Unix ideals and intent in 1992.
If anyone has a more accurate view of the above, I'd appreciate some input.
I think the issue is that this is also exactly what some modern Linux users want : something free that is gradually becoming far closer to Windows than they're happy to admit, and damn anyone else.
"I think the issue is that this is also exactly what some modern Linux users want"
I think quite the opposite. All I want is for hardware vendors to allow support for open APIs rather than enforce their own proprietary bullshit on software developers. AMD, which is a vastly smaller business than NVIDIA contributes a lot to open source and open standards in general, as does Intel. Wayland works flawlessly on AMD cards...it does on Intel cards as well...but NVIDIA...nope!
NVIDIA just kinda looks fucking lazy or incompetent...I've got a pretty long memory, and it wasn't all that long ago that NVIDIA drivers were just crap in general. Not just on Linux.
The day NVIDIA gets knocked off it's perch is a decisive manner, is the day they will never come back...unless they change their ways and show consumers that they do in fact give a shit about something.
NVIDIA may make extremely performant kit, but the whole organisation...right up to that leather jacket wearing wanker...feels incredibly phony. I bet he can't wait to get that naff looking jacket off when his PR people aren't looking.
I'm always suspicious of CEOs that dress like peasants or truckers...because you know they've been told to dress like that for PR reasons, "it makes you seem more approachable / relatable / like you don't give a fuck etc etc...and if they can't decide how to dress themselves, how the fuck can they make any other decisions?
The last thing we need in a CEO is someone that isn't human that wants to appear human...because it weirdly makes them even less human.
Thanks for the reference back to the Unix Hater's Handbook! It serves as a salutory reminder that everything the current generation accepts and takes for granted is the product of generations of compromises, and that current standards weren't and aren't universally accepted or loved.
The entirety of the Handbook is well worth a read, both for entertainment and historical edification.
Plasma 6 dev version supports X and was stable with X first, but will default to Wayland.
Anyway 2025 seems like a good target in general. I've happily been using Wayland for a while but some folks are still awaiting a few features.
As for how long it has been in development I think it's worth mentioning that in the beginning there were almost no-one working on it, people working on compositors had other priorities and once work started it was a volunteer here and there. So it's not all those years of all-hands-on-deck. Development on more protocols (maybe at an overly careful pace) and compositors have accelerated super-linearly in the last few years. And then there's Nvidia who was at first unwilling to use standard Wayand protocols and then just took it very slowly (they do own a big chunk of the market).
It's not like a Microsoft project where the company would decide to do something and immediately assign complete teams of full time engineers in all impacted departments and coordinate their work.
"It's not like a Microsoft project where the company would decide to do something and immediately assign complete teams of full time engineers in all impacted departments and coordinate their work."
No, but it's exactly like a RedHat project where the company decides to do something and immediately assigns complete teams of full time engineers in all impacted departments and coordinate their work. See also GNOME and the systemd-cancer.
And just like GNOME and the systemd-cancer, the powers-that-be at RedHat have decreed from on high that Wayland is The One True Way Forward... despite actual technical folks with technical backgrounds explaining to them why it's not a very good idea from a technical standpoint. And those very same technical folks demonstrating time and time again that the kludge is not ready for prime time, and probably never will be.
And of course Canonical and Debian slurp it up (it's FREE!!!!! What more would Management want?) ... and all the wannabe distros follow along blindly. To do otherwise would mean actually thinking (and spending money), and we can't have that, now can we.
Canonical and Debian don't make decisions about default anything without thinking it through, and Debian definitely listens to technical people before implementing a thing as important as a display manager.
I'm yet to see a really coherent criticism of systemd. It has certainly made my life much easier.
"I'm yet to see a really coherent criticism of systemd."
Shall we start with the fact that its not housebroken, and leaves little piles of shit all over the filesystem?
Red Hat implemented the systemd-cancer to make their Linux Distribution more Windows-like, which should be a red flag to anyone with a clue. Debian followed along for internal political reasons, the tech involved had nothing to do with its implementation in that space. Another red flag. Most of the rest followed on blindly through ignorance and/or apathy, with a pinch of sheer laziness, because they use one of those two distro's repositories. In no example that I can find did a distribution choose the systemd-cancer because it is demonstrably a technologically better system. Not one. Think about that for a minute, and then ask yourself "Have I been had?".
There is a reason that an init, traditionally, is a small bit of code that does one thing very well. Like most of the rest of the *nix core utilities. All an init should do is start PID1, set run level, spawn a tty (or several), handle a graceful shutdown, and log all the above in plaintext to make troubleshooting as simplistic as possible. Anything else attached to this base is a vanity project that is best placed elsewhere, in it's own stand-alone code base.
Inventing a clusterfuck init variation that's so big and bulky that it needs to be called a "suite" is just asking for trouble. The systemd-cancer is b0rken by design and implementation.
If systemd had just stuck to replacing init and a nice set of "systemctl start/stop/restart" commands, with the ability to better define dependencies between services (which is what allowed replacing init's purely sequentially defined starting of services) then things would be fine. As it is it now contains random junk that attempts to replace system features. Even files like fstab which you'd think are separately handled are interpreted by systemd (and not usefully, we have one machine which still refuses to mount nfs shares on boot due to some issue with network availability, is it configured differently from the others? Not so far as anyone can tell).
systemd doesn't fit all use cases, but even leaving that aside the largest issue is not systemd the init system, it is systemd and its boatload of ancillary functions that aren't strictly init based.
Even that would not necessarily be an issue, but software is then written with dependencies on systemd based functionality - init based, or not. That then makes it unusable both under systems that do not wish to run any systemd, and inherently non portable - you know, the thing Unix was actually supposed to be considerate of.
I'm not personally completely anti systemd - the Linux I run (in a VM) is a systemd based distribution, simply because the non systemd distributions I tried where I wanted to enable and switch between open source and proprietary GPU drivers for PCI-e passthrough were so poorly documented[1] it was easier to use a systemd based distribution with decent documentation. I also have Ubuntu distributions, and if I was running Linux as a main platform I'd probably make an effort to get the non systemd based Salix working again.
[1] This is sadly because WINE under FreeBSD is a little lacking, although it's rapidly getting there. If something fails I need to know if it's an application problem, a WINE problem, or a WINE on FreeBSD issue. Linux is of course the first class WINE citizen here to be compare against.
The problems I have are that for the remainder of my working life, I expect to be using 'legacy' UNIX systems (and I can't see me cross training into Cloud technologies at my time in life). It's just not going to happen that someone like IBM will implement Wayland capable clients on AIX, so windowing will remain X11 for the rest of the life of these systems, not that many people use graphical applications on AIX (I still do, but I'm regarded as 'odd' by my colleagues)
The transition to Wayland will further push AIX (and the remaining life of Solaris, HP/UX and Digital UNIX however long/short these will be) into the same category of text only OS that mainframes have bee relegated to. Implementing X12 with it's inability to do byte-swap won't help with AIX on Power, because although modern Power Linux implementations can take advantage of the configurable endianness of modern Power processors, I really doubt there will be a little-endian version of AIX, even though the remaining supported Power hardware for AIX is now bi-endian.
My one consolation is that XWayland is likely to exist for a few years more as the transition happens, and by the end of that, I hope I won't care as I won't be working with legacy UNIX any more, bringing an end to a 40+ year career of UNIX as my way of earning a crust!
If I was more of a programmer than I am, I may have joined the efforts to keep X.org going, but I fear that my coding skills are too old and too rusty for me to be much help.
Still using X on my Fedora desktop due to desktop incompatibilities and difficulties with QHD display. Tried to get the default Wayland to work, failed, changed back to X. Killing simple remote application running (x forwarding *and* x2go) is another genius move. Are they fixed yet? Maybe, sadly I've been hearing for years "not a priority" or "not a use case" and I've stopped expecting it to ever work, or the developers to ever be interested in the features their users need.
Middle mouse paste, another thing they removed and were refusing to implement, looks like it is now there (the similarity to Gnome changes that were forced on users as "good for us" for a couple of releases before they changed their minds has not passed me by), does it use a primary buffer (last selected text)? Who knows without installing and trying? It's certainly not documented anywhere, see for example Gnome discussion from 2015 https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection, which is long out of date but still pretty much the top search result for this. (But preserves the lovely gnomeism of describing something they don't want to do as an "easter egg". Hey guys, document things properly and they aren't easter eggs, but that's probably too difficult.)
Currently looking forward to whatever replaces wayland. Back in the late 200x-es we got a nice view of what the future of linux desktops might be like in Compiz, and then spent the next decade or so going backwards while they chased single user Macbook functionality.
And there's the problem - all the issues and the lack of features should have been ironed out by now.
Over now to my favorite quote from elsewhere:
"You failed to read the fine print at the bottom of all the wayland promises over the past 12 years:
"It will improve your performance. Next year. Or the year after that. Or maybe the year after that. If you have the right hardware. And the right desktop. On certain tasks with certain apps. Maybe. Depends on the alignment of the stars and the moon, and if Jupiter is in the 2nd house"."
These days companies simply cannot ignore accessibility legislation, one can get into a lot of trouble if you do. From what I’ve heard Wayland tosses all the accessibility challenges over to the app developers, not the desktop environment.
If Wayland based Linux really is unsuited to those needing help, then that practically guarantees that it can’t be offered to an employee. That ensures that there won’t ever again be anything like a large corporation / city council that is going to be willing to adopt a Linux desktop. Which condemns Linux to remain obscure…
I use LMDE 6 and X is the default and will remain so for at least 2 years, and that's fine. It does the job very well and Wayland simply isn't up to par yet. Red Hat is jumping the gun because they want to *force* developers to develop for Wayland, faster. I can't see any other reason why you'd do this when X already works fine for the majority. If Nvidia is the reason, F Nvidia. They are hostile to FOSS anyway so let Linux users get rid of their nvidia cards and get AMD instead. Tell nvidia using your wallet, that they need to support FOSS or lose money.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
