Everything in the X11 ecosystem seems to be a pile of hacks on top of hacks on top of hacks. It sometimes works pretty well and that's amazing! It's kind of beautiful in a silly way to realize how many layers of hacks are used to build the desktop experience on Linux.
I don't think terminals are much better. Fun fact about terminal escape sequences: some of them are timing-dependent. If a byte arrives too slowly, it will do something different.
The web is also a pile of hacks but at least we have multiple independent implementations and some standards.
No, it's really not. In many ways X11 is behind what the other operating systems offer, and the emphasis on backwards compatibility above all else is the reason. For example, Windows has the notion of window privilege, in which lower-privilege windows are isolated from higher-privilege windows. X11 technically has the XSECURITY extension, but nobody uses it as it breaks everything, so in practice every X11 app can keylog your browser. It's really unfortunate that the Linux community is so divided over Wayland, as from a technical perspective Wayland is sorely needed.
MS Windows manages to be binary backward compatible with win95 and in some cases even win32s. The graphics model is mostly the same as windows 3.0 . So MS has backward compatibility in spite of security.
Otoh, wayland has gaping functionality holes that MS windows has not: Screen recording is basic, normal usage. UI automation isn't that weird of a use case either.
I can't believe that this is unsolvable with some security model in wayland if the political will would be there. If a lot of people have the same complaint, and they are ignored, that's really unfortunate. Basically, Wayland should deal with reality or it will stay in limbo.
UPDATE: This post has a more harsh tone than intended. Sorry for that. I did my share of X11 programming,so I agree that something better is needed. And wayland is after years and years of no advancement a great initiative. But it pains me to see it stumble a few meters before the finish line, because of a stupid self inflicted wound.
Wayland is problematic as it goes entirely the opposite direction of X11, which means, for example, that screenshot programs and custom key binding daemons will not work.
We now understand that a program that can secretly take screenshots at will can spy on all your conversations and steal your credit card number. That isn't quite as bad as root, but, honestly, for most users it's pretty close.
Wayland is absolutely doing the sensible, conservative thing when it comes to screenshots.
No, I'm pretty sure that was always understood. What Wayland is doing -- breaking expected desktop functionality -- is not sensible at all. Window's permission model is more sensible as it actually accomplishes something.
Wayland's "fix" isn't one because on the vast, vast majority of systems any compromised program running under your uid can begin debugging another under your uid, completely circumventing any permission system Wayland tries to create. Have a root terminal logged in, or maybe open one later? Any program under your account now has root if it tries hard enough.
People started freaking out about the completely normal and expected things you could do under X11 and kneejerked themselves into the current Wayland. Maybe it will eventually be relaxed. If it isn't, I can't expected it to replace X11.
> ... and the emphasis on backwards compatibility above all else is the reason ...
Not entirely; from memory the entire X11 development team are also heavily invested in Wayland.
There was a long period of time where graphics drivers lived in userspace, in X11, and nobody could use an alternative window system. That was the way things were up until 2010-2012 era. Even then the graphics drivers in the kernel weren't in a great way.
Now the drivers in the kernel work well and the graphics stack is slowly migrating away from X11. They are moving as fast as they can without breaking things.
I want better windowing security, but I also need to be able to present my desktop in a video conference call. Expecting people to switch before they can do normal desktopy things isn't reasonable.
The fun thing about terminals is that many terminals pretend to be xterm, but in fact fail to implement some of the many, many terminal escape sequences xterm supports. So complex terminal applications pretty much need to double-check if terminals are actually xterm or if they're something broken pretending to be xterm.
Wasn’t referring to terminal compatibility as much as the “stuff that doesn’t necessarily do what it says it does”.
A big portion of most configure.sh scripts is logic that doesn’t just check for something, but that it can be trusted to do what the compiler will be expecting.
Sorry, I'm an adult, I don't need distracting bells and whistles, quite the opposite.
Windows is a poor desktop IMO. There is too much horizontal waste planting the user into a short and wide letter box that is nothing more than a portal into a malware universe.
> Fun fact about terminal escape sequences: some of them are timing-dependent. If a byte arrives too slowly, it will do something different
As someone working on a couple of different VT100 emulations, can you provide an example of this? I'm curious now, as none of the specifications I've seen mention this that I can think of off the top of my head.
Isn't cursor keys like that? If you get stalls when it sends the 4-5 byte sequence, you get to see ]^A instead of cursor moving.
Having dog slow links and tcp set to send each char instead of waiting for a whole line or packet probably helps to see it, but I'm somewhat certain the whole code for a cursor movement needs to arrive within a certain time in order for it to actually be a movement and not the individual chars.
Sounds like you might be dealing with a particular implementation quirk, or perhaps with SSH or some other network transport issue. In general terminal emulators tend to implement control character processing with a state machine:
In theory that shouldn't be affected by latency or delay in processing characters or groups of characters, and should be independent of the line speed, after all, the VT100 was able to operate at speeds between 50bits/second and 19,200 bits/second.
That said, there are so many terminal emulators out there
(xterm, gnome-terminal, linux console, just to name a few) and so many potential transport protocols (telnet, SSH, serial etc) and modern pty layers to deal with as well, so there are bound to be differences/quirks with different combinations.
Honestly, I can see why you might want two kinds of objects to pass via selection: strings, and blobs. But two is an odd number; it ought to be zero, one, or infinite. Zero doesn't help, and one would be hijacked by incompatible systems that would have to guess "are they going to want a JSON representation of this, or a MIME type followed by base64 encoded data?", so I guess that an updatable registry of types would be ok, just really unwieldy, and ... nightmares to follow.
Horses have an even number of legs. Behind they have two legs, and in
front they have fore-legs. This makes six legs, which is certainly an
odd number of legs for a horse. But the only number that is both even
and odd is infinity. Therefore, horses have an infinite number of
legs. (from fortune).
I don't think terminals are much better. Fun fact about terminal escape sequences: some of them are timing-dependent. If a byte arrives too slowly, it will do something different.
The web is also a pile of hacks but at least we have multiple independent implementations and some standards.
The mess is beautiful. Keep adding layers.