I restart X11 only when either there's a power failure longer than the battery on my UPS, or I upgrade my kernel, so it's reliable enough.
For running individual applications over the network, Waypipe might be the way to go, though I haven't tried it.
Right, the name or any kind of lineage does not matter, Wayland is the X11 successor because it is the current seriously developed and improved open display protocol. Nothing about Wayland stole from X11, has any less legitimacy to be the post-X11 protocol than something called X12, or prevents anybody else from improving X11 or from working on an alternative they call X12 or anything else.
I don't know why people get so hung up about this. People including its creators may have been over-optimistic about Wayland, but it was never going to be a case of a weekend hacking binge producing something useful out of the gate (X11 had that distinction because it was entering a very small and very green field). X11 has been used for so long because it is very well supported, robust, and has been extended and improved for decades and most of the remaining problems it has are very hard to solve. And that's exactly why we also didn't see something called X12 happen overnight either.
The fact that Wayland has been created and worked on and blessed by a number of X11 alumni did lend it a good amount of credence early on, and one might say gives it the right to be spiritual successor to X11. But really if you censor the names and look at the practical reality rather than sentimentality, Wayland creators and developers have been going down the long difficult road of coming up with something better and nobody else did, so that is really why it is the next X11. Progress may seem slow but it does not stop. Features continue to be added, implementations continue to improve, support continues to expand and its takeover seems almost inevitable at this point.
Someone might mention "network transparency" at this point. As far as I've seen from the outside looking in that was never the fundamental requirement of the protocol as far as I can tell. Non-transparent protocol like DRI were never not considered to be X11 by the X11 architects and developers who wrote and merged them, showing they have always been quite willing to step out of rigid dogma and embrace practical application. The original X announcement never said the project was a network transparent window system, it said it was a good-but-not-perfect window system and if a good windows system today does not require network transparent protocol (because users don't care as much as they did back then or because networking can be achieved at other layers) then there is no reason it couldn't be X12. The X12 page linked here enumerates some other X11 features that could be dropped too, I've never seen a reasonable argument for why a network transparent protocol is the be-all and end-all of X.
deleted 4y ago
[deleted]
Good point. And for those who need to connect over the network there are now FOSS implementations of RDP, for example. (And VNC, but the performance there is probably not so good.) Then there’s also proprietary solutions such as BeyondTrust and NoMachine.
Yeah, I know RDP was developed in Redmond but from my layman’s perspective, it’s one of the best protocols for accessing a graphical desktop environment over a network. If you worry about the security, just tunnel via WireGuard.
> I don't know why people get so hung up about this.
People get hung up on this because they believe that free software somehow entitles them to dictate that others perform infinite labour on whatever schedule, projects, or features that they deem fit, irrespective of whether the people they are dictating to want to, think that it's a good idea, or whatever.
> Wayland is 15yo, barely usable
It's the default on several distros. I regularly play AAA games on my gentoo gaming PC, using proprietary NVIDIA drivers, on KDE Plasma, with little or no performance differences compared to X11.
Even the Steam Deck, arguably the most popular linux PC, runs its default UI on Wayland.
Gamescope is wayland while the desktop is x11
A little weird to classify the Steam Deck as a "personal computer". It's a special-purpose handheld gaming device that just happens to run Linux & Wayland under the hood.
While I wouldn't call Android phones "personal computers" either, they're much closer to being the "most popular Linux PC" than a Steam Deck is.
I did say "arguably".
I mean more in the sense of the hardware it uses, i.e. it's PC-compatible (x86) hardware that runs a desktop linux distribution by default.
The Steam Deck is literally a PC, no doubts about that. It's even more "P" than many other "C"s, like most Apple hardware for instance. But I think that the notion that it somehow validates Wayland as mature tech is kinda weak.
It appears that the justification for switching to Wayland in many distros (just like systemd before it) was so that the devs could actually abstract away work on these components and invest time into their flagship features (WM, filesystems, shells, look & feel, the works). For what its worth, looks like this was achieved.
At least it's closest to a "Linux distro" software-wise.
(Otherwise Android phones would be the most widespread Linux devices with a powerful GUI.)
The Steam Deck is not locked down, unlike e.g. the Nintendo Switch.
I have tried Wayland several times over the last few years, but I have many persistent niggles caused by third parties refusal to fully support it. For one, Discord doesn't support push-to-talk VOIP on Wayland (I believe it requires them to create a daemon for global keypresses). I also recently 'upgraded' my RX 5700 XT to a 3070, because I received the 3070 for free, and Nvidia just refuses to support Wayland.
It's not that Wayland is bad. It's that companies, whose primary focus is Windows, just refuse to develop for it.
Does it? Desktop mode reports itself as X11. I don't think Gamescope supports Wayland either...
> Yeah, I'm a big fan of systemd but I can accept that when it first came out it was probably a lot worse than it is today.
The first "large" distro to switch from sysvinit to systemd was Arch, and that switch happened over ten years ago. The switch itself was quite rocky (the upgrade path was not particularly seamless, and while Arch users tend to be more tolerant of that sort of thing, it's worth mentioning).
That said, even in 2012-2013, the end result once you completed the upgrade was significantly better than collectively expected. The original plan was to support both systemd and sysvinit (at least for a period of time), but that was quickly abandoned because not enough people wanted to actually maintain sysvinit packages, so support[0] ended up getting dropped very quickly.
[0] Arch is a community project, so "support" is different from what you'd expect in (e.g.) RHEL, but it still has separations of what's considered supported and what's not.
> The first "large" distro to switch from sysvinit to systemd was Arch
No. In terms of released to users, the first was Fedora; the second was Arch; then Mageia; then openSUSE. In terms of integrated into the distribution, the first was Fedora; the second was Mageia; then openSUSE; then Arch.
Cf. https://en.wikipedia.org/wiki/Systemd#Adoption https://en.wikipedia.org/wiki/Systemd#Adoption
I don't really see the parallels.
For the past few months I've been investigating and working on porting parts of Xfce to be usable under Wayland. It's astonishing the number of features that are just not implementable at all on Wayland, at least not without inventing new non-standard Wayland protocols. (Another option is refactoring the desktop environment so all the individual components run in the same process as the compositor, and have access to the compositor's internals, but that's unacceptable for what are hopefully obvious reasons.)
Even after over a decade, Wayland still seems quite immature and poorly thought-through. The protocol standardization seems geared toward satisfying GNOME's use-cases and ignoring everyone else's. The wlroots camp has gone their own way on a bunch of things, which is fine, but fractures the landscape a bit.
Making Xfce fully Wayland means turning the window manager, xfwm4, into a Wayland compositor. For someone already familiar with xfwm4's code base, that's a year or more of work (and a requirement we'd have is that it would have to support both X11 and Wayland, further complicating things).
Even if fixing inherent problems in X11 (security, graphics rendering, etc.) would require compatibility breaks, personally I would find that preferable to throwing the entire thing out and having to build (and build on) an entirely new system. As much as I disagree with JWZ's attitude on a lot of things, his description of most open source projects as a "Cascade of Attention-Deficit Teenagers" seems to be pretty accurate, at least here. X11 hasn't been improved and fixed because no one wants to maintain and improve X.org anymore, and the people who used to maintain it would prefer the fun of chasing and working on new shiny things, even if it means decades of new make-work for anyone working in the Linux GUI space.
Don't get me wrong, I am the first one to cut off anyone at the knees who feels they are entitled to tell open source developers what to do with their time (though it gets a bit more complicated when many of those developers are employed by corporations to do this work). But I think it's pretty shitty to push the desktop in this direction and essentially force desktop and toolkit and application developers to choose between stepping up to maintain and build on X.org (something well out of most people's wheelhouse), or spend a huge amount of time porting to a new display system.
Having said that, Wayland does have promise to be a better system than X11, even though it will likely take another decade to achieve feature parity with what we already have. So I'll continue to work on getting there eventually, even though I resent the fact that I have to learn an entirely new display system so I can work on reimplementing the same features again instead of building new features, fixing bugs, and making things more polished.
> Even if fixing inherent problems in X11 (security, graphics rendering, etc.) would require compatibility breaks, personally I would find that preferable to throwing the entire thing out and having to build (and build on) an entirely new system.
Why?
X11 in the current state would need to be radically redesigned anyway.
There's a bunch of stuff that long stopped making sense, like XDrawLine and similar. The networking protocol sucks horribly and just doesn't perform, even on modern, high end connections, and there's a bunch of baked in assumptions that don't match modern hardware.
Yeah, you could make X12 break compatibility, throw out all the cruft, and redesign the protocol, but at that point, what is even the point? It'll break pretty much every single application in existence anyway.
The point may be to create a smaller, simpler, more secure protocol which is easier to develop against.
Unlikely it could be made more flexible than X11 though. But at least it could be made flexible enough.
I think in both cases, there's a similar switch of philosophy. We went from "there are a bunch of components glued together, and with enough glue you can solve anything (except an excess of glue)" (shell scripts for sysvinit vs declarative unit files for systemd; X11 apps that can do almost anything, vs the privileged compositor for wayland), to a model of "we wanted things to just work without having to install glue, so we integrated more functionality people wanted, if you want to swap it out you have to swap out the whole thing and keep up enough with all the other features people want" (e.g. you have to actually get the things you want into unit file directives, or get the features you want into the compositors people use; or you have to build a completely separate compositor or a separate init).
That's a tradeoff. For my part, I'm thrilled that so many more things just work out of the box; however, it's discouraging for people whose features aren't covered yet, since they have to go work on integration rather than writing a specialized tool and encouraging people to glue that tool in. But the benefit of that is that once something is integrated, it just works, with no glue required.
You are presenting this in certain way that I think veers into inaccurate and misleading in an attempt to smooth things over and be nice.
What we had before systemd was -
90% glue code, reimplemented quite badly across X distributions.
That glue code was, in practice, extremely brittle and very very unfun to attempt to keep even simple daemons running "portably" distribution to distribution.
The other 10% was increasingly aging and ill maintained c code snippets.
That was not a nice world for people actually using it.
For people making stuff up about "the old days" that didn't actually participate in the misery of making basic systemv scripts, yeah it was composable and we lost something.
The internals of systemd are just as brittle, and the model of unit file configuration does not really apply cleanly beyond the simplest cases. So editing unit files becomes an undocumented dark art.
Chiming in here to say that systemd seems to cover the 80% (or even 90%) case pretty nicely, however that last 10-20% is now really difficult.
Anyone who has really delved into systemd knows this but they get shouted down as halting progress and hugging bash scripts, which is disingenuous as bash scripts (as per sysvinit) were painful and had great difficulties in areas such as determinism and parallel execution.
If you ever want an example of what I mean: look at how systemd starts mysql. Someone (not me) spent at least a man month making that work.
I do begrudge the all or nothing approach that systemd is taking (even if it claims to be modular), but I will admit openly: that 80% case is a lot nicer.
> If you ever want an example of what I mean: look at how systemd starts mysql. Someone (not me) spent at least a man month making that work.
I was curious, so I cracked open the mariadb.service unit that ships with Arch Linux. Other distros might ship different unit definitions, but this is the one I'm looking at.
It's large, yes, but very well commented and seems quite clear to me.
Much of the complexity seems to be around sandboxing: PrivateNetwork, CapabilityBoundingSet, PrivateDevices, ReadWritePaths, ProtectHome, PrivateTmp. These are all settings to do with hardening the service. They're totally optional, and can be removed without impacting functionality.
There is some extra complexity in the ExecStartPre and ExecStartPost commands. This appears to be something to do with the Galera cluster functionality. I'm not entirely sure what's happening with those, but I imagine these commands would also be present in a SysV init script implementing the same functionality.
The rest is pretty standard stuff: the user/group is set, along with the umask and some ulimits. LD_PRELOAD is set to load jemalloc. There's also some start/stop timeouts configured, with a comment explaining that these same timeout values were used in the SysV init scripts in the past.
Essentially, I'm not really sold that any of this complexity is caused by systemd. The hardening strikes me as a little unusual, and at a guess I'd say that this probably wouldn't be present in a SysV init script. If it were, the configuration would live in executable code, not in strictly declarative config directives.
This?
https://gist.github.com/thomasfr/e4e4bb64352ee574334a https://gist.github.com/thomasfr/e4e4bb64352ee574334a
I don't see anything out of the ordinary there.
That's from 9 years ago - here's the one that Debian is currently shipping (172 lines): http://paste.debian.net/1272485/ http://paste.debian.net/1272485/
There's a little inline shell for Galera integration, but i suppose the rest is mostly comments,
> The internals of systemd are just as brittle, and the model of unit file configuration does not really apply cleanly beyond the simplest cases. So editing unit files becomes an undocumented dark art.
I call bullshit on that.
We removed few thousand lines of SysV init scripts from our configuration management that were basically fixed by us for subtle errors when we migrated to systemd. There is very little cases that aren't handled by very simple systemd units, in fact I'd dare you to give example that would be easy in SysV and hard in systemd.
Few fun cases:
Process after doing /etc/init.d/servicename start -> status immediately returned service stopped. That confused service managers like Pacemaker that thought the service failed to start. Why?
The app did start -> save pid file. Java app so it took a second.
The script just forked the app into background. So if you run status after start the pidfile was not there and it showed it is stopped. Not the problem in systemd
Another
(IIRC) MySQL init script put pid file in /var/run/, like everything else. Bit old install so /var/run wasn't a separate partition or tmpfs.
MySQL init script also didn't try to start if it found the PID existing in system. It didn't check what* was running tho.
So in crash scenario, server started, MySQL init script went "oh, there is apache daemon using that PID I had last reboot, clearly that means mysql is working" and exited. MySQL status returned MySQL working. Not a problem in systemd
Another:
Script just... sent signal and exited on stop. App could took some minutes to shut down. stop -> start failed, pid was lost coz script removed file with it after sending signal.... similar problem with multi-process app scripts not killing all childs. Systemd "just have a cgroup and mark service as stopped once everything dies" fixes that. YOu can ask for that behaviour if you tell systemd to not kill processes on stop but that's pretty much "purposefully using non-default settings" so can't be really done on accident.
IIRC all or most of that is how SysV init script by standard should not work but were simply bugged
Those scripts were in popular packages in "enterprise" linux distros. If even those maintainers can't make "simple SysV script" then maybe sysv scripts aren't as "simple" as some people claim they are.
I was attempting to acknowledge, in good faith, that there are valid tradeoffs between models, even for folks who prefer one model over the other.
I'm happy in the current model as well. But I also acknowledge what it traded off to get there.
X11 offers a lot of functionality on the server - a lot of it unused, but still. Wayland technically specifies little but the protocol. So here the philosophy switch is the other way around.
The problem is that systemd vs sysv-init is a false dichotomy.
Systemd took over a ton of important non-init functionality, like DNS, logging, and interactive sessions. That could be fine if systemd did so in a nice and rock-solid way, but it was unpleasantly bug-ridden for years after being thrust on mainstream distros via a hard Gnome dependency.
SysV-init sucks in many ways, it's well known, and I can personally attest to that. I don't want SysV-init to be perpetuated.
There were, and are, viable alternatives to both, which are a less radical rework of the well-established Unix approaches around the area, do not overreach well past the init system scope, and are sane and well-functioning. For examples, see [upstart], [openrc], [s6], [runit].
I think that the prevalence of systemd was mostly achieved not through its technical merits (which undeniably exist) but through Red Hat's strongarming, because Red Hat wants certain things work in a way convenient for their business, and they have a powerful battering ram under their control, the Gnome DE.
Fortunately Wayland is not being force-fed in such a way, because, much like systemd when it was introduced, it's still in many important regards not exactly ready. I, with my 25 years of running Linux on desktop, will gladly migrate to a better graphics architecture when in becomes adequate for my purposes, if the whole current Unix architecture is not obsoleted and replaced wholesale by that time.
[upstart]: https://upstart.ubuntu.com/ https://upstart.ubuntu.com/
[openrc]: https://en.wikipedia.org/wiki/OpenRC https://en.wikipedia.org/wiki/OpenRC
[s6]: https://www.skarnet.org/software/s6-linux-init/ https://www.skarnet.org/software/s6-linux-init/
[runit]: https://www.skarnet.org/software/s6-linux-init/ https://www.skarnet.org/software/s6-linux-init/
upstart: a broken design and abandoned by its author and canonical https://lwn.net/Articles/581548/ https://lwn.net/Articles/581548/
openrc: I don't believe openrc had a process supervision story 8-9 years ago. from what I recall at the time openrc was just a slightly better sysvinit.
runit: I have a lot of experience with runit, and while it works, it has many footguns and is hard to use correctly.
s6: a better runit with better footguns
A great thing that more people should read, is https://lwn.net/Articles/578210/ https://lwn.net/Articles/578210/ from one of the Debian developers who voted to switch to systemd. It touches on things like the lack of adoption of upstart, and openrc not solving the problems they had.
I'd like to see Wayland be integrated as part of systemd. It would make things much cleaner
> Then have fun running GNU stuff on ChromeOS
I do. My only ChromeOS device at present is an old Thinkpad T420 with a Core i5 and 6GB of RAM. It runs very quickly with ChromeOS Flex. Currently I have Firefox ESR running on it, and DOSemu. Inside DOSemu I have MS Word for DOS.
It's a Linux. It runs Linux stuff thanks to a built-in feature, and since Flex came out, the Linux support has improved visibly: so for instance Firefox now works properly with either a full titlebar or none, and this depends on the settings within Firefox not on ChromeOS.
It works, it runs, it's useful, now, today.
Personally I don't give a toss about any of the other things you mention. It plays videos smoothly, it's fast and responsive, and my webcam works. I've tried Skype, Whatsapp, Facebook Messenger and Zoom in ChromeOS and all worked fine.
Sure it may be limited. I am not denying that. But it's selling well up against Windows and Mac, which is something no other Linux distro has ever managed to do. Despite all their fancy acceleration features and being free, ordinary consumers are not interested, even though they are FREE.
ChromeOS is not free: you can only get the full version by buying it on custom hardware, and you need a Google account to use it. Those are significant drawbacks compared to every free distro...
And yet 10x more Chromebooks sell per year than all the free distros put together can GIVE AWAY.
That is not just noise. That is no rounding error. That is massive.
The year of Linux on the desktop came, over half a decade ago now, and the Linux world was too busy with infighting and squabbling over Snap vs Flatpak and other pointless nonsense to even notice that the mainstream consumer world has adopted Linux bigtime.
This link comes up in literally every Wayland thread and it is even more bullshit now than it was in 2013 when it was first posted (and it was bullshit then too). It is titled "the real story" but it is quite the opposite.
A few key points:
1) he laughs at how X has a bunch of extensions. https://wayland.app/protocols/ https://wayland.app/protocols/ hypocrites much. In 2013, since it was completely unusable, it probably didn't have many. But turns out real world use leads to "useless" features being reimplemented.
2) he complains about how X.org has broad hardware compatibility. As if that's a bad thing. Meanwhile wayland, even now it still doesn't work reliably on half the graphics chips on the market.
3) It complains that certain X features are not fully network transparent. True, but most are and you can detect at runtime and gracefully degrade. Wayland "fixes" this by just dropping the whole feature.
4) it flat-out lies saying the X server does nothing yet it is so much hard to maintain code. The core X protocol provides backward compatibility and is rock solid (and really easy to impelment from scratch btw, someone did it in Javascript for a tutorial for crying out loud). Meanwhile the Wayland compositor keeps accumulating everything because of point 1. Need a screenshot? Add it it the compositor. Need a hotkey? Add it to the compositor. Need drag and drop? Add it to the compositor. Need a notification icon? Add it to the compositor. In X, all those are peer to peer. Graphics are actually a relatively small part of a graphical user interface, something Wayland is still slow to learn.
5) He complains that certain applications are written inefficiently with blocking calls which is inefficient over a network connection. Wayland's calls are ALL blocking and just has no network connection.
6) Complains that X may draw things unnecessarily. Indeed... but there's an extension to disable that. Easy fix. Wayland even uses the same drivers!
1) no, he complains that X11 has a big core and then extensions. Extensions are fine, but they were unable to kick out parts of the core, because it is the core and something somewhere assumes it is there. So they had to maintain it, despite not being used in practice, except by that little something that nobody can point their fingers at.
2) he talks about obsolete hardware. There's no really a point to support s3 trio, at the expense of support for modern hardware, which works ink wastly different way.
3) That graceful degradation is in practice the same, as just using Wayland. Ever tried to use modern X11 app over network? RDP is vastly better experience, (and RDP support is wip in wayland).
4) This is so wrong so I won't even react to it.
5) Wayland calls do not wait for reply. You rapid fire requests and then collect responses as they come. Heck, you can even get a response you didn't ask for ;)
> he complains that X11 has a big core and then extensions. Extensions are fine, but they were unable to kick out parts of the core, because it is the core and something somewhere assumes it is there.
The thing that I find ridiculous about this attitude is that you have two choices:
1) Remove parts of the core that some (mostly old, unmaintained) applications rely on, which will break them. You'd probably have to call it "X12" now, but that's fine: most X11 applications would continue to work with no (or very few) modifications.
2) Throw out the entire system and build a new one from scratch, that literally no applications will work on until new toolkit backends are written and some applications themselves are rewritten or at least fixed up. Those same old, possibly unmaintained apps that would stop working in #1 are still not working, but now it's along with literally everything else too.
> RDP support is wip in wayland
If I had a dollar for every time I heard "$IMPORTANT_FEATURE is WIP in Wayland", I'd be able to get several pizzas delivered.
3) Build a new system that supports the old system reasonably well and doesn't prevent people using and improving the old system until the new one meets their needs.
> If I had a dollar for every time I heard "$IMPORTANT_FEATURE is WIP in Wayland", I'd be able to get several pizzas delivered.
It's true though there have been features missing. It's good thing that they are being worked on though, no? The X protocol and the Xorg implementation are both abandonware, so your comment comes across as positive, because missing $IMPORTANT_FEATURE in X/Xorg is not WIP.
> That graceful degradation is in practice the same, as just using Wayland. Ever tried to use modern X11 app over network? RDP is vastly better experience, (and RDP support is wip in wayland).
I do, in fact, use modern X11 apps over the network literally every day. Some are better than others - if the programmer made the effort to actually gracefully degrade it can be a considerably better experience than the ones who just shoot a constant stream of bitmaps down the wire (which do work better on rdp, i remember once upon a time, I'd ssh to my linux box and set up port forwarding to a windows box on my lan so i can remote desktop to it, then run Xming from there... which is absurd that that actually worked better), but if you do it well, remote X is very nice to use.
The seamless integration of windows from multiple computers is a thing to behold. Remote Desktop is great and I like a lot about it, but even the "Seamless" rdp doesn't work as nice as X.
> Graphics are actually a relatively small part of a graphical user interface, something Wayland is still slow to learn.
This I think is a key insight. I talk about this in another post, but I've been working on "porting" parts of Xfce to Wayland, and there are so many things missing in Wayland that have nothing to do with "graphics" that means that Xfce+Wayland will be missing a lot of useful features until/unless Wayland protocols are invented or extended to make them work.
None of Waylands internal functions between a client and compositor are blocking or synchronous to my knowledge. Generally you fire off a message and will later receive an event back from the compositor, which is happening in an event loop.
There is an exception, which is the explicitly blockling "roundtrip" function(s), but that is meant for special cases only.
Being asynchronous was an design goal for Wayland from the very beginning.
This isn't that different than X though which also has the fire off a message and receive event back. Very few of the functions actually make you want (even in xlib, which wraps the protocol itself to be a bit easier to use from C, the majority of functions still are async - much to the chagrin of newbies trying to decipher error messages)
> The core X protocol provides backward compatibility
I had a bit of fun a while back trying to get an old X/11 terminal to work with a modern Linux machine and was somewhat surprised I was able to make it work. Sort of at least. Many display managers didn’t implement the proper protocols, but XDM did and I was able to get it to work at least a few times.
> It isn't really Wayland's calls itself, I prolly stretched too much there,
Do you mean simply incorrect i.e., that Wayland calls are not all blocking? Or do you mean that in practice there are some important high-level situations that do require a round trip despite the low level purporting to be mostly asynchronous?
> Since Wayland doesn't support this kind of network remote use anyway, the distinction doesn't matter. Local X vs Wayland are both fast.
Wayland can run to remote displays though, right? You could argue it's not complete or well supported or nicely integrated into the core protocol or whatever, but you can literally use it today and probably have a package to do it available in any Linux distro you're using (e.g., waypipe). So it's hard to see what you're getting at. Wayland may not have been made with transparent networking support foremost in the protocol but AFAIK the idea was always that you'd be able to do remoting by forwarding buffer contents with the protocol.