3 ms·
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
by mahkoh 5y ago
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.
- p_l 5y agoThere'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...
- floatboth 5y ago> 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!).
- p_l 5y agoNo, 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.
- shatteredgate 5y agoAny 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.
- p_l 5y agoThe 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.
- shatteredgate 5y agoFWIW 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.
- Chyzwar 5y agoWhat 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 https://www.phoronix.com/scan.php?page=search&q=Daniel+Stone
- shatteredgate 5y ago>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.