Jordan SisselReading some x11 protocol code and code was pretty weird by modern standards … like, it’s mostly just writing a struct literally from memory…. Cast that lil struct to a void pointer and write it out on the socket;
Skewray Research (ZF¬C)@whack And what is amazing is that X11 works, pretty much bug free. That's why we are apparently all replacing it.
David Whittemore
poleguy looking for lost tools@whack wait... let me get this straight... you put the lime in the coconut...?
:-)
Josh Simmons@whack that's how it should work generally for wire protocols!
Marcus Müller@funkylab @whack to be clear it's not an optimization or large improvement to do it that way (unless it's a format designed for loading in-place, not applicable for a wire format mostly), I just don't think it's particularly bad either. Mid-parse validation can also be a pain so I like that separate anyway personally, but both approaches are workable.
Chris Siebenmann@whack @funkylab @dotstdy As I remember, X11 theoretically deals with endianness by having the server byte-swap everything from a different byte order client. Does this work in practice? It did once, but it's been a long time and a lot of X extensions and etc etc. I wouldn't hold my breath for completely bug-free code for that today, and I believe some of it may have been deliberately removed recently (under the 'we don't know if this works and it's not used any more' principle).
Neal Gompa (ニール・ゴンパ) 
@neal @cks @funkylab @dotstdy ehhhh 'significant security issues' was a retcon to boost Wayland's favor. Wayland was created to push pixels with less latency and without screen tearing. X11 didn't get "fixed" largely because Wayland, like any greenfield project, was more appealing to work on -- and I wouldn't blame anyone for having made that choice. They aren't dangerous by design. I say this speaking from my experience using the X11 API for almost 20 years.
@whack @cks @funkylab @dotstdy No, I'm specifically referring to the byte-swap stuff. That stuff is hard and has been a source of serious bugs.
And no, it's not really a retcon. The issues with X11's design have been known since the early 90s. There have been *books* about it. It's why NeXT and later Apple Mac OS X didn't go with X11. It's why Android didn't either.
@whack @cks @funkylab @dotstdy To be clear, I think Wayland is flawed too. The flaws are different, though. Too much minimalism has hurt things more than it helped. The antipathy for collaboration that has developed in the last decade has also been a problem.
But the core design concepts and the extensibility model is *slightly* better. They still screwed up by not defining endianness and other things in a fixed manner, but it's *easier* to fix now than it would have been with X11.
@neal @whack @cks @funkylab It's not particularly important but one really funny thing with the wayland wire protocol in particular is that they didn't think to add 64 bit integers... So you end up with stuff like this. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/presentation-time/presentation-time.xml?ref_type=heads#L247 (they really should add direct support for them to the generator though, it's kinda silly to open code it every time)
@neal yeah quite honestly, I wished that ~11 years in, the wayland community (if that *really* exists – it's more than the people writing composers) would have sat back and had been like "knowing what we know now, can we a) write a better, more comprehensive core proto spec that does away with such, and b) an alliance of desktop environments would have actually agreed on a single set extensions that people work on. The protocol is turning 18 this year, and has all signs of…
@funkylab … of embracing variety in approaches and absence of clear project direction that made Perl become a niche thing, roughly when that was 18 years old (2005). "There's more than one way to do it" isn't very helpful for protocols nor helps identify which part needs fixing/extension in case of obvious or less obvious feature gaps.
(+I don't buy "not hard, just generate the (de)serialization code", as s.o. who's worked with protobuf&capnproto&ice&thrift&ASN.1)
@funkylab @neal @whack @cks it's really not hard in the sense that which ever way you do it, it's not particularly more difficult. You have all the same problems either way, and the way you manage that complexity is the important part. Another way to put it is that the *protocol* isn't really important here, it's just an implementation problem. So replacing the protocol isn't justified by the implementation being crap.
@dotstdy "which ever way you do it, it's not particularly more difficult" does by no means imply "it's really not hard", sorry, that's just really not the case. :) and frankly, better-written specs reduce the complexity of implementing protocols in a reliable manner. So, there really *is* a difference to be made by protocol.
@funkylab I'm just saying that plenty of protocol implementations are built that way and it's fine actually. And notably, as I mentioned in the other sub-thread literally none of the issues are remotely related to this, it's all just C-isms going wrong in the implementation. I'm not going to say specs are bad, but you also don't need to change the protocol to write a spec for it. So it's mostly a "too hard, did a re-write instead" kind of thing. Which can be fine but it also has downsides.
@dotstdy @funkylab the c-level stuff is odd and the oddness goes all the way up the stack… the ultimate problem which still isn’t being solved is that x11 centralized what is now a decentralized social problem. Freedesktop ostensibly could be leading this but instead it’s this disconnected set of groups all rolling their own protocol extensions to do the same basic things… things that were known-needed (and existed!!) 20 years ago just omitted in Wayland and (input methods, EWMH, simulated input, screenshot/cast, drag-and-drop between apps, clipboard, Remote Desktop, etc etc)
And only gradually these things get remade, but from a position that hardly coordinates efforts and often ignores historical examples? We’ve got 3 input method engine protocols and the IBus maintainer is like “these are insufficient” … who is making this mess?! Two extremely different simulated input mechanisms, etc.
We took a technology problem and turned it into a social one without any leaders, then added theater that insisted an absent feature was necessary and good because that absence meant safety.
@whack @funkylab yep! And broadly the position of freedesktop such, as it is, is simultaneously that they don't have any power to tell implementors what to do (which is true), but also they they can arbitrarily block inclusion of things which they are opposed. So it's a really nasty social problem at that.
@neal I think it was 3-5 years after Wayland was announced that anyone mentioned security, and if that were honestly true, then the "security" was to build a house with no windows, doors, plumbing, and without a roof, because that's what shipped for the first *many* years. Then folks rejoice, "Yay it's finally safe!" and nobody can actually go inside. Oops. (Yes, it's been improving since Fedora shipped it 10 years ago, but that's been a *bad* 10 years)
I'm not suggesting anything of X11, just focusing on Wayland's path since ~2008.
James Just James@neal @cks @whack @funkylab out of curiosity I looked at the endinanness issues I could find too, at least 16 or so, and they're all just buffer overflows and uninitialised variables in regular ol C code, not related to endinanness except that code path isn't exercised enough so it's a bit more buggy.
hades@whack yep, that’s what everyone was doing really… Python has struct (https://docs.python.org/3/library/struct.html) and Perl has pack/unpack (https://perldoc.perl.org/functions/pack) literally to interop with this kind of protocols
