Hacker News Reader

Comment by DyslexicAtheist | Hacker News Reader

> one of the (several) motivations for creating Wayland was to fix the security issues with X11

security was only a footnote in the list of arguments of why X has/had to go.

X11 maintainer Daniel Stone's[0] very funny but also educational talk[1] from 2013 linux.conf.au has a lot of the gory details that make you say thank fuck and good riddance. The talk will make you feel truly grateful instead of nostalgic. Anyone who missed the 3 decade long discussion of why X is bad give it a go (it'll put good cheer in your heart I promise).

> I'm also not convinced that the X server can't be extended in other ways to fix other deficiencies.

it's not about whether anyone _can_ but if anyone should and is willing to do so is the right question (that Daniel's talk answers).

BUT X IS THE UNIX WAY! << so what is the 1 thing X does, and what is it doing well?

[0] https://www.fooishbar.org/about/

[1] https://www.youtube.com/watch?v=RIctzAQOe44

View on HN

> BUT X IS THE UNIX WAY! << so what is the 1 thing X does, and what is it doing well?

Provide an X server :-P.

The Unix Philosophy not only isn't really a philosophy but also isn't meant to be a dogma - it is meant to be a guideline that, when it makes sense, can be bent.

For example not even the original Unix kernel followed the Unix philosophy because sometimes you need some programs to do more than one things - often in order to enable other programs focus on their "do one thing well" aspect (e.g. window managers).

>so what is the 1 thing X does, and what is it doing well?

That... Isn't entirely fair. UNIX Philosophy is usually applied at the program level. You're talking the entire X stack, which, like it or not, started as "Network agnostic graphical computing" which was composed out of a handful of programs, and a protocol.

Now. We all know it isn't that now; and I don't buy that it's all X's fault. You have what, going on 40 years worth of dead ends there, that obviously someone thought was going to be important at some point, but which also were emergent outcomes of a bunch of companies doing, among other things, pursuing their own ends without tipping their hand to everyone else trying to yoink an idea or two. If you don't think X suffered for it, I'd like to point you at the rats nest of abstractions you end up having to navigate. And no, a compositor doesn't magically make it go away. Further, how many people here discussing/developing/opining have read, understood and reasoned about the source as a whole to the point of actually getting something working?

I'd wager not many. Next time I have a few months, it's on my TODO list. I have gone through the X.Org Dev docs a couple times though. Need to probably print it out and do some bookmarking to build up my haptic recall model for it.

This. Anyone who is thinking of posting "but muh network transparency" or some other tired old argument needs to stfu, watch Daniel Stone's talk, and realize that literally everyone with knowledge of the Linux graphics stack feels the exact same way. X is the internal combustion engine of window systems: it's really bad and it's got to go; give or take epsilon literally 100% of domain experts have known it's got to go for decades; yet here we are still stuck with it.

You WILL be running a Wayland desktop in the near future. Xorg itself is already unmaintained abandonware. The next step is deprecating and removing X support from the major toolkits. Beyond that, who knows. Probably Xwayland itself will be deprecated and removed too.

Best to suck it up, burn your X config to the ground, and start afresh with Wayland. If it's janky, submit bug reports or PRs. Just rip the band-aid off already, because nobody wants to hear your hemming and hawing when the axe finally comes for X.

The linked talk is full of half truths and misinformation by omission and already was when I first watched it in 2013. Most significantly the speaker conflates the X protocol and Xlib which nobody was using to write new software even back then. He says that gedit performs lots of blocking calls during startup. That's a problem of Xlib. With XCB you can perform all of these calls in parallel. He says that referring to an object that doesn't exist causes your program to abort by default. That's a problem of Xlib. With XCB, this simply returns an error that you can handle like you would do with any other API. He gets called out for this by one of the attendees but brushes it away with "but it's really hard to do". It's actually not.

I'm not going to go over the whole video since it was primarily made for entertainment and therefore any point can be defended by "he was exaggerating for comedic effect". Invoking this video is akin to invoking late night tv hosts when talking about politics.

And then of course he also has some valid points which are unfortunately diminished because the uninformed watcher will not be able to distinguish them for the invalid points.

There's also the little discussed part that XFree86/X.Org was the lowest common denominator implementation, and never really put resources into fixing many issues, while creating various problematic workarounds over time. And lo, toolkits ended up pushing for more and more "just let me blit"...

Meanwhile Wayland's design results in people writing hotkeys as root-running programs that hijack input devices at low level, because the whole system is incapable of providing such feature in pluggable way...

> the whole system is incapable of providing such feature in pluggable way

No, the system is perfectly capable, it's just hard to get all compositor authors to agree on a common protocol (and to agree that it's necessary in the first place). Big DEs especially prioritize regular-user usability features (e.g. currently lots of work on IMEs) rather than fancy nerd customizations that don't always need to be a common external program that works with all compositors (is it really a problem to write a plugin for your DE specifically? No!).

No, the system is designed for centralizing everything in one process, and biggest pusher is uninterested in cooperating with anyone else.

And ability to have global hotkeys is not fancy nerd customization. Writing a plugin is also a much more harrowing experience when any bug might take down your entire graphics stack due to above mentioned centralization by design.

Any mechanism that allows you to listen to hotkeys at will is about as insecure as running a program as root that snoops keys; either way you're vulnerable to keyloggers. The X implementation is quite insecure as well as having a number of other usability issues. I understand your complaints about Wayland but there has just never been any API for this that I've seen on any Linux window system that is actually secure, it just doesn't exist right now. If a secure API is ever implemented, it will probably be made to work with Wayland somehow.

The point is that Wayland architecture is designed to discourage such API, secure or not (I'll also have to check, but AFAIK Wayland went with even less security support in protocol than X11[1] - not XFree/XOrg - so retrofitting is even harder). Same with accessibility et al.

Honestly, Wayland by design feels like MVP that forgot that outside certain limited systems they are missing a lot of "filler" APIs, and somehow assumed it would magically happen by itself. Unfortunately there's no DCOM on Linux in practice, and D-Bus is much more annoying to program against, so the expected "do it in D-Bus" never materialized (and was supposed to cover even things like copy-paste in the original discussions).

[1] X11 servers from vendors other than XFree/XOrg had things like advanced access controls over what applications could do, some integrated with OS-wide Mandatory Access Controls. There's also the forgotten (by most) part of the protocol for secure entry that one is supposed to use when accepting passwords and the like.

FWIW I think the goal has been to put security in some other layer that's more appropriate. You can add those type of APIs to Wayland but you'd have to also implement a security mechanism, which is non-trivial. D-Bus can be the most secure option for some things but not here, there might have been a plan to put the clipboard in D-Bus but I believe that got scrapped because it was found to be less secure; Wayland implementations are supposed to validate access to the clipboard based on the most recent input event, to prevent background applications from snooping on the clipboard.

Personally for me I do find D-Bus to be easier to program than Wayland though, the libraries for it are a lot more mature. You might want to try something like pydbus or systemd's sd_bus, or the Rust library zbus. Those are some of the better implementations I've seen.

X11's security mechanisms were never really complete, I don't know of any distribution that actually uses those Mandatory Access Control schemes. Distributions that focus around X security (e.g. Qubes) all seem to use X sandboxing now which should work better than MAC-based security but is quite complicated to set up and still not practical for most other distributions to use. I remember seeing some MAC-based proposals for Wayland but they never caught on because the focus there has also moved to sandboxing.

>There's also the forgotten (by most) part of the protocol for secure entry that one is supposed to use when accepting passwords and the like.

AFAIK there is no special part of the protocol for this and this was never really a good solution. It's just done using an ordinary keyboard grab, which are mostly considered an insecure API that does nothing in practice because all the other X security schemes will try to disable or restrict grabs for security reasons.

Ah yes, security through magic fairy. To their credit, at least they went with "you can't break security through nonexistant feature", except a lot of those features tend to be critical for open desktop.

D-Bus is still way more problematic to work with than DCOM. Even on the operation model (something that generic libraries will always have hard time papering over).

As for the X11 extensions - no Linux distro (at least on open market). Because XFree86/X.Org != X11. In fact, XFree86 was essentially lowest common denominator, using with little change a design that wasn't specially good back in 1992. Even if glamor helped some of it, it was more a bandaid than rearchitecting the server (which could have been done without changing protocol).

What did you contribute to X?

I kind of trust Daniel Stone way more that some rando from internet? https://www.phoronix.com/scan.php?page=search&q=Daniel+Stone

>conflates the X protocol and Xlib which nobody was using to write new software even back then.

They are mostly synonymous, there is a large amount of software using Xlib that will likely not ever be rewritten to use XCB. And Xlib is still a better option than XCB if you want to use any client libraries because those all require Xlib.

>He gets called out for this by one of the attendees but brushes it away with "but it's really hard to do". It's actually not.

With GTK applications like gedit, it actually is because those are in the category of "won't ever be updated to use XCB". IIRC somebody even tried to port GTK to XCB once and the patches were never merged because it broke everything. XCB is nice for some things but comes with its own set of issues. Please also keep in mind that if you're suggesting the only reasonable solution is to rewrite every client to use a new library, that comes with about the same difficulty as porting to Wayland.

Who uses just one computer? When everything targets a web UI because it’s the only choice on the network, do I still need a compositor to host a browser and nothing else?

Reply on news.ycombinator.com