An introduction to Wayland
drewdevault.com
drewdevault.com
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.
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".
[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...
I'm only talking about software.
> legacy constraints
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.
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?
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.
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?
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.
Aside from that, it's great though. I used it for a month before going back to i3, you've really put a good amount of work into the project.
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 :)
[1] https://github.com/Cloudef/wlc [2] https://github.com/SirCmpwn/wlroots [3] https://nyantec.com/ [4] https://www.patreon.com/sircmpwn
You can actually expect that to ship in the upcoming release :)
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.
I switched from Wayland back to X due to bugs in other applications, such as Firefox.
> 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.
https://github.com/way-cooler/way-cooler https://news.ycombinator.com/item?id=14534295
[0]https://bugs.chromium.org/p/chromium/issues/detail?id=549781
[1]http://www.phoronix.com/scan.php?page=news_item&px=Google-Ch...
[2]https://nmilosev.svbtle.com/crouton-fedora-wayland-yes-pleas...
You wrote below that Wayland supports RDP. If so, it sounds like that should work?
minimize is already shoved in the debug api. sigh, in the end I really hope nobody but qt/gtk/sdl devs are even getting close to this.
https://plus.google.com/+KeithPackard/posts/azxz8ZPKght
Sadly it seems impossible to link to individual comments.
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.
https://github.com/SirCmpwn/sway https://github.com/way-cooler/way-cooler
{"type":"event", "name":"gamma_size", "arg": {"name":"size","type":"uint" }
Wayland is not the web. None of these technologies are involved in Wayland.
>{"type":"event", "name":"gamma_size", "arg": {"name":"size","type":"uint" }
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.
[gamma_size]
type = "event"
args = [
{ name = "size", type = "uint" }
]
I do agree that it doesn't matter much.
Overall, XML is too verbose; in particular, the text markup features of XML are needless complexity.
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.
The author has said as much: https://github.com/toml-lang/toml/issues/330
I didn't see XML namespaces used in the example given in the article, so I'm curious how Wayland leverages them.
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
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.
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.
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"?
Provenly incorrect.
How many RSS validators validates the contained HTML (as HTML, not as per XML well-formedness)?
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.
But hey. JSON is new and shiny!
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.
[0] https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...