I’m afraid that, while this might be a reasonable definition of “feature parity”, and I won’t argue over whether it is, there’s some stuff that is missing for a practical migration from Xorg to Arcan for current users.
For comparison, consider the Wayland migration plan. Via XWayland, it is possible for X11 clients expecting to talk to Xorg to instead talk to XWayland and not know the difference. The X11 network protocol is still present and clients can be remote. I don’t know if I’ve experienced it, but I have heard various folks report that they did not know that they were running on top of Wayland, because so much of their existing X11 tooling continued to work.
If I am interpreting your drawing API diagram correctly, then today it is possible to host an entire Arcan server as an Xorg client. This gives a possible incremental migration where users can move each application from Xorg into Arcan, and when everything is migrated, then the Xorg server can be dismantled. This also suggests a useful way that I could contribute: I could package Arcan for my distribution of choice, as a plain X11 client with no distinguishing features. Is this a reasonable view of the current state of the project?
It is worthwhile to stress that this project in no way attempts to ‘replace’ Xorg in the sense that you can expect to transfer your individual workflow and mental model of how system graphics works without any kind of friction or effort.
Wayland does not attempt to do this either. In order to make every frame a painting, the compositor gives slightly different results on-screen from what the X11 client might believe is in the pixel buffer. This disconnection is ultimately empowering to the user, to the point of Compiz, so it’s hard to argue against it, but it’s not seamless. Nonetheless, Wayland has a practical path to hosting X11 clients.
In pragmatic terms, I used to give a demonstration at the local university where I perform many X11 party tricks; the finale was to remotely invoke a Firefox instance to run on a local Xorg server. For feature parity, I would expect to be able to give the same talk with Arcan, including the same sorts of practical demonstrations. I’ve already started imagining how the talk would change if Wayland were to become the paradigm which is taught first, and it’s different, but still doable.
I’m afraid that, while this might be a reasonable definition of “feature parity”, and I won’t argue over whether it is, there’s some stuff that is missing for a practical migration from Xorg to Arcan for current users.
Hence why I begin by saying that the compatibility vector is a different subject matter altogether, and if you approach it prematurely, the entirety of the project will suffer - which is very much the case with Wayland.
There is support for wayland clients. There is support for x-over wayland clients. There is a separate Xorg (Xarcan) fork that work similarly to Xephyr. to the article on Dating my X(2016) - or this clip for that matter: https://www.youtube.com/watch?v=CIWZdEkgPfM
All those bases are covered, but also wholly uninteresting from my point of view. It is, at most, “due diligence”. If the set of current and drafted Wayland objects would be the fences to my FOSS desktop experience, I’d break my 25+ years of Linux/BSD/Solaris/… and go all in on Windows 10 in a heartbeat.
If that compatibility vector would turn out to be relevant in the grand scheme of things - I doubt it - I would rather burn a few weeks more on adding rootless mapping to Xarcan along with a scene-graph synch tactic so X window managers could manage ‘faked’ Arcan windows, but again, not much interest in that kind of work. Had I known then what I know now about Wayland internals, I would have pursued that path instead. They chose the wrong primitives from the start, and even the simple stuff is endlessly tedious and frustrating as a consequence.
Wayland does not attempt to do this either. In order to make every frame a painting, the compositor gives slightly different results on-screen from what the X11 client might believe is in the pixel buffer. This disconnection is ultimately empowering to the user, to the point of Compiz, so it’s hard to argue against it, but it’s not seamless. Nonetheless, Wayland has a practical path to hosting X11 clients.
One of the >many< problems with the rootless X transition model is that it works superficially for some 90%, then an endless stream of unpredictable breaks and more subtle quality degradation.
I could package Arcan for my distribution of choice, as a plain X11 client with no distinguishing features. Is this a reasonable view of the current state of the project?
Which distribution is that? chances are that there are people at work on it already. As for distinguishing features - even the included console WM works fine as a terminal-emulator with benefits.
In pragmatic terms, I used to give a demonstration at the local university where I perform many X11 party tricks; the finale was to remotely invoke a Firefox instance to run on a local Xorg server.
The ones I tend to do is the runtime network redirection as linked before, as well as sshing in, killall -9 arcan. Run it again from the tty and see clients coming back to life where they were. Others are using two laptops, closing the lid on the one and see the windows appear on the other - or running gnomeland on one of them, arcan/durden on the other and subjecting both to a while true; weston-terminal &; done kind of a loop. Earlier I used the drag+compose+share this thing (2013), seek to about 2:30 in.
There is something much more interesting around the corner though.
Which distribution is that? chances are that there are people at work on it already. As for distinguishing features - even the included console WM works fine as a terminal-emulator with benefits.
Do you have a list of distributions with arcan packages? I could only find that it’s supported in Void. Arch seems to have AUR packages, but no wiki page.
Hence why I begin by saying that the compatibility vector is a different subject matter altogether, and if you approach it prematurely, the entirety of the project will suffer - which is very much the case with Wayland.
Then why title your post “Arcan vs. Xorg: Feature parity”? Why should Xorg users care about the features of Arcan and whether those features can be put into correspondence with Xorg features, except for the case where Xorg users might become Arcan users?
Because explaining something mildly complicated that doesn’t fit established, strong, categories without grounding it in some frame of reference that the target audience might be able to relate to, is really hard and impossible outside the span of seconds/minutes of attention you might get as a mostly unknown and obscure figure.
A mapping from “X did it in this way, I understand that, what is Y in this space?”
Xorg is a useful technical link as its inner properties are not that hard to unpack or find coherent descriptions of, and it is the more robust such possible reference - OSX and Windows are too opaque and Android is too alien with a wider system view. Wayland is a never-ending story of “oh but it is just a protocol” (the main, mostly defunct and incomplete document referred to itself as a display server, as did the initial todos and readmes). “no that is up to the compositor” “no not the compositor object in the protocol, the compositor!”.
You could add non-accelerated drawing to Wayland with a one line addition to wl_shm defining a buffer format as SVG, wouldn’t that be interesting
A while back, both for shits and giggles and because I wanted a simple and straightforward way to debug some code that wasn’t related to drawing so I just wanted to make it easier to draw some stuff into a buffer, I did more or less that, except it was bolted to wlroots (wlroots isn’t, strictly-speaking, necessary, but it made me want to slash only my left wrist when working on Wayland code so…). It was a clunky hack that I never really turned into something more useful than a debug crutch but it worked.
It’s not an entirely unhealthy idea, certainly not the worst in wl_shm alone (though admittedly that sentence was there to troll a bit). Since it goes across a privilege boundary, there is the problem of amplification for DoS - create a SVG to starve fill-rate, and suddenly we are in heuristics land (and that is where I stopped exploring the idea in an Arcan context, then primitives and client-side tesselation makes more sense).
For Wayland there are other such magnifications (wl_region + wl_subsurface is loads of fun) though so yolo.
Is there a document that explains what Arcan is better than their about page? I couldn’t find anything with a few Google searches.
I get the feeling from their about page that it’s something that gives you the components that can build a display server, but can also build apps that draw directly to the screen without a display server (analogous to building an OS vs. an application that runs without an OS). Is this a correct understanding?
You are close. There will be two articles (as OS design and the spoiler). that go into this eventually, but it is Christmas, so here is a condensed spoiler: Look at this here ol’ thing: https://speakerdeck.com/letoram/arcan?slide=2 - now doesn’t it look familiar when you think ‘Web Browser, but for a different web?’.
This might make you more confused, but let’s try something.
‘Web Browser’ itself is a ‘bonding’ term more than anything substantial with clear boundaries – it is everything and it is nothing.
Take a gradient from two colours, say ‘green’ (“A browser is a viewer for distributed document fragments”) and ‘red’ (“A browser is an execution environment and distribution mechanism for dynamic networked client facing applications”). Red is a mouthful.
Solid green is way back in the 90ies. Bright red is in the emergency room, where we are now. Chrome and friends cover the entire gradient (with some banding artifacts) and that is why they are infinitely huge and ‘impossible for anyone to write’ and so on. What happens if you focus on just on these two primary colours, skip the decades of transition, and steal the lessons learned?.
Tech-wise - swap out Javascript for Lua – it is the more civil, simpler cousin from the countryside that is easy to sympathise with. De-couple and outsource the weird ‘binary format and linker / loader’ that is xHTML5CSSedition to someone or something else. Here is where the colour comparison breaks down a bit as you don’t even need green. A local compiler/translation step would allow greater experimentation with the beaten and abused ‘document format’, and maybe Xanadu can rise again.
Boot-strapping wise - do the Android (and ChromeOS) thing: << evil voice >> ‘That is a nice kernel you have there, too bad if something would happen to its userspace…’. Throw systemd, d-bus, gconf, pulseaudio, steam, getty, tmux, xterm, bash, qt/gtk, Xorg, … in the fire. Arcan does the same job, at the size of something a single person could demonstrably write. There’s a foundation for desktop anarchy.
I’m afraid that, while this might be a reasonable definition of “feature parity”, and I won’t argue over whether it is, there’s some stuff that is missing for a practical migration from Xorg to Arcan for current users.
For comparison, consider the Wayland migration plan. Via XWayland, it is possible for X11 clients expecting to talk to Xorg to instead talk to XWayland and not know the difference. The X11 network protocol is still present and clients can be remote. I don’t know if I’ve experienced it, but I have heard various folks report that they did not know that they were running on top of Wayland, because so much of their existing X11 tooling continued to work.
If I am interpreting your drawing API diagram correctly, then today it is possible to host an entire Arcan server as an Xorg client. This gives a possible incremental migration where users can move each application from Xorg into Arcan, and when everything is migrated, then the Xorg server can be dismantled. This also suggests a useful way that I could contribute: I could package Arcan for my distribution of choice, as a plain X11 client with no distinguishing features. Is this a reasonable view of the current state of the project?
To quote from your previous article:
Wayland does not attempt to do this either. In order to make every frame a painting, the compositor gives slightly different results on-screen from what the X11 client might believe is in the pixel buffer. This disconnection is ultimately empowering to the user, to the point of Compiz, so it’s hard to argue against it, but it’s not seamless. Nonetheless, Wayland has a practical path to hosting X11 clients.
In pragmatic terms, I used to give a demonstration at the local university where I perform many X11 party tricks; the finale was to remotely invoke a Firefox instance to run on a local Xorg server. For feature parity, I would expect to be able to give the same talk with Arcan, including the same sorts of practical demonstrations. I’ve already started imagining how the talk would change if Wayland were to become the paradigm which is taught first, and it’s different, but still doable.
Hence why I begin by saying that the compatibility vector is a different subject matter altogether, and if you approach it prematurely, the entirety of the project will suffer - which is very much the case with Wayland.
There is support for wayland clients. There is support for x-over wayland clients. There is a separate Xorg (Xarcan) fork that work similarly to Xephyr. to the article on Dating my X(2016) - or this clip for that matter: https://www.youtube.com/watch?v=CIWZdEkgPfM
All those bases are covered, but also wholly uninteresting from my point of view. It is, at most, “due diligence”. If the set of current and drafted Wayland objects would be the fences to my FOSS desktop experience, I’d break my 25+ years of Linux/BSD/Solaris/… and go all in on Windows 10 in a heartbeat.
If that compatibility vector would turn out to be relevant in the grand scheme of things - I doubt it - I would rather burn a few weeks more on adding rootless mapping to Xarcan along with a scene-graph synch tactic so X window managers could manage ‘faked’ Arcan windows, but again, not much interest in that kind of work. Had I known then what I know now about Wayland internals, I would have pursued that path instead. They chose the wrong primitives from the start, and even the simple stuff is endlessly tedious and frustrating as a consequence.
One of the >many< problems with the rootless X transition model is that it works superficially for some 90%, then an endless stream of unpredictable breaks and more subtle quality degradation.
Which distribution is that? chances are that there are people at work on it already. As for distinguishing features - even the included console WM works fine as a terminal-emulator with benefits.
The ones I tend to do is the runtime network redirection as linked before, as well as sshing in, killall -9 arcan. Run it again from the tty and see clients coming back to life where they were. Others are using two laptops, closing the lid on the one and see the windows appear on the other - or running gnomeland on one of them, arcan/durden on the other and subjecting both to a while true; weston-terminal &; done kind of a loop. Earlier I used the drag+compose+share this thing (2013), seek to about 2:30 in.
There is something much more interesting around the corner though.
Do you have a list of distributions with arcan packages? I could only find that it’s supported in Void. Arch seems to have AUR packages, but no wiki page.
You can use Repology to search a bunch of package repositories at once!: https://repology.org/project/arcan/versions
Then why title your post “Arcan vs. Xorg: Feature parity”? Why should Xorg users care about the features of Arcan and whether those features can be put into correspondence with Xorg features, except for the case where Xorg users might become Arcan users?
For what it’s worth, there is a nixpkgs issue for packaging Arcan.
Because explaining something mildly complicated that doesn’t fit established, strong, categories without grounding it in some frame of reference that the target audience might be able to relate to, is really hard and impossible outside the span of seconds/minutes of attention you might get as a mostly unknown and obscure figure.
A mapping from “X did it in this way, I understand that, what is Y in this space?”
Xorg is a useful technical link as its inner properties are not that hard to unpack or find coherent descriptions of, and it is the more robust such possible reference - OSX and Windows are too opaque and Android is too alien with a wider system view. Wayland is a never-ending story of “oh but it is just a protocol” (the main, mostly defunct and incomplete document referred to itself as a display server, as did the initial todos and readmes). “no that is up to the compositor” “no not the compositor object in the protocol, the compositor!”.
A while back, both for shits and giggles and because I wanted a simple and straightforward way to debug some code that wasn’t related to drawing so I just wanted to make it easier to draw some stuff into a buffer, I did more or less that, except it was bolted to wlroots (wlroots isn’t, strictly-speaking, necessary, but it made me want to slash only my left wrist when working on Wayland code so…). It was a clunky hack that I never really turned into something more useful than a debug crutch but it worked.
It’s not an entirely unhealthy idea, certainly not the worst in wl_shm alone (though admittedly that sentence was there to troll a bit). Since it goes across a privilege boundary, there is the problem of amplification for DoS - create a SVG to starve fill-rate, and suddenly we are in heuristics land (and that is where I stopped exploring the idea in an Arcan context, then primitives and client-side tesselation makes more sense).
For Wayland there are other such magnifications (wl_region + wl_subsurface is loads of fun) though so yolo.
Is there a document that explains what Arcan is better than their about page? I couldn’t find anything with a few Google searches.
I get the feeling from their about page that it’s something that gives you the components that can build a display server, but can also build apps that draw directly to the screen without a display server (analogous to building an OS vs. an application that runs without an OS). Is this a correct understanding?
You are close. There will be two articles (as OS design and the spoiler). that go into this eventually, but it is Christmas, so here is a condensed spoiler: Look at this here ol’ thing: https://speakerdeck.com/letoram/arcan?slide=2 - now doesn’t it look familiar when you think ‘Web Browser, but for a different web?’.
This might make you more confused, but let’s try something.
‘Web Browser’ itself is a ‘bonding’ term more than anything substantial with clear boundaries – it is everything and it is nothing.
Take a gradient from two colours, say ‘green’ (“A browser is a viewer for distributed document fragments”) and ‘red’ (“A browser is an execution environment and distribution mechanism for dynamic networked client facing applications”). Red is a mouthful.
Solid green is way back in the 90ies. Bright red is in the emergency room, where we are now. Chrome and friends cover the entire gradient (with some banding artifacts) and that is why they are infinitely huge and ‘impossible for anyone to write’ and so on. What happens if you focus on just on these two primary colours, skip the decades of transition, and steal the lessons learned?.
Tech-wise - swap out Javascript for Lua – it is the more civil, simpler cousin from the countryside that is easy to sympathise with. De-couple and outsource the weird ‘binary format and linker / loader’ that is xHTML5CSSedition to someone or something else. Here is where the colour comparison breaks down a bit as you don’t even need green. A local compiler/translation step would allow greater experimentation with the beaten and abused ‘document format’, and maybe Xanadu can rise again.
Boot-strapping wise - do the Android (and ChromeOS) thing: << evil voice >> ‘That is a nice kernel you have there, too bad if something would happen to its userspace…’. Throw systemd, d-bus, gconf, pulseaudio, steam, getty, tmux, xterm, bash, qt/gtk, Xorg, … in the fire. Arcan does the same job, at the size of something a single person could demonstrably write. There’s a foundation for desktop anarchy.