> Ultimately it appears to be software with more fans than productive users.
Correct. You can swing productive usage of Durden and the rest of the kit in its current state, but it's still an experimental piece of software under active research and development. As it stands, it's more attractive to daily drive xorg as a default while keeping arcan around to hack on and experiment with.
It's been rapidly closing the gap towards usability over the last few development cycles. I can speak for myself as tentatively waiting for 1.0 before abandoning xorg totally, which is at least a few years away.
Despite having read about it multiple times I still don't feel like I know what it is. My best guess is that it's an operating system, minus the kernel? But also it can be used as a GTK/Qt type interface layer? Or it can be used to replace X/Wayland? So like, a super modular operating system? And now I guess it's also a web browser, or a generalization of web-browser-like things that may or may not actually be compatible with the traditional web?
You're close! I'd recommend checking out this blog post which frames it as such and goes into motivations and how the architecture ends up panning out at a high level:
I love the idea of arcan, I like how as a counter point to waylands "X went to hard, the display server should be a dynamically linked shared object" there is one solitary guy doing his own thing saying "X did not go hard enough we need an even more seamless, recursive solution to move our display between different devices" and doing amazing work on this problem.
But just like plan9 I have a hard time actually doing anything with it. Achingly beautiful software, but just a little to different and obscure. And I say that as an OpenBSD daily driver, where apparently I thrive on the pain that comes from using an obscure system.
But I am currently back on the plan9 kick, seeing if I can get it to stick this time. I may give arcan another try as well.
> But just like plan9 I have a hard time actually doing anything with it.
For me Plan 9 isn't about daily driving or how useful it currently is, rather, It's for exploring a new way to build software. There are lots of pieces missing but that's the fun part, you get to build them!
As for daily driving, 9front has vmx(8) so you can run virtual machines on supported Intel hardware. I know a dev who runs Linux (I think OpenBSD too) in vmx using VNC to run a browser. 9front Drawterm also has a few tricks to work in reverse where the Linux resources are exported to the Plan 9 workstation.
Edit, I should also mention that Arcan is close to how I would envision building a web OS using Inferno: don't start with a browser, start with a highly portable OS who's user space lives in a VM.
Even the style of writing screams "I'm doing something weird and I'm not going to explain it to you unless you are already a mega-fan". Reminds me of Wolfram's writing a bit. He's created a world that only he is in and then writes about it in detail as if everyone else is there too.
Arcan is a display server, in the category of X, wayland or rio
The focus of arcan is to make the final display target super flexible.
So X was designed to be network agnostic, the programmer could use the same protocol and depending on how the end user had it configured it could be displaying on the same machine as the program via local shared objects or on a remote machine via tcp. But X never was able to dynamically transition between the two, there was no way for X to move a window from one machine to another. This is a core goal of the arcan project. I think the thing that gets people confused is along the way there is also a lot of adjacent experimentation in really wild window managers and control scripts. That is, what crazy things can you do once you have this amazing window location flexibility.
The most confusing thing about it is that it's supposed to be a 'display server crossed with a game engine', which to me implies that it should have tons of flashy demos, as its a very visible component, yet I only see slide after slide that arguing that it is the future.
I like Nix as well, you can use this one liner in OSX or Linux to try out arcan/durden/cat9, as it matures you can expect arcan applications to be made available the way html pages/apps and this kind of nix derivation would let you run the "browser":
The vision of "one desktop, many devices" (https://www.divergent-desktop.org/blog/2026/01/26/a12web/#a1... ) seems perfect for cloud hyperscalers to own all of compute. Your desktop will be in the cloud, the only computer with enough CPU power and RAM to run your stuff, and you will be allowed to access your desktop from any device you license from the cloud hyperscaler.
I already have that with my Apple devices, kind of. I can drag my mouse from my MacBook Pro to my iPad, use my iPad (or Vision Pro) as a secondary monitor, or the same with my Mac mini, I can start a document on one platform and continue it on another…
All in all I love the ecosystem, it’s very convenient.
As a separate note, I don't see how A12 Web (https://www.divergent-desktop.org/blog/2026/01/26/a12web/#a1... ) is different from the current web, where (Javascript) apps are downloaded and run locally (in your web browser) all the time. There are some additional checks for digital signatures and package integrity, which are typically taken care of by HTTPS in the current web.
Author's inspirations are BBS + 'offline first", and together, this produces something like Android Instant Apps. On first visit, your client downloads some remote code, as a signed package. Then the code gets run, and it can only talk back to the originating server.
The overall result gives all powers to server owners, and IMHO is pretty terrible for users. Definitely much worse than current web, UX-wise.
- There is forced, instant auto-update. You don't get to postpone updates, and in fact, there is a system for real-time update of all of the clients.
- There is no inner links by design. It's like being in giant SPA, bookmarks are useless.
- User has zero power of customization (unless author designs a system for it). Adblock? Nope. Increase font size or change to more legible font? Not with A12. Custom userstyles? Not here.
- Oh, and if you want to extract information, there is no convenient HTML representation to parse, or an API to intercept. It's all internal state, driven by server. Maybe start reverse-engineering stuff.
- Special mention for search: it's all under server owner control. Server has to provide index for search engines, and inside page, implement Ctrl-F if they feel like it. There is no way to ensure that the index is up to date, nor that it actually has any relation to site's contents.
- About cookies and privacy: each user gets identity, and it is immediately sent to a server at each connection. That identity is salted so it's different between app, but within app, it's permanent.
I'll give credit to the author, it is very much like BBS. As a user, this makes me appreciate how great the current web is, even with all its downsides.
As a special mention, there are some _weird_ claims in here...
- Apparently "eval()" is disabled, to prevent "‘middleboxes injecting code’ adtech style tampering." I had to read this twice and check the calendar.. it's 2026, the last time middleboxes could inject code was over a decade ago, before https was everywhere.
- The only allowed connections are to originating host ("directory"), and it has to proxy whatever resources it has. It is no longer possible to keep control of HTML and offload large files to CDN - if you want CDN, you go all the way in and surrender all control.
(Author claims this means "request record/replay is trivial for both archival and development purposes.", but unless the script is fully deterministic, any application can easily defeat archival replay by putting a changing number into request and expecting it back. This is, again, 100% inline with author's vision of user having no control)
- Author talks a lot about local-first, and you can bundle media with code in initial downloads. But many examples are of regular remote apps. "image sharing" app which loads images on-demand. A video player which can only stream videos. A complex app which is backed by VNC-like remote desktop connection. None of this is local-first!
stoplight161 | a day ago
sho_hn | a day ago
Ultimately it appears to be software with more fans than productive users.
ux266478 | a day ago
> Ultimately it appears to be software with more fans than productive users.
Correct. You can swing productive usage of Durden and the rest of the kit in its current state, but it's still an experimental piece of software under active research and development. As it stands, it's more attractive to daily drive xorg as a default while keeping arcan around to hack on and experiment with.
It's been rapidly closing the gap towards usability over the last few development cycles. I can speak for myself as tentatively waiting for 1.0 before abandoning xorg totally, which is at least a few years away.
idle_zealot | a day ago
ux266478 | a day ago
https://arcan-fe.com/2021/09/20/arcan-as-operating-system-de...
somat | a day ago
I love the idea of arcan, I like how as a counter point to waylands "X went to hard, the display server should be a dynamically linked shared object" there is one solitary guy doing his own thing saying "X did not go hard enough we need an even more seamless, recursive solution to move our display between different devices" and doing amazing work on this problem.
But just like plan9 I have a hard time actually doing anything with it. Achingly beautiful software, but just a little to different and obscure. And I say that as an OpenBSD daily driver, where apparently I thrive on the pain that comes from using an obscure system.
But I am currently back on the plan9 kick, seeing if I can get it to stick this time. I may give arcan another try as well.
MisterTea | a day ago
For me Plan 9 isn't about daily driving or how useful it currently is, rather, It's for exploring a new way to build software. There are lots of pieces missing but that's the fun part, you get to build them!
As for daily driving, 9front has vmx(8) so you can run virtual machines on supported Intel hardware. I know a dev who runs Linux (I think OpenBSD too) in vmx using VNC to run a browser. 9front Drawterm also has a few tricks to work in reverse where the Linux resources are exported to the Plan 9 workstation.
Edit, I should also mention that Arcan is close to how I would envision building a web OS using Inferno: don't start with a browser, start with a highly portable OS who's user space lives in a VM.
timhh | a day ago
Even the style of writing screams "I'm doing something weird and I'm not going to explain it to you unless you are already a mega-fan". Reminds me of Wolfram's writing a bit. He's created a world that only he is in and then writes about it in detail as if everyone else is there too.
somat | a day ago
The focus of arcan is to make the final display target super flexible.
So X was designed to be network agnostic, the programmer could use the same protocol and depending on how the end user had it configured it could be displaying on the same machine as the program via local shared objects or on a remote machine via tcp. But X never was able to dynamically transition between the two, there was no way for X to move a window from one machine to another. This is a core goal of the arcan project. I think the thing that gets people confused is along the way there is also a lot of adjacent experimentation in really wild window managers and control scripts. That is, what crazy things can you do once you have this amazing window location flexibility.
torginus | 6 hours ago
[OP] ingenieroariel | a day ago
nix run --impure 'git+https://codeberg.org/ingenieroariel/arcan?ref=nix-flake-buil...'
warkdarrior | a day ago
frizlab | a day ago
All in all I love the ecosystem, it’s very convenient.
warkdarrior | a day ago
theamk | 4 hours ago
So basically no adblock and no customization unless remote server's owner allows it.
cyberge99 | 23 hours ago
theamk | 19 hours ago
The overall result gives all powers to server owners, and IMHO is pretty terrible for users. Definitely much worse than current web, UX-wise.
- There is forced, instant auto-update. You don't get to postpone updates, and in fact, there is a system for real-time update of all of the clients.
- There is no inner links by design. It's like being in giant SPA, bookmarks are useless.
- User has zero power of customization (unless author designs a system for it). Adblock? Nope. Increase font size or change to more legible font? Not with A12. Custom userstyles? Not here.
- Oh, and if you want to extract information, there is no convenient HTML representation to parse, or an API to intercept. It's all internal state, driven by server. Maybe start reverse-engineering stuff.
- Special mention for search: it's all under server owner control. Server has to provide index for search engines, and inside page, implement Ctrl-F if they feel like it. There is no way to ensure that the index is up to date, nor that it actually has any relation to site's contents.
- About cookies and privacy: each user gets identity, and it is immediately sent to a server at each connection. That identity is salted so it's different between app, but within app, it's permanent.
I'll give credit to the author, it is very much like BBS. As a user, this makes me appreciate how great the current web is, even with all its downsides.
As a special mention, there are some _weird_ claims in here...
- Apparently "eval()" is disabled, to prevent "‘middleboxes injecting code’ adtech style tampering." I had to read this twice and check the calendar.. it's 2026, the last time middleboxes could inject code was over a decade ago, before https was everywhere.
- The only allowed connections are to originating host ("directory"), and it has to proxy whatever resources it has. It is no longer possible to keep control of HTML and offload large files to CDN - if you want CDN, you go all the way in and surrender all control.
(Author claims this means "request record/replay is trivial for both archival and development purposes.", but unless the script is fully deterministic, any application can easily defeat archival replay by putting a changing number into request and expecting it back. This is, again, 100% inline with author's vision of user having no control)
- Author talks a lot about local-first, and you can bundle media with code in initial downloads. But many examples are of regular remote apps. "image sharing" app which loads images on-demand. A video player which can only stream videos. A complex app which is backed by VNC-like remote desktop connection. None of this is local-first!