I was initially excited for wayland, and was an early adopter.
I soon soured on the entire thing. It's very clear to me that wayland was an 'ivory tower' display server that had little respect for users or wm devs. You can't just go and break tons of things for security's sake when the harm is clearly higher than the benefits. Disabling screen and input capture should have been an 'opt in' feature for the truly paranoid. They should have also shipped a fully working bare bones desktop wm instead of a 'toy' implementation meant to run on a car entertainment center.
Frankly I can't believe it got as much traction as it has, but we're all stuck with it now as it's clearly 'the future'. This and systemd really showed me that the linux ecosystem is far more vulnerable to the interests of a few corporate sponsored devs than the general community.
To be fair they just make applications go through an API now, known as a desktop portal. This is done to allow the user to control which applications can capture or control their screen or input, like Windows and MacOS.
Allowing any application to do that without the user knowing, the X11 model, is a recipe for disaster. With the right exploit chain you could theoretically deploy a keylogger from a website.
Now sure, Wayland didn't have all of this from the start, but it wasn't the default for most distros until all of these things were in place. You opted to use Wayland before it was ready for general consumption.
>Allowing any application to do that without the user knowing, the X11 model, is a recipe for disaster.
I don't know a single person that has ever fallen victim to a virus or malware on linux, and I've been using it almost exclusively for the past 20 years. If it was a threat vector, it clearly wasn't a very big issue.
If they wanted to not break existing apps, simply intercept attempts to share screens or inputs, and pop up a dialog box asking the user for consent? That would have been fine. That should have been a part of their default implementation. What they actually wound up doing was infinitely more user hostile.
I tried using it summer of '22. The wayland hype train was well underway and major linux distributions were already pushing it. I'd be much more forgiving if the wayland devs said 'hey guys, we're working on a new display server but it's very experimental and no one should use it unless they want to help us work out the kinks'. Instead, it was 'this is the future, x11 is abandonware'
> I don't know a single person that has ever fallen victim to a virus or malware on linux, and I've been using it almost exclusively for the past 20 years. If it was a threat vector, it clearly wasn't a very big issue.
Do you think the same would have applied to Android, had it used X11 instead of SurfaceFlinger (which in turn isn't very different from Wayland)?
Even if no virus cares about the Linux desktop, that doesn't mean that security issues should be ignored.
>I don't know a single person that has ever fallen victim to a virus or malware on linux, and I've been using it almost exclusively for the past 20 years. If it was a threat vector, it clearly wasn't a very big issue.
So: no true Linux user succumbs to malware and no true Scotsman puts sugar on his porridge.
Putting that aside, it doesn't take much effort to find an example of X11 keylogger that requires zero superuser privilege and zero explicit permission granting by the user. Here, the first result from DDGing "x11 keylogger": https://github.com/anko/xkbcat
It is hard to believe this has not occurred in the wild. If such attack really hasn't occurred before in the Linux world, I would rather use the unpopularity of Linux desktop as my justification.
> I don't know a single person that has ever fallen victim to a virus or malware on linux, and I've been using it almost exclusively for the past 20 years. If it was a threat vector, it clearly wasn't a very big issue.
Yes, well, the ground is being prepared to turn desktop Linux into a Android/Windows like app system (/ wasteland) where users mostly download third party proprietary apps and devs push updates directly to users with minimal oversight.
In this brave new world, you will definitely appreciate app isolation.
> If it was a threat vector, it clearly wasn't a very big issue.
By the same token, patching the apps to use the new API is not a very big issue either. Or is it? Why?
If you have the sources, neither is a problem. If you do not have sources, both are problem. A matter of fact is, that users are going to use apps that they do not have sources for, and can neither audit, nor update the apps.
> If they wanted to not break existing apps, simply intercept attempts to share screens or inputs, and pop up a dialog box asking the user for consent?
Because there was no API before; there were hacks. Some of them worked only due to circumstances of how the given functionality was implemented, but spec-wise, it wasn't guaranteed at all.
Now there are APIs. Just like there is a virtual memory or filesystem permissions. These weren't given years ago either. They also "broke" apps.
> major linux distributions were already pushing it.
RHEL8 is Wayland-default on non-Nvidia GPUs. Old relase of a freaking RHEL, which itself moves as molases.
> I'd be much more forgiving if the wayland devs said 'hey guys, we're working on a new display server but it's very experimental and no one should use it unless they want to help us work out the kinks'.
You missed that phase by some 10 years or so.
> Instead, it was 'this is the future, x11 is abandonware'
That's how it is. If linux wants to stay relevant and not became another Amiga, that's how it is going to be.
xdg-desktop-portal is a workaround for the chaos Wayland caused. It puts the implementation burden on all of the individual "compositors" (read desktop environments) individually, resulting in many times the work, many incomplete and many incompatible implementations.
The Wayland devs hyped their project up like it's going to be the thing to replace X11, but ended up delivering barely 10% of what X11 is.
One of the beautiful things about Linux was that you had thing huge variety of desktop environments and the reason for it was that X11 gave you all the infrastructure, you only had to do the user-facing parts. Now, a DE needs to implement all of X11 and then some to be feature-complete.
And no, I'm not accidentally mixing up DEs and compositors - the reality is that we don't have a good "base compositor" that DEs could build on top of. The big players built their own compositors and the small players either died or used wlroots, which again doesn't implement most of the essential things (and the ones it does are incompatible with KDE and GNOME).
>One of the beautiful things about Linux was that you had thing huge variety of desktop environments and the reason for it was that X11 gave you all the infrastructure, you only had to do the user-facing parts.
Why do people like to emphasize this point so much? You still get shared infrastructure in the Wayland ecosystem by utilizing libraries such as wlroots or Smithay.
In fact, GNOME and KDE are practically the _outliers_ of the ecosystem as they do their own thing, but other compositors such as Hyprland or Sway do share the same core.
If you want even higher level of abstraction so that you can make your own window manager in one hundred lines of code, you can opt to write a Wayfire plugin. It's as close to having a "base compositor" as possible.
GNOME and KDE definitely are the outliers, but they are the biggest players and they didn't do this out of sheer evil or whatever. They did this because when everyone was pushing for Wayland adoption, wlroots didn't exist or wasn't usable. And when it came out, everyone called it a "reference implementation" and it was expected of DEs to implement their own compositors.
And the main problem wasn't even that DEs didn't have a shared codebase for compositors, it was that there weren't any standards for critical features of any modern system. It was all "up to the compositors", meaning it wasn't just a matter of implementing some APIs, they had to be designed first. We now have different protocol extensions for KDE and wlroots alongside external DBus-based APIs for GNOME that have now also been partially implemented by KDE, yet there are still basic X11 features that can't be done on all of these compositors.
> And when it came out, everyone called it a "reference implementation" and it was expected of DEs to implement their own compositors.
Small correction, it is Weston that was a reference implementation. Weston was developed alongside the standard, so it's always been around. Whereas wlroots is very much supposed to be a practical implementation, but only came later.
The general Linux community is just fine with systemd. It works, and works well. It is only a minority (albeit vocal) of users who are actually upset about systemd.
Indeed, and many of us who have spent extensive time writing data center automation prefer it to the way things used to be.
* Config files and startup behavior are all in the same format; outputters for name daemons, cron jobs, networking, name resolution, NTP, coredumps, mountpoints, and more are all the same. Hand it a data structure with the proper keys and you know it's going to work.
* cgroup and namespace configuration are much more fine grained, flexible, and straightforward than docker. Have a weird vendor service that you'd like to restrict or isolate? you can do that.
* Process management is mostly a solved problem after years of being ignored by POSIX.
* Accounting metrics on memory, tasks, and I/O is for all your services is there
* Shipping to syslog is a breeze.
Yeah, it's got a learning curve but it's objectively better than a bunch of random init scripts. Which you can still use.
* You get real honest-to-god dependency solving, no more having to number scripts so they run in the right order or working with magic comments.
* .targets are the correct abstraction over runlevels that do what people actually need them to do.
* How journald manages disk finally fixes the stupidity of logrotate edgecases.
* sysusers/tmpfiles is by far by far the best way to manage non-human users and application specific directories.
* The entire system is programmable in real programming languages without having to shell out to system("systemctl start ..."). The whole thing is dbus-first and systemctl is just a client to it like any other.
* You can make your own unit types with systemd-generators if the built-in ones aren't enough for you.
* The system for overrides finally solves the package management bullshit where the init script and the package manager fight.
* Built-in userspace oom killer.
* Makes user sessions a real thing on Linux instead of an ad-hoc set of conventions.
* sd-notify for service readyness checks is fantastic
I love systemd, I just hate journald. Their built-in pager sucks (text flowing off the screen by default, really?), and logging in binary was a mistake. It doesn't integrate nicely into any of the tools I would normally use. tail in particular is pain in the ass because I have to wait for journalctl to convert the entire log back to text.
Logs are text, tools that work on logs expect text, and I don't give a crap that my logs are 50% smaller or whatever. Disk space is absurdly cheap, and logs are a minority of my disk usage.
I know it can forward to syslog, but at that point I'd rather just have syslog.
systemd is fantastic, though. I've just been building a new system and having to deal with journald is a big pain in the butt.
From the log producing side, journald is much better than log files. No one wants to manually configure log rotation for each daemon individually (What signal does this daemon use to reopen its log file shudder). With systemd you just log to stdout+stderr and are done.
I'm often both the producer and consumer though, and the consumer side is painful enough I tend to avoid journald.
From the producer side, I typically use a logging library/extension that handles its own log rotation and doesn't require logrotate. It's a half-dozen lines of code or so, not too onerous.
They could have at least not re-invented the wheel: perhaps use SQLite (or OpenLDAP's LMDB) instead of DIYing it.
> The gory story begins with their journald discussion, here http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/69... where they rationalize why they created their own data structure rather than using an existing embedded DB. Aside from their claim that nothing suitable existed being wrong (LMDB belies those claims) the fact is the solution they developed is inherently unreliable https://bugs.freedesktop.org/show_bug.cgi?id=64116 which utterly invalidates their claimed attention to robustness.
Their current database is still dramatically slower than log files. Waiting for journalctl to produce logs is consistently the slowest part of me working with my logs.
It's just a silly use of a database. I could probably count on my fingers the number of times I wanted non-sequential log records, and that's the only time I can see a database beating log files. Even if I want non-sequential records, Linux has a plethora of tools to manipulate and query plain text that everyone already knows. I would much rather use grep or awk or another tool I know than learn whatever arcane query syntax journalctl supports.
Nevertheless, the point of software freedom is freedom. I'm not upset about systemd as long as I have other choices.
It's the tendency of systemd users to say "shut up, you don't count, you're just a minority and you don't have anything real to complain about" and otherwise forcefully evangelize for their favorite paperclip maximizer that irks me.
What's so hard about init scripts ? Since few years peoples are literally demonizing them, ROFL.
"Maintaining" that few lines of shell code that start/stop/check some program is incomparable to mainatining source code so can't be serious reason for demanding of removing them from existence.
And from that little scripts you literally know everything about starting/stopping managed program. Compare this to systemd undocumented, buggy and not working as expected "configs" :>>
Of course it's possible to make mess with scripts. But you can't manage to mess script so badly it becomes so monstrous as systemd :)
And you realy can't include so many CVEs as systemd introduced - that brain-dead not-a-init moved init process to ranks of sendmail and bind... Well done ? Works for me ? Minorities only problem ?
Unixes have this nasty property that forking new processes tends to inherit all the attributes of the parent process, and shell scripts are really good at making sure all the attributes are passed by default unless you bitch and complain and try really hard to not do so. Things like signal masks or environment variables, etc.
If you wanted a system where a service you're setting up runs differently because it was invoked by init on startup versus invoked by someone over an ssh session versus invoked by a different user over an ssh session versus someone running in a terminal in an X session, well, init scripts are a great way to do that. If you think such a system is horrific for debugging purposes and should be avoided at all costs, you're going to start by avoiding shell like the plague. (Also, shell is just an atrocious language for most tasks.)
But you can do all that above. You can split onto separate parts when needed. You can start small and grow your scripts. You can comfortably replace them. You can do everything you have rights to.
Good luck debugging, fixing and splitting or just modifing or twiking systemd implementation :)
So what deserve bigger "avoiding like the plague" ? Possibility or not possibility ?
The first problem is you can only write a shell script to be defensive about the things you know about. Do you personally know which environment variables need to be reset to their default value for your service to work correctly?
The next problem is that there's actually some inheritable process state you can't manage with shell builtins. Combine that with the above, and it really makes sense for you to have a utility that knows how to spawn a service in a pristine, controlled environment.
While we're working on that pristine, controlled environment tool, we should also reflect on the fact that process management in Linux is a real complicated bitch. Simple is invariably neither robust nor correct. If we've already got a utility to help us write a services, we might as well extend it to be able to help with detecting stuff like "is this service still actually running or did it somehow fart itself and die?"
Of course, once you have this tool, you look back at your new init script and realize that all of the work you have to do is now in this tool, so why should you have to bother with boilerplate in a defective-by-default language [1]?
> Good luck debugging, fixing and splitting or just modifing or twiking systemd implementation :)
I've had more issues debugging init scripts than I have with systemd stuff. I actually find debugging easier with systemd... it actually tells me when things go haywire!
[1] Try having directories with spaces in their name with shell and see how often you get tripped up by it!
Maybe, maybe it can be done in some way, whatever 'it' is.
> you can only write a shell script to be defensive about the things you know about
And that is a problem strictly unique to shell scripting ? :) With systemd you know ? Or pick one arbitrary thing and just deny other possibilities ? Of course you deny (you as in the systemd implementer / beliver / user), as has been seen many many times. Suddenly usecase has been changed ! And maybe now you can do that with scripts even better then with systemd ? :)
> inheritable process state you can't manage with shell builtins
Is "builtins" a key world here ? Becouse shell scripts are quite literaly about using not build in pieces :)
> spawn a service in a pristine, controlled environment.
See ? Use case changed. It is no longer "user" or "other user", nor ssh or console or interactive, nor txt or X or W... Use case refactoring :) You can rething how to script it to not loss functionality.
Oh, wait... It's systemd ! Functionality loss is a motto there :) But scripts need to handle orginal usecase, for PR reasons :)
> process management in Linux is a real complicated bitch
nixes are complex. Lastly Linux have even more namespaces, contexts, etc. And you know what ? Systemd do not helped to make it simpler. Just wrapped some of them, badly (context v1 for years!) into internals and hijacked development of sane and modern system utilities.
> Simple is invariably neither robust nor correct.
Luckily we talking shell scripting here :) Becouse any system utility can be used. And they can be combined even ! Shocking ! ;)
> If we've already got a utility to help us write a services, we might as well extend it to be able to help with detecting stuff
Valid use case. Had been done ages ago. In modular fassion. With possibility of replacing monitoring part into other implementation. Can be even started from init.d script :)
> "is this service still actually running or did it somehow fart itself and die?"
And this is working on systemd ? :) Working better then in other service managers ? How systemd detect such conditions that other managers can't do that ? :) And why systemd display that not-funny messages of waiting for service to do something ? And permamently halting system halt ? And making my screen / tmux not working ? :)
> > Good luck debugging, fixing and splitting or just modifing or twiking systemd implementation :)
> I've had more issues debugging init scripts than I have with systemd stuff.
I have more problems with systemd configs then I had with using init.d scripts - they are just like command line(s), sequencial execution, easy to debug by just
looking on them and checking system / app state. And usually it's not script problem but something with app. How systemd can improve on that ? By blackboxing managing service ? :)
> I actually find debugging easier with systemd...
Maybe. But just wait systemd will make debugging effort poinless by changing systemd behavior :)
But you missed something: with pure scripts or simpler managers you know everything* about system you are running. With systemd you don't - you introduce additional complication. And constant CVEs stream. How that is easier to debug ?
> defective-by-default language / directories with spaces in their name
On contrary, *nix shell scripts are perfect for work they are doing - batching commands you type into pack for re-execution. Tested commands that work as expected. And "spaces" problem is solved. Do tar or cpio in script have problem with directories with spaces ? Do ls, find and others have options for better separating things ? Do shell allow '""' usage ?
Thing about scripts is that you are supouse to stop using them when usecase is more complicated. This is counted as +1 for scripts and +1 for init.d usage (and -1 for systemd monitic monster). Scripts work is just to be agregators for fast and clear development eg. for start / stop / check helpers that you copy / paste almoust literally. Just like configs in systemd :)
Edit:
Btw. Hey, I don't specially like init.d - it works, is simple, extendable, replacable in few hours, etc, etc. Just systemd is such monstrous insanity...
> And that is a problem strictly unique to shell scripting ? :) With systemd you know ? Or pick one arbitrary thing and just deny other possibilities ?
If I run /etc/init.d/foo start to start a service, the service is forked from my current shell and therefore inherits everything from the shell. If I instead run service foo start, the tool instead sends a message to PID 1 process to fork the service, inheriting everything from PID 1. At that point, anything that can be changed could only have been changed by systemd itself, so if systemd doesn't know about something, then it can only be in the default state.
> And "spaces" problem is solved.
No, it's not. Write a shell script that reads a shell command (that contains quoted arguments with spaces in them!) from a file, appends some extra arguments to that command, and runs that command. The only way I could get that working was to go through Python instead.
> If I run /etc/init.d/foo start [...] inherits everything from the shell
'su' and 'env' helped a lot all that decades. Until everyone started using sodo passwordless :)
> If I instead run service foo start, the tool instead sends a message to PID 1 process to fork the service, inheriting everything from PID 1
Wait, you just want clean service ? I thinked usecase need to recognize how it is started and react to that ! But ok, send a signal 9 and inittabzerod will fork it with inheriting everything from pid 1 :)
> > And "spaces" problem is solved
> No, it's not
Ok, it isn't :) They even rewrote git in C to use file descriptors instead of text paths. But moustly it is becouse it is a very known problem with decades of solutions already implemented in common tools.
> Write a shell script that reads a shell command (that contains quoted arguments with spaces in them!) from a file, appends some extra arguments to that command, and runs that command
So: do shell meta programming in shell ?? :) That's clear abuse becouse shell is not general purpose programming language.
And how you do just that with systemd ? :)
But if you want some editable template file then oneliner in sed or awk or perl or ... with some structure will do. No need for introducing CVEs with new and soon to be rewriten or removed or abandoned parser somewhere in milions of lines.
That's fine and all but systemd is a real-life example of if you actually offer someone a "The Right Thing" solution that takes all of their hard problems, swallows the complexity of them and presents a simple interface with the right abstractions people will choose it overwhelmingly over alternatives.
I couldn't care less about design-by-ideology when I'm paid to design correct systems.
I've used both systemv and systemd professionally. They both have flaws. I have had fewer issues with systemd(albeit I have a system that rarely doesn't start up its target program after a restart, but it's managed so it's not a problem and just gets a manual start). Individual experiences may vary obviously but overall your comment supports the GP assertion of a vocal minority.
Others may not vocalise the issues, to which I believe happens to more people than those who do vocalise the matter, doesn't mean it's works well. It works at best.
> […] but overall your comment supports the GP assertion of a vocal minority.
Is it possible to tell the difference between a demographic minority of people who are (all/largely) vocal, and a demographic majority of which only a small number are vocal?
Generally people like to complain; if everyone says something is bad, usually it is, and if most people aren't complaining, but consistent voices do, then it's an indicator of individual rather than widespread issues.
> Disabling screen and input capture should have been an 'opt in' feature for the truly paranoid.
You can do screen captures on wayland. I've seen tools that were used to share a mouse and a keyboard to multiple computers kvm like that supported wayland so input capture seems to be possible to me.
My only gripe with wayland is that we seems to be lacking a common top level interface that is compatible with any compositor. Right now if some feature is not managed by the toolkit's wayland backend, devs need to have to implement compatibility with gnome's mutter, wlroots based compositor and kwin independently which doesn't seem to be a sane way of doing things. I wish all projects would converge into a common library like wlroots.
You can, now, but it's still not up to the level of polish that we had in x11, and nearly all of these are janky workarounds to a self inflicted problem
>I wish all projects would converge into a common library like wlroots.
They could also converge to a single display server implementation and the display server can interface with a separate window manager which could be swapped out.
If the X11-and-Wayland maintainers had put X11 up for adoption that might not have been the case.
That is, they might have said "We're looking for new maintainers for X11. They will be responsible for its future direction, representing X11's interests to the kernel and to distributions, and deciding when (and if) X11 is to be declared deprecated."
As far as I can make out, what they did instead was say "We're looking for people to fix bugs in X11, but they won't get to make any nontrivial decisions."
Anyone is welcome to contribute. You still can I you feel so inclined[1].
Contributions have never been discouraged, but no one wants to work on xserver. Remember, this is a 20 year old codebase. With all the cruft and dark corners you would expect and more.
According to [0] there have been several releases in the last 10 years.
Including one in 2021 that added variable refresh rate and touchpad gesture support.
On the output side: Mixed-DPI displays. HDR/wide color gamuts/LUTs/color management. Non-rectangle workspaces, or workspaces with no absolute coordinate systems (think headsets).
On the input side: touch gestures recognized as touch gestures, not as mouse emulation.
On both: hotplug of all input/output devices. Headless sessions and handover of sessions between console and headless, both directions. Reliable lock screen, even if popup menu is showing ;).
At some point you will have to either start building it for yourself or get someone to build it for you (when distros drop it from their repos). And that will become harder and harder as time goes by. Just recently apps I was building using Tauri stopped working on Xband forced me to switch to the Wayland Gnome session (on Debian testing) permanently. This will become more and more common, until it becomes untenable.
Building X is probably going to be trivial going into the future, yeah. Building and running future apps written for the Wayland will be a different beast though.
Just like there is XWayland today to make it possible to use a Wayland system with X apps, there are already similar solutions to run Wayland apps on an X system.
If you run `cage`, it will run a Wayland application in its own sandboxed window while the rest of the system runs X.
Similarly; if you run `sway` under X for example, it will start the window manager in its own window, and you can run Wayland applications inside it.
I've been using Wayland for years at this point, and it works fine, and has continued working fine. When I switched, which again was years ago, it handled several things I cared about much better than Xorg. Try using multiple monitors of different DPIs on Xorg, it sucks.
> x11 has seen no development for 10 years. Staying on it for forever is not viable.
Erm, what ?
Are you sure ?
Why it is X starting without a mouse now ? It has not done it 10 years ago ? Why do i need a gazilion of font libraries now ? Why were the default fonts changed ? Why is Mesa a hard dependency now ?
> Packard is responsible for many X extensions and technical papers on X. He has been heavily involved in the development of X since the late 1980s as a member of the MIT X Consortium, XFree86 and the X.Org Foundation.
> we’ve decided to remove Xorg server and other X servers (except Xwayland) from RHEL 10 and the following releases. Xwayland should be able to handle most X11 clients that won’t immediately be ported to Wayland, and if needed, our customers will be able to stay on RHEL 9 for its full life cycle while resolving the specifics needed for transitioning
Ugh, "...that won't be immediately ported..." sounds like they want to get rid of XWayland too at one point. Why don't they simply accept that some programs will never be ported to native Wayland APIs since Wayland implementations don't offer required features for some types of programs (like universal support for rendering consistent window decorations). With XWayland, X11 is just another client-side window system API, why not simply support that forever and why should it matter for application developers what happens below the X11 API shim? Especially since it is more feature complete and much less hassle than writing code directly against Wayland APIs?
You could speculate on the wording, but there is currently no such plan to drop Xwayland in the upstream Xorg project. In fact, one of the maintainers seems to be enthusiastic about continuing to maintain it for a very long time, now that the workload won't be eaten up by xserver (https://ajaxnwnk.blogspot.com/2020/10/on-abandoning-x-server...)
> Ugh, "...that won't be immediately ported..." sounds like they want to get rid of XWayland too at one point.
Astronaut 2: Always did.
Keeping the jank of X11 around was never long-term viable. One day you will have to either switch to Wayland-capable apps or sandbox whatever last version of Xwayland is out there to keep whatever old app you have going.
> Keeping the jank of X11 around was never long-term viable
Ha, it’s like saying “keeping the jank of win32, directx, GDI was never long-term viable” as your one and only argument for the inevitable success of Windows RT.
It can't be much more than a thin "translation layer" on top of Wayland similar to how xcb or xlib are two different flavours of the same thing right? The most important feature of XWayland is that it knows how to render the window chrome so that it looks consistent with other apps.
It's basically all of Xorg except the low-level graphics card driver bits. Xorg tracks a lot of state, there is no "thin wrapper" for that chonky protocol.
Ok then I have another grand idea: a system-level libwayland dynamic link library which eases the pain of using the native Wayland APIs.
No stupid code-generated headers, no extension mess, just a plain and simple widget-framework-agnostic C API in a single header and library to create a window with a titlebar and resizing handles (which needs to look the same as other windows on that system, no matter if Gnome, KDE or anything else is used), a hook for receiving input events, programmatic control over window position and size, being able to switch between fullscreen and windowed mode and being able to query the display DPI and refresh rate (that's the super-luxus requirements list which would make that API better than most alternatives including X11).
Basically enough window system glue to create a window for housing a GL or Vulkan context, but nothing more.
If this library existed and would be guaranteed to exist on each and every desktop Linux installation, I would switch in 30 minutes (it shouldn't take longer to port my code over).
TL;DR: I don't care about the technical details on why X11 is better or worse than Wayland. I only know that X11 provides the required features for my use case, but Wayland doesn't (which is mainly: not having to deal with rendering window chrome that's consistent with the rest of the system, and without having to bring a widget framework like Qt or GTK into the mix - which doesn't make sense if all I need is a 3D rendering context spanning the entire window client area).
> Basically enough window system glue to create a window for housing a GL or Vulkan context, but nothing more.
It called Gtk.
To get that on Windows, you link against user32.dll just to be able to call CreateWindowEx (and have no control, what it drags into your process). On macOS, you link against Cocoa.framework to get NSWindow. Why would be Linux any different?
Just because you have transparent low-level access to display server does not mean, that you have to use it and then complain, that higher level constructs are not available. Windows won't allow you to talk directly over ipc to dwn. Neither will Apple.
To display a fully-functioning window decorations, you need widget library (what do you think popup menus are?). So if you want to spend your life creating a library, that proxies to some configured widget library just for decorations, for those who refuse to use the right layer in the stack, be my guest. If you are not willing to do that, why do you expect others to do it for you?
Does GTK give me KDE's window decorations when running on a KDE desktop or does it look "alien"? Does every Linux desktop setup that runs Wayland have GTK libs installed? Last I checked these were the main show stoppers when linking against a specific widget framework on Linux. There's no least common system standard like on Windows or macOS (X11 was that standard, but oh well...)
> Does GTK give me KDE's window decorations when running on a KDE desktop or does it look "alien"?
No. Just like Win32 or Cocoa doesn't draw foreign chrome, neither does Gtk. Apps are free to draw whatever they want, and many do, like Firefox, Chrome or MS Office.
> Does every Linux desktop setup that runs Wayland have GTK libs installed?
I have yet to see any relevant linux distribution, that comes with display server (not just wayland) and doesn't ship with Gtk.
> Last I checked these were the main show stoppers when linking against a specific widget framework on Linux.
These are not show stoppers; they are subjective preferences. They are also demanding something from Linux that they do not demand from other systems.
> There's no least common system standard like on Windows or macOS (X11 was that standard, but oh well...)
It is, you just chose to ignore it (going full circle; it is called Gtk). You are free to ignore it, but it comes with a price. Complaining about the price without putting in an effort to change it according to these subjective preferences won't get anybody too far.
Can SDL2 render proper client side decorations on Wayland by now that look identical with the rest of the system? Last I checked it couldn't because libdecor couldn't. But googling again it looks like libdecor has special GTK support since quite recently, so maybe the problem has actually been solved (I would be surprised though, because nothing else in the Wayland ecosystem seems to "just work").
Awesome, this might be just what I needed! I need to run vscode and it seems to be possible if you launch it with --enable-features=UseOzonePlatform --ozone-platform=wayland . I'll play around with it the next days, thanks!
RDP as a protocol does support remoting just apps (RAIL: Remote Application Integrated Locally, or RemoteApps).
However, for Wayland compositors, this is a distant future; right now, Mutter supports connecting to existing, already running session (desktop). Ability create a new session over RDP is in the works. Everything else is after that.
Last time I tried to use Wayland on my NVidia laptop it didn't work well, both with the proprietary driver and with Noveau. I can't remember the details and I have too many open apps to logout and try again now. I switched back to Xorg and forgot about it. It was January this year, Debian 11.
I had weird flickering and micro screen freezes with my 2070 on Arch using Wayland on my new desktop build 3 weeks ago. Switching to Xorg fixed everything.
I use X11 as opposed to Wayland with my Ubuntu desktop. One reason is that if I open a Gnome terminal and start to expand or shrink its size, a tooltip appears showing its size as I am modifying it. IIRC, wayland does not do this, out of the box any how. I remember that there are other things that break for me as well, but I can't recall them off the top of my head.
> Xwayland should be able to handle most X11 clients that won’t immediately be ported to Wayland, and if needed, our customers will be able to stay on RHEL 9...
For such a drastic change a "should" it's not enough.
since when is a change which had been incoming for 10+ years drastic?
plus the huge majority of software doesn't directly communicate with either X or Wayland, but instead with some GUI library which does that for them. Which means that instead of porting thousands of applications you need to port a handful of relevant GUI libraries and any software which is keept up to date will "just work".
Sure when it comes to some "desktop environment utilities" and similar that won't work, but for most of them there are Wayland compatible ports or alternatives.
Also each (major) version for RHEL is supported for many years which means that going in 2 versions through deprecation and removal isn't drastic at all either (RHEL 9 is planned to be "supported" for roughly another 8 years, through mostly security fixes and similar at some point in a few years).
Shifting to Wayland hasn't been incoming since the project never meant to support everything X did. It follows directly that it never could, if you care about supporting all your users and all their uses.
I'm not sure how to properly response to your comment without it sounding mean because it's pretty much nonsense.
Wayland from the beginning was meant to replace X and this was pushed from a lot of sides, including some of the core developers of X at that point in time. So it had been very clear, from the get to go, that X will go and be gone sooner or later. That was clear like 10 years or so ago!
Anything wayland didn't support pretty much falls into one of three categories:
- its a security issue, so it was meant to be removed and would have been removed from X if that would have been viable
- it's somewhat broken and not really properly supported by X either with there being alternative better working approaches (e.g. the whole network transparency thing)
- it's not yet supported by wayland, but wayland is designed with extensibility in mind and there is since years a standard group which is standardizing additional wayland protocols and basically stating what any implementation should support. By now the large majority of gaps are filled and it has become often more a question of weather or not the wayland implementation you use has implemented it yet then weather it's supported per-se. Most times that's not too much of an issues but if you are on a distribution which mainly ships outdated software versions or on some niche mostly hobby project wayland implementations that can be an issue.
There are some minor exceptions to that 3 categories (e.g. wrt. certain front rendering things) but they in the larger picture don't matter and normal have alternatives in the 3rd category.
> if you care about supporting all your users and all their uses.
No one does support all users. Or at least no one who doesn't hypocritically claims things they can't long term commit too does.
You always should support the majority of users. If you have contributing users with a bias for them. But going from that to all isn't possible without stopping any changes and outside of some (but not even all) bug fixes stopping development. But that would kill your software sooner or later. Times change and resources are limited. What was acceptable security wise 20 years ago today can land you in prison for negligence (well legal troubles then prison, it's a metaphor). Similar requirements change, In the past supporting keyboard is enough, then mouse today controllers and drawing pans and in at most 20 years proper touch support is essential. This means your codebase needs to be changeable, maintainable and secure enough for the resources the maintainers have available. For X non of this was the case and some of the problems where of fundamental architectural nature. So that X needs to die was known even before wayland was a think.
I mean if I buy a new car I make it fit my current and coming requirements and if just because it means I can't help some friend of mine with moving something as much as I could before doesn't mean it's not a replacement, because in the end what matter the most is what the person who pays for the car and maintains it needs, not what a friend who doesn't contribute anything to it would prefer it to be.
> So it had been very clear, from the get to go, that X will go and be gone sooner or later.
It was more like a rant that X sucks and some people are building the best thing since sliced bread.
The only thing that i noticed is that, since around one year ago, they are pronoting it as as finished product, while some people complain that basic things are still not implemented.
The previous poster didn't say "Wayland wasn't meant to replace X", they said "Wayland was never meant to support everything X did". These are very different things.
You're responding to something that was never claimed. "It's nonsense that Wayland doesn't support everything X11 did" and "Wayland doesn't support this for these reasons" is pretty contradictory.
Your argument is misleading using the pretense of using logical deduction to argue that something that isn't 100% backward compatible can't be expected to replace something else.
Seems more like a silly excuse to me as this argument is not based at all in reality but pure ideological delusion. Something I assume you know very well as people commenting on HN normally have a bit of experience with software development/administration.
Wayland has been the default on Fedora and Arch w/ GNOME since around 2018, 5 years ago. It became the default on Debian w/ GNOME in 2019, 4 years ago.
RHEL 9 defaults to Wayland: the X server is available, but the admin must explicitly choose it, and most admins never do. So describing this as a drastic change is a bit hyperbolic.
How many RHEL paying customers rely on anything which won't run under XWayland, though?
I detest Wayland. I'll stay on X for years to come (heck, I've just started writing an X window manager). But I'm not sure this will matter to the typical target customer of RHEL.
2. RHEL linux has queried their customers, especially their largest ones and that doesn't seem to be a major issue
3. RHEL care mainly about their (paying) customers. But some of the most common things which will never work on Wayland are highly customized desktop environments and tools around them. I.e. use-cases somewhat irrelevant for the use-cases RHEL is sold to. For the the things which their customer do care for (e.g. HDR) RHEL made sure that they are supported by wayland, at least for the setups RHEL cares for (i.e. mainly GNOME, KDE in the versions shipped with RHEL 10, maybe already RHEL 9.x with a high enough x, as well as maybe some special cases, but they probably care not that much about anything wlroots based).
3. most things run on XWayland, and XWayland is also improved on so some things which didn't run initially do so by now or start using a newer version of Qt/Gtk/etc. at which point they run on Wayland.
Recreational Bugs talk [1989] by "Sgt." David Rosenthal (author of the ICCCM, developer of the Andrew Window Manager, X10, X11, and NeWS, employee #4 and chief scientist at Nvidia, and an old friend of mine):
One of the fundamental design goals of X was to separate the window manager from the window server. “Mechanism, not policy” was the mantra. That is, the X server provided a mechanism for drawing on the screen and managing windows, but did not implement a particular policy for human-computer interaction. While this might have seemed like a good idea at the time (especially if you are in a research community, experimenting with different approaches for solving the human-computer interaction problem), it can create a veritable user interface Tower of Babel.
If you sit down at a friend’s Macintosh, with its single mouse button, you can use it with no problems. If you sit down at a friend’s Windows box, with two buttons, you can use it, again with no problems. But just try making sense of a friend’s X terminal: three buttons, each one programmed a different way to perform a different function on each different day of the week — and that’s before you consider combinations like control-left-button, shift-right-button, control-shift-meta-middle-button, and so on. Things are not much better from the programmer’s point of view.
As a result, one of the most amazing pieces of literature to come out of the X Consortium is the “Inter Client Communication Conventions Manual,” more fondly known as the “ICCCM”, “Ice Cubed,” or “I39L” (short for “I, 39 letters, L”). It describes protocols that X clients must use to communicate with each other via the X server, including diverse topics like window management, selections, keyboard and colormap focus, and session management. In short, it tries to cover everything the X designers forgot and tries to fix everything they got wrong. But it was too late — by the time ICCCM was published, people were already writing window managers and toolkits, so each new version of the ICCCM was forced to bend over backwards to be backward compatible with the mistakes of the past.
The ICCCM is unbelievably dense, it must be followed to the last letter, and it still doesn’t work. ICCCM compliance is one of the most complex ordeals of implementing X toolkits, window managers, and even simple applications. It’s so difficult, that many of the benefits just aren’t worth the hassle of compliance. And when one program doesn’t comply, it screws up other programs. This is the reason cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text), drag-and-drop locks up the system, colormaps flash wildly and are never installed at the right time, keyboard focus lags behind the cursor, keys go to the wrong window, and deleting a popup window can quit the whole application. If you want to write an interoperable ICCCM compliant application, you have to crossbar test it with every other application, and with all possible window managers, and then plead with the vendors to fix their problems in the next release.
In summary, ICCCM is a technological disaster: a toxic waste dump of broken protocols, backward compatibility nightmares, complex nonsolutions to obsolete nonproblems, a twisted mass of scabs and scar tissue intended to cover up the moral and intellectual depravity of the industry’s standard naked emperor.
Using these toolkits is like trying to make a bookshelf out of mashed potatoes.
In practice this matters for some people and not to others. My wm so far largely ignores the ICCCM and will never implement most of it. I have no reason to (heck, I haven't read all of it, and have no plans to - I've read parts and may apply parts, though some parts I'll just take mild inspiration from).
The previous WM I used (I now use my ~7 day old WM; dog-fooding a piece of software which may or may not restart is fun, but with a little bit of care I haven't "lost" any open windows since the Reparenting Disaster Of Last Wednesday) was bspwm which certainly is not compliant either. And that's fine.
What I have in few hundred lines works well enough for my needs, and already does some things closer to how I want them than bspwm (bspwm is great; I have odd expectations)
I don't want my machine to work like a friends. I want it to work in the way that best suits me. Nobody else is going to use it - and thanks to smart phones there is less need than ever to let anyone. I don't need a lot of applications to run - a terminal (my own), a file manager (my own), an editor (my own, and running in the terminal), a browser, and image viewer and a PDF viewer add up to pretty much everything I run that isn't a web app or on the command line.
But Wayland doesn't fix the described mess. By deferring nearly everything to extensions, it has fragmented the space far more than X wms ever did. The level of boilerplate to talk to a Wayland compositor makes an X client look trivial (you can of course, and should, use a toolkit if trying to talk to Wayland; with X it's a lot closer to optional, at least if you only care about running on modern servers where you can insist on expecting XRender and the availability of an RGBA visual it guarantees and pretend the rest doesn't exist)
Then again, as I said, to RHEL customers that probably doesn't matter. They're not going to be likely to be anarchic places full of not quite interoperable diverse window managers. For them Wayland is probably fine. Or rather a specific Wayland compositor and a curated set off apps known to work with it will likely be fine.
(As always I love your historical links and quotes, though)
I love your dedication to customizing your own environment!
I'm frustrated that Wayland doesn't support all the good ideas (and avoid all the bad ideas) of X-Windows or NeWS, and doesn't even have a built-in extension language like emacs and web browsers do. (What were they even thinking, not making it extensible at runtime? That everybody would want to compile their own server to customize it in C? Or that they'd solved all possible problems perfectly and there would be no need for customization?)
I always thought X window managers put the cart before the donkey: the client starts first, then the window manager reactivally wraps it in a generic frame.
Instead, window managers should be more like HyperCard, where users can wysiwyg build and script their own stacks that frame and compose and integrate one or more clients together (or none, for fully server side stacks like the clock or drawing editor): the stacks come first, and they start up and pull in whatever clients they want to frame and integrate and even script.
Of course you should just be able to run any client and it gets assigned a generic frame, but the user can edit both the generic frame prototype in the warehouse, edit and add scripts and message handlers, and customize any existing frame, including adding more pages (with tabs) and widgets and clients, and save them out to use later, restore all your windows after you reboot, add them to the warehouse, trade them with friends, etc.
Users can easily customize and script their own window frames (stacks), and add or edit the look and feel of gui widgets like resize corners, buttons , tabs, and pie menus, and even high level components like drawing editors (great for property sheets that let you edit the graphics and colors and layouts of the gui, clock faces and hands, or graphics you can cut and paste between clients), so they can script and integrate together multiple clients to customize them for particular tasks and workflows.
OpenDoc and CyberDog were barking up the right tree, but they didn't have a ubiquitous scripting language that you could use to both integrate and implement components.
Sun's HotJava browser was also a step in the right direction, but it did not include a Java interpreter or the Java compiler written in Java (which was written by Arthur van Hoff who earlier wrote HyperLook for NeWS), so it didn't have runtime scripting like HyperCard had with HyperTalk.
Later at Marimba, Arthur implemented Bongo, which did include and invoke the Java compiler and dynamic linker at runtime, so you could interactively write and run scripts and message handlers. (IDEs do this all the time now, but it was unprecedented for Java at the time, and Arthur knew how to pull it off, because he'd written the compiler.)
At UMD I wrote an X10 window manager scriptable in FORTH (by linking in the C "uwm" X10 window manager that I'd implemented pie menus for, and rewriting its main loop in Mitch Bradley's Sun FORTH, so I could fling windows around and they would animate bouncing around the screen with FORTH tasks), and used it to perform and measure controlled experiments comparing pie and liner menus.
And at Sun we wrote an integrated X11 and NeWS window manager for X11/NeWS in PostScript (three of them actually, but the last one "owm" was the best), which could manage X11 windows much better than X11 could (plus it was easily extensible, with tabbed windows, pie menus, rooms, scrolling virtual desktop, shaped windows, and was more responsive and didn't let input events fall through the cracks when you changed focus). And we also planned on making a much more advanced window manager with HyperLook (like HyperCard in PostScript), before Sun pulled the rug out from under us.
>And we had a lot of internal discussion about how NeWS fit into Sun's window system strategy. We developed a prototype X11 window manager in NeWS, to prove how much better NeWS can handle seamlessly integrated NeWS and X window management much better than X can manage its own windows. The next step we wanted to take was to write a user-extensible HyperCard-like window manager using HyperNeWS/HyperLook. But Sun management wasn't having it. They actually wanted to do the worst-possible upside-down solution and put NeWS applications inside of X-Windows managed by OLWM, precluding the possibility of arbitrarily shaped windows, tabbed windows, pie menus, all stuff we'd been doing for years with NeWS that we'd have to give up in the name of X interoperability, after we'd already proven we had a working better solution with "owm".
Those are some great ideas that dovetail together in powerful ways! Thanks you for sharing your work in progress.
In the hopes of inspiring you and others, here's a kind of messy draft of an article I haven't completely finished, but it's all about HyperLook (a user-editable desktop GUI system inspired by HyperCard and implemented in NeWS PostScript) and some components and applications I developed with it, like SimCity, a cellular automata machine, pie menus, a customizable clock editor, a customizable window manager, and "Happy Tool":
SimCity, Cellular Automata, and Happy Tool for HyperLook (nee HyperNeWS (nee GoodNeWS))
HyperLook was like HyperCard for NeWS, with PostScript graphics and scripting plus networking. Here are three unique and wacky examples that plug together to show what HyperNeWS was all about, and where we could go in the future!
Some years ago, Simon discussed some of the problems with Wayland that made it impossible to implement all the features of Gnome-Pie. I don't know how much Wayland has progressed to address those problems since then, but he's moved onto developing cross platform pie menus with Kando - An Open Source, Cross-Platform Pie Menu, to reach the much wider audience of Windows and Mac users as well as Linux.
It baffles me that the Wayland compositor wasn't designed from the ground up in the first place around a scripting language like JavaScript (or PostScript even ;). It's not like the idea was a secret or patented, and it seems to work well for emacs and web browsers. Then it would have been much easier to address all those problems and implement much more flexible powerful and efficient window managers, pie menus, tabbed windows, etc. And then maybe Wayland wouldn't be so limited, and would have already fully taken over from X11 decades ago.
Wayland – in it’s current state – makes applications such as Gnome-Pie hardly possible. Due to security concerns, applications are much more isolated. There is a good summary on the cairo-dock forums.
No client side window placement: Application cannot position their windows. How shall we open the Pie beneath the cursor? The only way I can think of is to open a transparent full screen window and draw Gnome-Pie at the pointer location. Sadly, this is not possible either: Only as soon as the user moves the pointer over the window, we can get the pointer location. I see no chance in getting this information more early. That means that we simply do not know were the mouse is when we open the full screen window. Hence, Pies can be opened at the center of the screen only.
No global input grabbing: Another reason for the full screen window is, that input capturing is impossible. This is the only possibility to close Gnome-Pie when the user clicks outside the activation radius. The full screen window makes the whole thing much slower and may lead to unwanted side effects such as auto-hiding panels.
No global key bindings: Applications cannot intercept keyboard or mouse events anymore. While this seems reasonable in the context of security concerns, it limits the usefulness of Gnome-Pie drastically. The only possibility is to open Pies with the terminal command gnome-pie --open <ID of your Pie>. Of course, this command can be bound to global hot keys of your desktop shell (as can be seen in the screen shot above), assigned to hot corners, etc. However, there is no way to support the turbo mode and delayed activation mode Gnome-Pie features on X11.
No mouse pointer warping: It is impossible for an application to manipulate the position of the mouse pointer. Therefore it is impossible to warp the pointer to the center of the Pie.
No client side window management: This is something for the desktop shell. There is possibility for a client application to get a list of opened windows. Therefore something like the window list slice group (Alt-Tab) is not possible. Maybe there will be an interface in future? Gnome-Pie uses wnck which is specific to X11.
No sending of fake keyboard events: This is a very useful action type for pie slices. In addition, this is required for deferred pie activation.
The conclusion
Hopefully this can be improved in future, however a lot of security decisions have been made during the development of Wayland which make applications like Gnome-Pie basically impossible. If there are no large scale changes in Wayland, I see bad future for Gnome-Pie.
If someone knows solutions for some of these problems please help making Gnome-Pie useful on Wayland!
OpenPie!
With the advent of Wayland Gnome-Pie will slowly die. OpenPie is my new concept for bringing (pie-) menus to the Linux desktop. In this post I will give a motivation and describe the planned software architecture.
Gnome-Pie will die.
On Wayland, there are at least six major issues which make applications such as Gnome-Pie basically impossible. I have described these issues in one of my previous posts in more detail - here they are listed again:
No client side window placement - Menus cannot be opened at cursor location
No global input grabbing - When a menu is opened, you will still be able to Alt-Tab to another application, etc.
No global key bindings - No global hot-keys from within Gnome-Pie. Only cumbersome configuration in your window manager
No mouse pointer warping - Leads to problems when menus are opened close to screen edges
No client side application management - No Alt-Tab window list features
No sending fake keyboard events - No simulated key strokes or deferred activation anymore
Kando will be a pie menu for the desktop. It will be highly customizable and will allow you to create your own menus and actions. For instance, you can use it to control your music player, to open your favorite websites or to simulate shortcuts. It will be available for Windows, Linux and maybe macOS.
The Vision
I am the developer of Fly-Pie, which is a similar project but limited to the GNOME desktop. I have been working on Fly-Pie for more than 3 years now and I am very happy with the result. However, I have always wanted to create a similar application for the desktop in general. This is why I started this project.
Kando is very similar to Fly-Pie in terms of interaction and appearance. At the same time, there will be some major differences. You can read more in this blog post!
Wow, this is going to keep me busy for a while. Thanks.
> I always thought the way X window managers worked put the cart before the donkey: the client starts first, then the window manager wraps it in a generic frame.
I agree, the reparenting stuff is painful and not very clean. Doubly so because you need to be very careful not to "lose" windows that way if you reparent the window and the wm dies (it happened to me once, I promptly put my reparenting code aside and decided that's for later, if ever, since I mainly use nearly no frame at all anyway; it'd be nice if the server just reparented the window back to root if the wm fails catastrophically...).
Some recent wm's like Katriawm[1] avoids reparenting even when drawing window chrome by instead carefully putting windows around the client window, which is more robust against catastrophic failure but it just feels icky to have to create multiple windows that you need to move separately whenever moving or resizing the client window.
> Instead, they should be more like HyperCard, where the user can build their own stacks that frame and compose and integrate multiple windows together: the stacks come first, and start up and pull in the clients they want to integrate.
bspwm kinda, sorta allows something like this if you squint just right, and via a private API by letting you define slots that will "swallow" windows that match the right WM_CLASS, but it's really awkward, requiring a bunch of API calls to define placeholder "receptacles" and then defining rules for which windows will end up in them. There's an "add-on" for bspwm that provides a number of layouts [3], which looks quite decent. But having a nice, clean way for applications to easily do that would be great. I guess you could hack your way around it without needing the WM to be particularly helpful thanks to X's lax security, but it's not very satisfactory.
The main reason I decided to toy with my own anyway (apart from what must be a masochist streak) is that I use a very tiny subset of bspwm's functionality and like how that works, but also want to be able to more easily mix in floating windows when/where I want, and bspwm isn't great with that (it supports floating windows, but getting it to handle apps opening new windows in floating mode is a pain. We'll see how soon I regret this decison :)
[2] My "todo" desktop consists of tree panes, a todo list on the left, and a "done" list on the upper right and a "notes" list on the lowe right. Each is a terminal window running an editor. To do that with bspwm I had to basically do all of this ($D was set to the selector for the desktop I wanted to put it on) before even opening the terminals. It felt decidedly clumsy, but it worked.
bspc node $D:/ -k # Kill any pre-existing windows on that node
bspc node $D: -i # Insert a "receptacle"
bspc node $D:/ -p east -i # Preselect the right hand side and insert a receptacle
bspc node $D:/2 -p south -i # Preselect the bottom and insert a acceptable
bspc rule -a todo-todo node=$D:/1 # If the class is todo-todo, assign it to node /1 on the relevant desktop
bspc rule -a todo-done node=$D:/2/1 # todo-done assigned to /2/1
bspc rule -a todo-notes node=$D:/2/2 # todo-notes assigned to /2/2
A good stress test is to try adding a parameter to your window manager that lets you specify the window id to use as the root window, and pass it xcalc's client window id! Then you can totally customize your calculator!
I prototyped a way of adding tabs and pie menus to Mac windows, by making a full screen web browser overlay with a transparent background, and just implementing and drawing the tabs and pie menus in JavaScript and html! The tabs even intercepted events properly. It monitored the window positions and other stuff through various Mac system and accessibility apis, so it would move the tab to follow the window, so they might become detatched and lag a bit, so it wasn't perfect.
I wrote more about that (why not just run a web browser directly on the hardware, and dispense with X11 or Wayland entirely?) and some thoughts on Wayland in general here:
Honestly I kind of assumed that was the future direction, especially with their work on rootful xwayland - I'm surprised that they didn't emphasize that path forward.
Edit: Though I do feel obligated to say that
> Today, Wayland has been recognized as the de-facto windowing and display infrastructure solution.
Is... optimistic. It has been called that, usually by people busy explaining why your use case isn't valid and shut up already about Wayland's shortcomings, but that's not quite the same as it being true.
RHES is looking at their (potential) paying customers, not Linux in general.
And a lot of that are in a context where there are many further restrictions to what can be run and how thinks can be setup. For example software whitelists and/or multi device administration where you are not admin on you desktop system. This for example means that for them most windows managers which are not GNOME/KDE did never matter for them at all (and just to be clear most means most, there are some exceptions). And XWayland is also still around in RHEL10 which mean the only problem are applications which 1. for their customers matter, 2. do not work correctly with XWayland, 3. can not be ported to a newer version of their GUI framework which supports Wayland. Which let's be honest aren't that many to begin with and mainly was stuff like e.g. missing HDR support for certain VFX use cases and similar, whist has been fixed by now.
So for RHEL this isn't "optimistic" but very realistic and based on facts derived from studies done with their customers, not some "busy people".
I really struggle to read "the de-facto windowing and display infrastructure solution" as "for our super narrow usecases" rather than a very general claim. Though yes, if that's the meaning then it's much easier to defend; if RH knows that none of their customers need an actual raw Xorg server without xwayland, then it's really easy for them to say that they can drop Xorg proper.
I personally would not call it super narrow or even narrow.
Sure it's non end user, but non end user desktop Linux is not as narrow as it might seem. Through it's not well represented on HN I think.
Most important both GNOME and KDE have embraced Wayland as the de-facto standard with their latest/upcoming versions and when it comes to commercial Linux desktop usage outside of some special cases only GNOME and KDE matter (and all the special cases I currently can come up with also use Wayland, but that might be due to my limited knowledge about special cases).
Other DE are nice and fun but in relevant amounts I'm only seeing them on privately managed (but not necessary privately owned and used) desktops.
>> Today, Wayland has been recognized as the de-facto windowing and display infrastructure solution.
> Is... optimistic.
Is it? Wayland is largely developed by the old X developers. They’re the ones who say Wayland is the future and there is nothing else. Xorg hasn’t been under real active development for a very long time.
The people in the best place to decide decided. They’ve been fixing the remaining issues.
There is no path forward for Xorg. It won’t get better. Only Wayland has a future.
> There is no path forward for Xorg. It won’t get better. Only Wayland has a future.
Well nobody tell the folks shipping new features[0]; I'd hate for them to realize. That said, as an active user, I don't really need X to get better, I just need it to keep working until either Wayland actually catches up, or everyone moves on to the next thing and that manages feature parity.
> Wayland is largely developed by the old X developers. They’re the ones who say Wayland
That doesn't mean it's any good. Or that they're right.
"The people in the best place to decide decided" is a hugely fallacious argument. You can say that about any controversial change to anything and dismiss any argument out of hand with that.
I’m going to assume they know better than random people do. Simply because they have the experience.
But thats not all I was really trying to get. Also: that there are no major Xorg developers left. All the ones that knew that weird massive codebase moved over to Wayland.
If a whole bunch of developers wanted to pick up Xorg and fix its issues and move it forward (no one has yet) they have a very very deep hole to dig himself out of it just understanding how everything that’s there works and how fragile it is.
I have used awesome for >10 years now, and the way awesome does multi-monitor support has grown into me. No other WM, wayland or X11, has offered it.
I am upset not because of X "deprecation" (still not convinced it will happen, hopeful it won't), but rather that I will, again, need to invest time and energy into something that had worked just fine for more than a decade.
I believe nvidia gave up on their EGLStreams-only vision and implemented GBM a couple years ago. Granted, this likely doesn't cover all of their hardware, but nouveau has made some big leaps since the nvidia open source release, and I expect that trend will only continue.
Yeah, good point. CUDA doesn't depend on the display server anyway. But not sure if it's possible to have Nvidia's kernel module and nouveau enabled at the same time. I remember one was disabling another in the past explicitly.
Sorry, about Wayland, I thought it still has some disadvantages and also still not widely supported such as VNC related things? Could anyone enlighten me?
Mine giving some details? Never used RHEL for GUI apps, servers mostly (well, Centos), why it's goodbye, what kind of blocker it will be for your team and corporate IT staff?
> we’ve decided to remove Xorg server and other X servers (except Xwayland) from RHEL 10 and the following releases
Isn't RHEL supposed to be the distro that gives you long-term support and stability for things? Why are they committing to remove X before Wayland gets full feature parity with it?
This is starting to feel like the arguments against systemd all over again. A few highly vocal people hate it, but it works just fine for almost everybody else.
As someone who has been working on porting a desktop environment to Wayland for the past year or so, I don't hate Wayland, but I certainly don't love it. After 10-15 years, it still seems pretty half-baked. Some pretty fundamental-feeling protocols have been languishing as merge requests on git.freedesktop.org, some for 3+ years at this point. I get that you don't want to rush standardization of things that need to remain stable and backward-compatible for (hopefully) decades), but c'mon, this is getting to be a bit much.
At this point I cannot actually replicate Xfce feature-for-feature in Wayland, not without inventing private protocols of my own, which I'd prefer not to do. My biggest issue right now is xfce4-panel, and embedding surfaces from one process into a parent process. There's no Wayland way to do this, and the Wayland folks have explicitly rejected some sort of XEMBED-workalike Wayland protocol, instead telling people they should write an embedded Wayland compositor. Well, I've been working on that for the past eight months, and it's hard to get right. I have something that "works", but it has a lot of rough edges, and, critically, eventually either the parent app or embedded apps run into weird spurious protocol errors and quit. While yes, that's technically my fault and my bugs, working with an under-documented protocol and really bare-bones libraries for building apps (wlroots, sadly, is not suitable for writing an embedded compositor, as it does too much) doesn't make any of this easier. I've written more than 10k lines of code (so far), and, meanwhile, you can do an XEMBED implementation in a few hundred.
I get that X11 made certain things impossible. But why not build an "X12" rather than throwing everything out and staring completely from scratch? It seems like people just didn't feel like it, and building something new was more exciting and would look better on their resume. I of all people know it's not cool to tell people what open source software to build in their spare time (though, to be fair, many/most of the people involved in Wayland are employed or at least funded by corporations), but jeez, this has been exhausting.
I think an X12 would be amazing. Incorporate some features from the open-source version of NoMachine NX to make network transparency work better over the internet with high latency. Incorporate some better security mechanisms.
With the world moving ever more again towards distributed computing (Like Windows desktop in the cloud which you can rent now from Microsoft) it would be amazing if each window on my computer could run on a different physical computer. I could run my 3D Design program on a heavy instance somewhere, my browser on a medium instance (and sandboxed), and some smaller programs locally. X11 can do all that today (and it could in 1995!) but it's not very good at it due to the latency sensitivity introduced by the many roundtrips in the protocol. Wayland can't because it's really designed to be fully local.
I'm halfway tempted given I've replaced almost all of my stack with my own code barring the browser and X.
I think, if I was going to consider and "X12" though, what I think would be the steps to start with would to trim the starting point down aggressively, to reduce the maintenance burden:
* "Promote" certain extensions, like BigRequests and XRender and enable them automatically.
* XRender requires a fixed set of visuals, including 24 bit and 32 bit. As a result, if you require XRender you can reasonably aggressively deprecate most inferior visuals. You might lose some old software without shims/a proxy that way. But frankly I don't think it's worth caring enough - if any of it is worth keeping, a shim is fine.
* Aggressively deprecate most legacy rendering calls and options. Almost all of it can trivially be shimmed client side or supported via a proxy if any extant/in use apps still support them. This includes support for server-side bitmap fonts (they can trivially be supported by XRender glyph support).
* Remove most backends. Support maybe one "dumb"/basic backend for legacy use, but remove as much possible.
The point is you can do a vastly better job if you strip the thing bare first.
Myth: X Demonstrates the Power of Client/Server Computing
At the mere mention of network window systems, certain propeller heads who confuse technology with economics will start foaming at the mouth about their client/server models and how in the future palmtops will just run the X server and let the other half of the program run on some Cray down the street. They’ve become unwitting pawns in the hardware manufacturers’ conspiracy to sell newer systems each year. After all, what better way is there to force users to upgrade their hardware than to give them X, where a single application can bog down the client, the server, and the network between them, simultaneously!
The database client/server model (the server machine stores all the data, and the clients beseech it for data) makes sense. The computation client/server model (where the server is a very expensive or experimental supercomputer, and the client is a desktop workstation or portable computer) makes sense. But a graphical client/server model that slices the interface down some arbitrary middle is like Solomon following through with his child-sharing strategy. The legs, heart, and left eye end up on the server, the arms and lungs go to the client, the head is left rolling around on the floor, and blood spurts everywhere.
The fundamental problem with X’s notion of client/server is that the proper division of labor between the client and the server can only be decided on an application-by-application basis. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. Still others need a sophisticated combination of the two, depending on the program’s state or the region of the screen where the mouse happens to be. Some programs need to update meters or widgets on the screen every second. Other programs just want to display clocks; the server could just as well do the updating, provided that there was some way to tell it to do so.
The right graphical client/server model is to have an extensible server. Application programs on remote machines can download their own special extension on demand and share libraries in the server. Downloaded code can draw windows, track input events, provide fast interactive feedback, and minimize network traffic by communicating with the application using a dynamic, high-level protocol.
As an example, imagine a CAD application built on top of such an extensible server. The application could download a program to draw an IC and associate it with a name. From then on, the client could draw the IC anywhere on the screen simply by sending the name and a pair of coordinates. Better yet, the client can download programs and data structures to draw the whole schematic, which are called automatically to refresh and scroll the window, without bothering the client. The user can drag an IC around smoothly, without any network traffic or context switching, and the server sends a single message to the client when the interaction is complete. This makes it possible to run interactive clients over low-speed (that is, slow-bandwidth) communication lines.
Sounds like science fiction? An extensible window server was precisely the strategy taken by the NeWS (Network extensible Window System) window system written by James Gosling at Sun. With such an extensible system, the user interface toolkit becomes an extensible server library of classes that clients download directly into the server (the approach taken by Sun’s TNT Toolkit). Toolkit objects in different applications share common objects in the server, saving both time and memory, and creating a look-and-feel that is both consistent across applications and customizable. With NeWS, the window manager itself was implemented inside the server, eliminating network overhead for window manipulation operations — and along with it the race conditions, context switching overhead, and interaction problems that plague X toolkits and window manager.
Ultimately, NeWS was not economically or politically viable because it solved the very problems that X was designed to create.
Today it'd perhaps be even easier to do. Both X and Wayland protocols are extensible and so adding a way of uploading extensions is simple enough. You'd run into "political" roadblocks, perhaps if you try to standardise it, but someone could just do it. A web assembly profile that provides a way of exchanging messages to allow you to build classes could easily be made to optionally either run over the network (maybe mostly for dev/debugging) or internally within an Xserver or Wayland compositor.
I think the biggest challenge today is that people would be more likely to just use a web browser for most of those things that would benefit most from working over the network, and latency for locally run software isn't a big deal (my wm, which I've mentioned elsewhere, is written in Ruby and spews about a dozen lines of debug output to the terminal for every mouse move during resize and drag at the moment, and yet it's smooth enough).
It'd be fun to try, though.
[EDIT: One simple/fun idea as a starting point for something like that would be to simply add an extension that injects such a wasm binary as a "filter" between inbound requests and outbound events/replies]
and I'm seeing many of the same kind of arguments as with systemd
like arguments you could re-formulate as "but my kinda uncommon setup which is irrelevant for the maintainers and sponsors of which do the decision will not work and it's bad to not support everyone for free" or "but you can't to X in that specific way and because of that you can't do so at all (ignoring alternative ways) and because of that it can't replace it at all" or "hung up on some technical detail which doesn't matter for 99% of users" or "my software which wasn't properly updated since 10 years doesn't work flawless under Wayland" or "hung up on something which wasn't supported initially but is supported since multiple years by now"
in the end someone will probably continue to support Xorg and someone will probably maintain it and it probably will get increasingly more painful to run it but it also will take many years until it really hurts and it probably will be banned from most companies caring about security and people starting to use Linux in some years in the future will probably not really know what Xorg is except is that thing related to some ancient programs not behaving nicely and they will wonder what it has to do with X(Twitter) and if thats why it's no longer used.
It is because it is the same situation. RedHat pushing their IP onto the mainstream and at the same time taking maintenance of over the industry standard so they can let it die off.
I'm sure I can make do with systemd but I don't like it, and thus I chose an OS that doesn't use it. I also don't like the way it was orchestrated that I don't have a choice. I want choices. And I don't like my system changing for the sake of it.
But with RedHat positioning themselves as the center of the Linux world it is quite difficult to avoid their stuff. They still have a huge finger in the pie and people still respect them as if IBM hadn't taken them over. Even after CentOS where people are even supporting their narrative of "freeloaders" when it comes to Alma and Rocky Linux.
I really hope some org from perhaps the BSDs will take over maintainership of Xorg instead of allowing RedHat to shutter it. Choice is good.
Who are these souls that would be maintaining Xorg, if only the nefarious Red Hat had not been doing so (laggardly, according to you)? Are they spending their free time working on Xorg, or are they being paid to do so by an employer? Which employer would that be, that has a reason to care about desktop linux AND is motivated to support Xorg specifically over Wayland?
And the people who were against systemd were arguing for sticking with the steaming pile of shit and toenail clippings from AT&T that replaced the simple but functional stuff from BSD, because they're too young to have ever known anything other than a steaming pile of shit and toenail clippings, and mistakenly think that's the One True Way of Unix.
Nostalgia for X-Windows is just as naive. Since nobody even uses X-Windows networking any more, they'd be better off with SunView.
For me, the reason for sticking with X is that my X setup works, and whenever I look at what it'd take me to do the same things with Wayland, I balk. I really don't care about X. But as long as the migration would break any number of script I rely on, it's not worth it exactly because I care about how I spend my time.
And that even drives me to write more X code because looking into whether I could realistically do the same upgrades to my environment with Wayland has put me off every time (I could write a tiny wm or be forced to maintain my own compositor - even the "tinywl" wlroots example is several times the size of my current wm, while not doing what I want).
For me it is purely pragmatic. If/when it gets harder to keep my X setup running than migrating, I'll migrate, and I do what I can't to keep the X-specific parts of my code well isolated. But it's likely to take many years before migrating becomes easier than staying put at this rate - frankly, odds are what will make me migrate is if/when the browsers drop X support.
> And the people who were against systemd were arguing for sticking with the steaming pile of shit and toenail clippings from AT&T that replaced the simple but functional stuff from BSD
I use the simple but functional BSD stuff :)
> Since nobody even uses X-Windows networking any more
This is my window manager; it's kind of a hacked-up thing I did myself for the craic. It works a bit different than many other WMs, and I spent a weekend or two on it and it's worked very well for my since. I last compiled it in 2019 (it's fairly large on account of being statically linked) probably to change some simple configuration thing. It's worked very well for me since.
"I use my home-grown WM" is an uncommon scenario, but "I have some specific thing written for X" isn't (this is just a bit of an extreme variant of that), and neither is "I'm rather used to my current setup, and I'd rather not change". I have a bunch of other programs that have no clear alternative; I've written some myself, some are by others. Perhaps my favourite is my wm-scratch[1] script to quickly show/hide a "scratch terminal" or other windows like Firefox devtools. I will need to re-create all of that. I don't even know if something like wm-scratch is possible under Wayland (maybe, maybe not?)
I know very few people who like X11 as such. In fact, I know no one who does, and never have. I do know a lot of people for whom X11 works "good enough", and don't feel like spending time changing things.
If this is a new argument for you then you really haven't been listening, because this is what many people have been saying for years.
As for systemd, my argument has always been "SysV init sucks, but so does systemd, and we have much better systems like daemontools". "SysV init sucks, so therefore systemd is the only possible answer" has always been one of the great fallacies of that entire discussion.
Welll in this case anyone who wants Nvidia cards to actually work for games. Also anyone using some major applications like discord. So anyone actually gaming on Linux.
X is a moving target, RHEL continuing to support X and push it to customers maintains it's relevance and helps propel it forward. By not channeling resources into supporting and maintaining X, they will simultaneously slow the speed that X is moving, be able to divert more resources to Wayland, and light a fire under the asses of people who haven't transitioned to Wayland.
X is 32 years old and Wayland has been the replacement for it going on 15 years! That's insane, it's time for distros to pick a side. Either continue to support X or switch to Wayland.
> By not channeling resources into supporting and maintaining X, they will simultaneously slow the speed that X is moving, be able to divert more resources to Wayland, and light a fire under the asses of people who haven't transitioned to Wayland.
Ah yes, the time honored "if you can't reach feature parity, just make the old thing worse" strategy. That'll really win hearts and minds.
Are you working on X? Are you donating to get others to work on X?
He who does the work in open source calls the shots. Nobody is working on X anymore as of like 10 years ago, holdouts need to put up and support X, or switch to Wayland. Sure Wayland needs work, but everything I can see says it is a better architecture and people are working on it.
Mm, there's a fine line there - people who aren't contributing aren't entitled to demand work from people who are, but that doesn't mean that their complaints about shortcomings are somehow invalid. Or put differently, just because Wayland is given away for free doesn't make it immune to criticism.
And
> Nobody is working on X anymore as of like 10 years ago
is just factually incorrect; it's actively maintained, and it's kind of hard to point at a single changelog because of how Xorg releases components separately, but ex. https://www.phoronix.com/news/Modesetting-TearFree-Merged is a feature release from late last year, and there have been multiple security/bug fix releases this year.
In any event, yes, I am donating to drive work on Xorg; am I allowed to call out regressions now?
X is maintained, but only the bare minimum possible. I wasn't aware of TearFree, but looks like someone stepped in to do that work - will that person continue add features to X, switch to Wayland, or go away: I don't know. That work plus security/bug releases is not very much.
How much are you donating to Xorg? $200,000 entitles you to one year labor (that is probably a low estimate). If it is $100 (a much more likely donation) you gets you an hours worth of effort. Xorg needs a lot of money just to keep the lights on, so probably you don't even get that hour just because it all goes to web hosting and other overhead (thanks for giving it - they do need that)
Ah yes, the time honored "I don't like the new thing, so I'm going to cry foul and lie about the actions of others to characterize them as evil" strategy.
Saying "hey, we don't want to keep supporting this product so we're going to stop" is not the same as "we want to make this go away, let's sabotage it." It's indigenous to equate the two. But you don't care right? The ends justify the means after all.
Well now I'm mostly going to conclude that Wayland proponents are remarkably unpleasant if you dare disagree with them. But cropping out the personal attacks and addressing substance:
> "hey, we don't want to keep supporting this product so we're going to stop" is not the same as "we want to make this go away, let's sabotage it."
From inside Red Hat, that's true. From outside, they look similar. As a user, they're functionally identical; anything not actively maintained and supported will degrade or die, because users are forced to new hardware that needs to be supported (if nothing else, by old hardware dying) and new software and OS versions (by company policy, audit requirements, and vendor support). If and end-user was using, say, an accessibility tool that doesn't work on RHEL 10, the motives and mechanism are secondary to the fact that the tool no longer functions.
> Well now I'm mostly going to conclude that Wayland proponents are remarkably unpleasant if you dare disagree with them.
I literally just threw your own rhetoric back at you. Is that an admission that you're remarkably unpleasant?
> From outside, they look similar. As a user, they're functionally identical;
The sort of entitlement you must have to think anyone is required to financially support your project...
This is how open source works, you support the projects you like and want to succeed or that benefit you. Full stop.
No one is required to fund or support a project just because it's open source and anyone is allowed to walk away from something when they feel it no longer serves their interest.
If X can't survive without Redhat funneling money into it, then Redhat was the only thing keeping it alive and it's time to put it out to pasture. You may not like the thought of your project or community dying but it is 100% dishonest to characterize it as sabotage or an attack. That's the type of logic abusers use on victims.
they aren't making it worse, they are only focusing wayland to reach feature parity, and xorg is already death in development, so it don't change too much
How do you figure they are not supporting things long-term? RHEL 9 (with the current X server) is fully supported to 2027 with maintenance support (i.e. security updates) until 2032... That's an incredibly long time.
RHEL 9 is supported until 2032, with the right support contract you might get even more years, idk.
so you have another ~8 years with Xorg on RHEL
and since RHEL made Wayland the default in RHEL8 (released mid 2019) it is clear for 3+ years that you _slowly_ have to start planing migrating to Wayland. Which means customer have around 10 years time to slowly plan and execute the migration.
> Isn't RHEL supposed to be the distro that gives you long-term support and stability for things? Why are they committing to remove X before Wayland gets full feature parity with it?
Because they provide long term support. With RHEL10 being released in 2025, that would mean having to support Xorg up to 2035, which they obviously do not want.
Additionally, it would slow down the transition. Many would take it, that they have extra time and need not bother yet. By this announcement, it is clear that there are no extra years, clock is ticking, by 2029 the Xorg is dead.
I soon soured on the entire thing. It's very clear to me that wayland was an 'ivory tower' display server that had little respect for users or wm devs. You can't just go and break tons of things for security's sake when the harm is clearly higher than the benefits. Disabling screen and input capture should have been an 'opt in' feature for the truly paranoid. They should have also shipped a fully working bare bones desktop wm instead of a 'toy' implementation meant to run on a car entertainment center.
Frankly I can't believe it got as much traction as it has, but we're all stuck with it now as it's clearly 'the future'. This and systemd really showed me that the linux ecosystem is far more vulnerable to the interests of a few corporate sponsored devs than the general community.