I hope to have some spare time over the next six months to look a bit more seriously at Arcan. Do you have any pointers for people wanting to poke at the code?
After the next release* I promised some people to finish the exercise series with the more advanced stuff, as quite a few has finished the beginner ones: https://github.com/letoram/arcan/wiki/Exercises
*a week or two away depending on my progress with getting Xarcan to allow old window managers to be reused
The FreeDesktop project had a bunch of things to abstract over differences between platforms, which the major Linux distros decided were unnecessary complexity and replaced with direct use of Linux-specific interfaces. It’s a bit depressing to see how quickly they shifted from caring about portability when their favourite platform was a minority to actively working against it once this was no longer the case.
So Wayland is still not finished defining the basics (currently: what’s a colour, really? later: when does a pixel map to which colour? even later: so about that alpha channel) for .. a window after so many years of ‘trying to get it right’. It’s less than a month since last different fractions again gaslit eachother about if the buffers should contain decorations or not (123)
One of the funny things is that sharing from source to sink is somewhat defined, if and only if the source is a client. The other direction, with the server (“compositor”) acting as source either as full buffers, composited or corrected results or slices thereof are ‘out of scope’.
That’s the “Wayland doesn’t support screen sharing” argument (which is a singular use case, but with the audience we’re stuck with first order forms). This is where the peanut gallery comes and say “hah! we use Pipewire for that”. Yes, reinventing the arguably hardest part (the mechanics of the IPC system) forcing you to use two different ones seems like a great idea. Another 20kloc of C code (about the IPC part of Pipewire) you shouldn’t think too hard about the implications of.
Alas the designs doesn’t compose. At all. You need a bunch more metadata and context for all the other useful desktopy sharing things, to define what is shared and here you get xdg_desktop_portal. This hails from FlatPak (uh oh) and pulls in D-Bus. Now we’re up to three IPC systems.
D-Bus alone was instrumental in killing the prospects of X11 network transparency. Since “design” in Wayland is whack-a-mole features one at a time spread beyond the widest of attention spans (dissonance by lack of design) without guiding principles. This, of course, is repeated with the networking protocol that is hidden in Waypipe (which looks eerily similar to what DCOM had to do with COM).
So say you want to run Firefox transparently.You run Waypipe that proxy-patches wayland objects and fills in ‘implementation defined’ blanks (e.g. dma-buf, file descriptors for keymaps and clipboard transfers and ..) to work across the network. This completely lacks CIA so you need to tunnel through SSH. Let’s ignore the security implications of that. Now any of the basic integration features something like Firefox has, File picking? oops, xdg-desktop-portal will sideband that through D-Bus so you’ll save and load from the wrong computer. Same for desktop sharing; for screenshots; for a11y tools.
But this is just a simplified current state of affairs. We’ll see if Kettenis et al. will be up for stubbing/translating that mess as well. Prediction time.
More clients will use the portal / pipewire sidebands to gradually migrate away from Xorg.
These will become necessary dependencies for popular applications, their absence won’t be tested, debugged or supported.
The synch bugs getting this cacophony of IPC systems to play nice becomes a triageing nightmare and workarounds rather than fixes will be abundant.
Toolkits will be forced to make Xwayland (which has a serious design problems of its own) specific workarounds which is now maintained out of synch with other Xorg DDXes.
Applications running fine on Xorg-xwayland-xdg-… won’t work on “pure” Xorg-xfree86/Xorg-modeset/…
D-Bus alone was instrumental in killing the prospects of X11 network transparency
This is such a shame, because D-BUS was originally meant to add network transparency in places where X11 didn’t (sound, file access, and so on). D-BUS was always meant to be agnostic to the underlying protocol. It has a mechanism for providing file descriptors, but a distributed version could provide these as streams at a remote end (I remember someone talking about adding D-BUS support to SSH so that it could just add SSH channels as file descriptor endpoints for proxied file descriptors).
Now any of the basic integration features something like Firefox has, File picking? oops, xdg-desktop-portal will sideband that through D-Bus so you’ll save and load from the wrong computer.
I think that’s a problem that’s somewhat intrinsic to the underlying problem. If I run a program on a remote machine, it’s unclear whether I want to give it access to my local files or the remote machine’s files. You need a capability mechanism (yes, I know you have one of those!) and a way of exposing namespaces.
5+ years earlier .. https://arcan-fe.com/2018/04/25/towards-secure-system-graphics-arcan-and-openbsd/
@qbit added the wayland service transport to the port last fall if I recall correctly, with twitter memory hole:ing things it’s hard to know.
I hope to have some spare time over the next six months to look a bit more seriously at Arcan. Do you have any pointers for people wanting to poke at the code?
https://arcan-fe.com/2018/10/31/walkthrough-writing-a-kmscon-console-like-window-manager-using-arcan
I’d go up to / including part 4 to understand enough of the server end, then work from the client side - https://github.com/letoram/arcan/blob/master/tests/frameservers/counter/counter.c
After the next release* I promised some people to finish the exercise series with the more advanced stuff, as quite a few has finished the beginner ones: https://github.com/letoram/arcan/wiki/Exercises
*a week or two away depending on my progress with getting Xarcan to allow old window managers to be reused
!! Exercises! sweet! I didn’t know about these :D - Thanks!
I was semarie@ who enabled it : https://github.com/openbsd/ports/commit/0150291b1a3b6581d1519c18d130d81b43e52d16 :D
Sad to see how many linuxisms are present in the ecosystem that need to be stubbed out
The FreeDesktop project had a bunch of things to abstract over differences between platforms, which the major Linux distros decided were unnecessary complexity and replaced with direct use of Linux-specific interfaces. It’s a bit depressing to see how quickly they shifted from caring about portability when their favourite platform was a minority to actively working against it once this was no longer the case.
It’s going to get much worse. For everyone.
So Wayland is still not finished defining the basics (currently: what’s a colour, really? later: when does a pixel map to which colour? even later: so about that alpha channel) for .. a window after so many years of ‘trying to get it right’. It’s less than a month since last different fractions again gaslit eachother about if the buffers should contain decorations or not (1 2 3)
One of the funny things is that sharing from source to sink is somewhat defined, if and only if the source is a client. The other direction, with the server (“compositor”) acting as source either as full buffers, composited or corrected results or slices thereof are ‘out of scope’.
That’s the “Wayland doesn’t support screen sharing” argument (which is a singular use case, but with the audience we’re stuck with first order forms). This is where the peanut gallery comes and say “hah! we use Pipewire for that”. Yes, reinventing the arguably hardest part (the mechanics of the IPC system) forcing you to use two different ones seems like a great idea. Another 20kloc of C code (about the IPC part of Pipewire) you shouldn’t think too hard about the implications of.
Alas the designs doesn’t compose. At all. You need a bunch more metadata and context for all the other useful desktopy sharing things, to define what is shared and here you get xdg_desktop_portal. This hails from FlatPak (uh oh) and pulls in D-Bus. Now we’re up to three IPC systems.
D-Bus alone was instrumental in killing the prospects of X11 network transparency. Since “design” in Wayland is whack-a-mole features one at a time spread beyond the widest of attention spans (dissonance by lack of design) without guiding principles. This, of course, is repeated with the networking protocol that is hidden in Waypipe (which looks eerily similar to what DCOM had to do with COM).
So say you want to run Firefox transparently.You run Waypipe that proxy-patches wayland objects and fills in ‘implementation defined’ blanks (e.g. dma-buf, file descriptors for keymaps and clipboard transfers and ..) to work across the network. This completely lacks CIA so you need to tunnel through SSH. Let’s ignore the security implications of that. Now any of the basic integration features something like Firefox has, File picking? oops, xdg-desktop-portal will sideband that through D-Bus so you’ll save and load from the wrong computer. Same for desktop sharing; for screenshots; for a11y tools.
But this is just a simplified current state of affairs. We’ll see if Kettenis et al. will be up for stubbing/translating that mess as well. Prediction time.
(6. IBM pulls the plug on RH desktop funding ..)
This is such a shame, because D-BUS was originally meant to add network transparency in places where X11 didn’t (sound, file access, and so on). D-BUS was always meant to be agnostic to the underlying protocol. It has a mechanism for providing file descriptors, but a distributed version could provide these as streams at a remote end (I remember someone talking about adding D-BUS support to SSH so that it could just add SSH channels as file descriptor endpoints for proxied file descriptors).
I think that’s a problem that’s somewhat intrinsic to the underlying problem. If I run a program on a remote machine, it’s unclear whether I want to give it access to my local files or the remote machine’s files. You need a capability mechanism (yes, I know you have one of those!) and a way of exposing namespaces.