> Wayland is the new hotness on the Linux graphics stack
Use wayland (with gnome) everyday myself but wanted to point out that wayland started almost 10 years ago :) The adoption has taken forever though partly because of the infinite legacy of X11 and lack of support from big players like nvidia.
Adoption has taken forever mostly because it's a solution in search of a problem, at least in terms of how it's been sold to users. The main user-visible difference is "lose the ability to run remote programs on your local display" - you can understand why users aren't lining up for that.
For what it's worth, I might be a more-obsessive-than-average user, but it kills me when I see tearing and flickering in X11 windows. "Every frame is perfect" is a super visible change :)
Btw, am I right that tearing in a video in VLC is an X11 interaction, or is that purely a VLC thing that I should expect to keep happening with Wayland support?
> but it kills me when I see tearing and flickering in X11 windows
Honestly don't think this will ever be solved in the open source world. It rarely even gets solved in the commercial world unless there is an internal design team involved who have enough power to force the dev team to solve these things. Win 10 for example has some silky smooth transitions but then you resize an explorer window and it flickers black.
So many people don't even seem to notice it but for some of us it's nails on a chalkboard.
VLC is notoriously buggy in general. I'd put a lot more stock in how mplayer (or whatever the popular option is these days), xine or even ffplay behave.
The classic tragedy of Linux-on-the-Desktop: trying to gain traction by removing perceived "warts", all the while alienating user and developer communities alike. Result: more cluttered landscape that is even less of a target platform for desktop software.
Unfortunately a lot of people look at large projects full of difficult to understand, ugly, inelegant code and see a pile of spaghetti and warts that is hard to maintain. In many cases - especially mature projects that are widely used - the warts and inelegance are bugfixes, the piles of spaghetti are the compromises needed in complex interdependent systems and the workarounds/patches that handle the messy problems of real life.
As Joel Spolsky famously explained[1], a lot of those "warts" are the most valuable part of the software. They represent an incredible amount of programmer time and effort. Throwing them out and starting over sounds nice because the clean, elegant replacement is solving a far simpler problem. The replacement is usually missing features and bugfixes. When you finally update the new version to be an actual full-featured, bug tested and fixed replacement, you've probably re-added most of the messy "warts".
A lot of warts in software come from legacy constraints - both I'm terms of backcompat, and HW/design constraints that are laughably irrelevant - throwing out warts and starting simpler is how you got ZFS for eg.
Those "legacy constraints" are often being used. Backwards compatibility is very important, because throwing out decades of development efforts involving millions of man-hours. Supporting legacy interfaces can be annoying and in some situations it gets in the way of newer features, but it's incredibly rare
> ZFS
Nothing needed to be thrown out to implement ZFS. More than one software interface can exist at the same time. ZFS development didn't use some of the features used by traditional filesystems, but it's "rampant layering violations" didn't require the removal of UFS, RAID, or older volume management drivers. The fact that it's always been possible to mount ZFS and older UFS disks at the same time should make this obvious.
Or maybe X11 is actually useful to many people... I regularly run expensive commercial software remotely on a beefy server and access the GUI locally via X forwarding. I suspect among professional desktop use of Linux (besides software development) this a fairly common scenario.
Not just that. It took major DEs a very long time to get to some level of readiness with Wayland (KDE is just getting to it). And some major applications aren't event close yet. Firefox seems to be in progress for years, and Wine didn't even start moving to Wayland, because of various difficulties.
One of the reasons why Wine worked in the first place is because GDI primitives map nicely to X11 drawing primitives. Wayland developers made the Yao Ming "bitch please" face and told us "no one uses those dusty old primitives anymore! Here, have a bare framebuffer and render everything yourself!"
I think that's less "hard" and more "impossible by design" - that is, Wayland intentionally doesn't give applications any way to know or control the absolute positions of their windows, and of course Windows applications expect this.
I have to agreee with you. How many look at the current situation and compare to a realistic best case?
If wayland were adopted as fast possible without breaking a bunch of things for people how long would it take? Much longer than it is now, or just slightly longer?
Even if every body wanted could we have gotten this done in 5 years without breaking a ton of stuff?
Interesting article, nice to see some more practical examples.
For those unaware, SirCmpwn is responsible for sway - https://github.com/SirCmpwn/sway - which aims to be an i3 compatible compositor for Wayland. In my experience it's not production ready yet, but it's definitely a pretty cool project to keep an eye on if you do use i3.
Out of curiosity, when was your last exposure to Sway? Many people use it as their daily driver and would agree that it's production ready (even if it's not done). Can you report any bugs you find?
Not OP but I'm using sway when I'm on Linux, too. The only annoying thing is, that the mouse cursor is laggy when the system is under load. Apart from that I think it is pretty good! A systray would be nice of course but that is not a deal breaker. Thanks for the amazing work!
A lot of it comes down to the choice to use wlc[1], a library that provides some of the low-level plumbing for Sway. It was great for getting Sway up and running quickly, but it's not very flexible for the directions we want to go. Most of Sway's performance issues are due to WLC or decisions Sway had to make to accomodate WLC.
Currently most of the work on Sway is being done on wlroots[2], with the goal of replacing wlc. The design is much more flexible and should have better performance and should avoid imposing constraints on Sway that impact its performance. A lot of Sway features are also currently blocked by wlroots, since wlc isn't flexible enough to allow us to implement them. I'm actually lucky enough to be working on wlroots full time at the moment, thanks to a generous commercial sponsor[3], along with some support from Patreon[4]. The future is definitely bright for Sway :)
> Can you report any bugs you find?
Perhaps, but I'm not convinced they're bugs in your code.
When I said it wasn't production ready, I was referring to the ecosystem (using xwayland, GTK apps etc). In my experience this isn't quite as good. As an example: searching in Firefox is glitchy (dropdown menu), resizing apps (even apps such as urxvt) in Sway is a bit glitchy during the resize etc. I'm not sure how many of these things have been reported. The default mouse wheel speed and mouse speed seems to be odd, I think I need to read up on the documentation to fix this.
I spent some time recently trying it on my XPS 13 and I noticed that the mouse would freeze sometimes as well. Also there are some weird glitches when using apps like Steam, but that's not a major issue really.
Probably the two things (which aren't sway issues) that kept me from continuing to use it are that wayland doesn't work properly with Synergy (which I use a lot) and I'm not an i3 user and I'm a lot more comfortable and familiar with XMonad but I'm sure I could configure it to my taste given enough free time.
Fun fact: Wayland is supported on ChromeOS versions 50 and above for the supported Android applications.[0][1] Consequently, you can run Fedora with Wayland on a supported Chromebook using crouton.[2]
nice, i've actually reset my chromebook (removing crouton) a few month ago because the constant context switching annoyed me... i think ill reenable it later today and try that out
If I recall correctly, one major catch is that wl_shell has been feature-frozen since 2012 and lacks newfangled features like the ability to minimize windows. For newer functionality you need to use xdg-shell instead, which regularly changes in backwards-incompatible ways and there's no guarantee the version your application implements (or any version of it) will actually be available.
A question that may only be of interest to me: is anyone looking at getting Wayland running on Windows? In particular, interacting with the new WSL stuff?
I imagine it's possible, but complicated. You'll likely need a custom backend for your compositor - I doubt WSL implements DRM (display resource management).
WSL doesn't support the graphics stack at all. But it is possible to VNC or RDP (with xrdp as a server) into an X11 session running inside WSL, so that's what people do.
You wrote below that Wayland supports RDP. If so, it sounds like that should work?
I wrote below that Weston (a specific Wayland compositor) supports RDP and that Sway eventually will. But yes, Weston might work on Windows in that case.
Last time I tried, weston-rdp was unusuable: slow, high bandwidth usage and had trouble with key repeat (pressing a key even for a short while resulted in multiple characters).
Has anyone been able to run Chrome (or anything Electron based) on Wayland in a virtual machine? I just a black rectangle instead of Chrome/VSCode/etc.
Disabling GPU acceleration for Chrome via command line flags or for the VM entirely seems to fix it, but that's obviously a non-solution.
I'm running Fedora 25 in a VMWare Workstation 12 with a Windows 10 host.
XML has several advantages over JSON: it's much better at self-documentation and the schema validation tools are more powerful. Namespaces compose elegantly. XML has a bad reputation due to enterprise-y abuse of the technology, but that does't mean it's a fundamentally bad idea.
I never saw a nice use-case of namespaces. Maybe you can show me one?
So far I have only seen namespaces used by Inkscape to state that a SVG is a still image using 3 different name-spaces in one hierarchy. Does it not just add complexity to need to support different standards at the same time
> I never saw a nice use-case of namespaces. Maybe you can show me one?
Basic example: If you want to mix data from several formats in one document.
Let's say you want to create an RSS-feed which contains information about "new stuff" whatever that new stuff is. This "new stuff" may actually be other XML-data which can be parseable and processable by other tools (like for instance new builds, deployments, whatever). This data probably has a format of sorts individually, independent of the RSS-feed itself, which has its own well defined format.
Now let's say both the RSS-feed and the custom-data contains both a "link" element and a "title" element. Without namespaces, these are bound to collide.
Some examples of problems which then arises:
- How can a RSS-library validate that the feed format itself is correct?
- How does a RSS-feed library know which "link" elements it should process and display, instead of only ones which belongs to the feed definition?
- How does the RSS-processing library know that it should most definitely ignore that title which belongs to the deployment metadata?
- Etc etc
Namespaces allows you to combine data from different formats without ever running the risk of the data getting mixed up by whoever consumes them.
It's a really basic feature, and it's at the core of the whole eXtensible bit of XML. I'm honestly surprised by both the amount of people who find this confusing and how few people are able to realize the value of such a simple construct.
I guess too many "1337 HTML ninja rockstars" got introduced to XML as "just another angle-bracket markup format" and never actually bothered to learn anything about absolutely foundational XML basics.
> Basic example: If you want to mix data from several formats in one document.
Can you get more concrete on why you would want to mix formats? So far what I have seen namespaces were used just to extend one format.
> Now let's say both the RSS-feed and the custom-data contains both a "link" element and a "title" element.
Easily avoided if you just extend one format, but can happen if you would want to mix existing formats because of some reason.
> - How can a RSS-library validate that the feed format itself is correct?
You still need some code that parses the non-RSS part anyway, which can validate it.
Don't you usually have just one parser that parses RSS and the non-RSS at the same time?
If not, how are you passing your non-RSS XML tree-parts from the RSS-only library to the "new stuff"?
If you ever have to annotate one tree using a completely separate tool, you need to do something to ensure the names you choose are different from the ones used by whatever produces the tree. You can choose odd names, but there's no guarantee. Namespaces can provide that guarantee, via uniqueness of URIs, ultimately relying ICANN.
Almost certain this doesn't qualify as "nice", but:
Namespaces make XSLT more powerful than one might think at first, because they allow you to write XSLT that generates XSLT (and so on...) by switching a namespace to a different one upon output generation.
Of course, the result is often barely readable anymore, so there's that.
Edit: On the other hand, the difference between XSLT-namespaced elements and all the others in a stylesheet is the one thing that makes basic XSLT readable, since you don't have to use a full meta-language just to create simple elements.
> XML has a bad reputation due to enterprise-y abuse of the technology, but that does't mean it's a fundamentally bad idea.
The fact that the Javascript-world is still copying XML-techcology and ideas which was formalized, standardized and ready for use over a decade ago, should pretty much be all the proof you need for that statement.
Oh, just put an object key named "//" with your comment as the value, and change the software to ignore such keys! /sarcasm
My rage over JSON not supporting comments grows every time I have to write some config file in it. Crockford tells you, "Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser."[0]... 99% of the usecases for JSON offer no way to insert a preprocessor into that pipe.
Json il less verbose and is the de facto standard for the web, json is easier to parse by javascript (by the browser or node.js), and a serialization/deseriazation is unique, in xml you could put some infos on the attributes oand other on tags or as parameters.
instead of
<event name="gamma_size">
<arg name="size" type="uint"/>
</event>
Your example is more verbose and harder to read... XML is definitely misused in many applications where JSON is appropriate but this is not one of them.
We have TOML in the sense that TOML is currently v0.4.0 and bears an explicit warning that the specification is unstable should be treated accordingly.
That's unfortunate, but there are a lot of projects out there that depend on TOML, and it hasn't changed since 2015. It's de facto stable at this point.
It's not. It's barely more verbose than JSON and a hell of a lot more readable. JSON is appropriate for machines to talk with. XML is appropriate for writing documentation or API specs.
Thanks for the insight. Some of the comments revealed why xml was picked. I personally agree that depending on the problem you must pick the right tools and what might be a good suit in a context it might not be the best fit in another. Moreover, there are probably more mature and performant parsing libs in c for xml than for json.
However, XML might be overkill as it might be too complex for this particular scenario. XML parsing it's complicated and from time to time there are bugs in those parsers. A simpler format might also get the job done and might be safer. However XML might provide flexibility to scale.
Finally, this is what Torvalds said about XML when someone suggested to use it in git:
> XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it's a disaster to parse even for computers. There's just no reason for that horrible crap to exist.
Use wayland (with gnome) everyday myself but wanted to point out that wayland started almost 10 years ago :) The adoption has taken forever though partly because of the infinite legacy of X11 and lack of support from big players like nvidia.