Arcan

How about Arcan? [0] It seems very well reasoned, has stable API, excellent backwards compatibility and does not require GPU and i5 as this one might? Its author also has proven record and actual experience, which I'm not sure authors hpf TFA have, judging solely from their writing. 0: https://arcan-fe.com/

Nicely ranted. I'm one who feels that ranting is a kind of art (or can be profitably interpreted that way), and well-formed rant counts as art. This is a good rant, not great, but heartfelt and sincere with judicious use of curse words and rhetorical flourish. (For greatness in ranting see the work of Mickens, perhaps our finest performing ranter of the day. https://mickens.seas.harvard.edu/wisdom-james-mickens ) - - - - On a tangent, I've been keeping an eye on the Arcan project https://arcan-fe.com/ > Arcan is a powerful development framework for creating virtually anything between user interfaces for specialised embedded applications all the way to full-blown standalone desktop environments. > At its heart lies a robust and portable multimedia engine, with a well-tested and well-documented interface, programmable using Lua. (Nothing against Wayland, I'm just mentioning it to say something potentially useful to someone.)

Not to stand up for Claude Code in any way, I don’t like the company or use the product. This is just a related tangent- one of my favorite software projects, Arcan, is built on the idea that there’s a lot of similarities between Game Engines, Desktop Environments, Web Browsers, and Multimedia Players. https://speakerdeck.com/letoram/arcan?slide=2 They have a really cool TUI setup that is kinda in a real sense made with a small game engine :) https://arcan-fe.com/2022/04/02/the-day-of-a-new-command-line-interfac…

Take a look at Arcan, it supports both X11 and Wayland (and I think other protocols too). https://arcan-fe.com/

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: https://arcan-fe.com/2021/09/20/arcan-as-operating-system-design/

Nope, because we already could have had that with VR/AR glasses, and while there are some (even impressive) options now, they aren't mainstream. Neither are the 'apps', nor the content interoperable, exchangable. Furthermore I see nothing wrong with the desktop metaphor, it's just that we mostly only had a miserable magnifying glass, giving only a small viewport into a crammed childs toy, instead of real large high-resolution screens as can be had now, or sensible virtual desktops for more common sizes. To be expanded by "Metisse", an early 2.5D extension for FVWM, and later "User Interface Faćades". Maybe with some Zoomable UI sprinkled on top, like in https://eaglemode.sourceforge.net/ or whatever the clandestine weirdos from https://arcan-fe.com/ may come up with. (IF. EVER.)

Wayland made writing WMs needlessly hard, and the benefits of Wayland were frankly not real - most of the reasons given in 2011 were patched in to X11 later. All the Wayland rewrite got us was a situation where Wayland is both bleeding-edge and obsolete simultaneously. Say what you like about X11, but by the time people unironically pushed for mass Wayland adoption, X11 was stable and boringly so. The future of WMs is, IMO, Arcan - https://arcan-fe.com/ - but that's an ambitious project and I don't blame the main developer for deliberately going out of his way to avoid advertising it before it's ready. In the meanwhile, Wayland and X11 both more-or-less work with the occasional major pain in the ass.

Maybe might be appropriate in this discussion: https://arcan-fe.com/ I hope this project will produce some usable new UX at some point.

Two interesting projects in that space: - https://arcan-fe.com/ which introduces a new protocol for TUI applications, which leads to better interactions across the different layers (hard to describe! but the website has nice videos and explanations of what is made possible) - Shelter, a shell with reproducible operations and git-like branches of the filesystem https://patrick.sirref.org/shelter/index.xml

Chisnall has stated several times over on Lobsters that he's thinking of basing is future project on Arcan (https://arcan-fe.com/). It's a very interesting project.

You should take a look at arcan, it's almost exactly that: http://arcan-fe.com - https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lashcat9/ - https://arcan-fe.com/2024/09/16/a-spreadsheet-and-a-debugger-walks-int… I am not using it as a daily driver, because, emacs, but I keep an eye on it because, well, emacs.

So cool! I'd never thought about a spreadsheet interface for the shell, but it makes total sense. The other demos (a little more than halfway down the page) are amazing too: https://arcan-fe.com/2022/04/02/the-day-of-a-new-command-line-interfac…

A lot of this seems like it's done by Arcan (https://arcan-fe.com)

You might be interested in Arcan desktop engine ( https://arcan-fe.com ), which has a tui api for clients. It has been used to build an interesting experimental shell: https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lashcat9/

kragen, what's the current status of BubbleOS? Also, I'm curious what you think of Arcan (https://arcan-fe.com)

See https://arcan-fe.com/, in particular Lash: https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lashcat9/

FWIW, you can pipe graphics (sort of) with arcan[1]. So its not like the ideas have been abandoned. 1. https://arcan-fe.com/

That's the intended use case for Arcan [0] iirc [0] https://arcan-fe.com/

This isn't quite that, but I can never not link to https://arcan-fe.com/ in cases like this. He even updated today!

> The fact is, Wayland is the only viable X11 successor There's at least one other option in the running, Arcan: https://arcan-fe.com/

It's not implausible, there's ready Arcan https://arcan-fe.com/

Alternate summary, from https://arcan-fe.com/2018/05/31/revisiting-the-arcan-project/ > the ‘elevator- pitch’ to the modern tweet-length attention spanned reader goes as follows: > Arcan is a curious blend of a streaming multimedia processor, game engine and display server with a novel design that lends itself well for both complex and simple realtime interactive graphics projects alike, and goes well with anything from Sci-Fi UIs for some homegrown embedded project to full blown desktops. It is highly modular, low on dependencies, yet comes with all necessary batteries included.

Interesting project. You might check out Arcan (https://arcan-fe.com/) if you've never heard of it. (EDIT: I see author recently added a link: https://github.com/tattoy-org/tattoy/blob/main/website/content/news/20… ) A couple of points related to contrast ratio management: - The Mynex answer here is very informative: https://stackoverflow.com/questions/596216/formula-to-determine-percei… - The "limit/bound" on the contrast ratio has a "polarity" (a +- sense). At least for "text", in almost every font there are many more background pixels than foreground pixels. So, for example, your human eyes can tolerate a lower text cell fg-bg contrast with a dark background color for the text cell on an all-black background than they can for a dark foreground color on an all-black background. Part of this relates to "shared discrimination work" that the outside-the-text cell background pixels are doing. So, really "ratio" of just two things is somewhat of an oversimplification. - XTerm OSC 4 may have a very limited ability to probe the color palette. At least on `st` I can only see default foreground, background and cursor colors, not the full 16-color palette. This mostly just amplifies the point elsethread by @hnlmorg. - At least until more recent ssh's, default configs on Linux would pass through all "LC_*" environment variables. So, if you adjust your shell rc/configs to key off of, say,…

Ah, it underwent a complete rewrite somewhat recently, I heard it was a significant improvement. But I must agree that dedicated data analysis tools like DuckDB and jq are more powerful, intuitive, and performant. I guess what makes nushell appealing is how the data is already in nushell. It's where I stash any inputs I plan to use, any output commands produce and also any datasets I'm currently working on. The true value of nushell is it's role as a data exchange that preserves typing+structure and in providing tools so ingesting structured data is easy and parsing unstructured data is not daunting. I'm less pushing for nushell specifically and more hoping that it encourages more people ro think about some larger questions: - It's time to question the role of "UTF-8 text" as "the basic fundamental unit of data in the POSIX ecosystem" - Typed/structured data brings significant value and is not harder to work with - How can we improve data interchange between tools/apps without causing breakage? There's been quite a bit of thinking on if CLI tools can negotiate with each other to switch to communicating using higher-level data formats. Optimally it should work over common transports like SSH too. Unfortunately, I haven't seen any proposals that don't also introduce new problems. The nushell authors are looking into this as well. - How can we evolve terminals from the simple, reliable text renderers (that they never were) into simple, reliable renderers of general…

Have you heard of Arcan? https://arcan-fe.com

The Arcan project[1] has pushed for this for a loooong time and doing some really interesting cutting edge things with it. Depending on which set of Lua scripts it runs it fills a different role. The first set becomes the display server and window manager. It can then run itself recursively to provide graphical 'apps' (but also X11 ones, Wayland ones, ...). I run the 'regular' desktop (stacking, tiling, ...) 'durden' right now, but I hope to switch to the more crazy dataflow/zui one (pipeworld[2]) or the VR one (safespaces[3]). Then it has an additional 'curses like' one for TUIs and CLIs, 'arcan-tui' with a default shell Lash#Cat9[4]. Looking at their recent posts there also seem to be a network story including server-side processing, but I haven't had the time to play with out more than following the examples in the blog so can't say more about that. EltaninOS[5] is trying to build a distribution around it. Everything scripted in Lua. [1] = https://arcan-fe.com [2] = https://arcan-fe.com/2021/04/12/introducing-pipeworld/ [3] = https://arcan-fe.com/2018/03/29/safespaces-an-open-source-vr-desktop/ [4] = https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lashcat9/ [5] = https://eltaninos.org/

see also: https://arcan-fe.com

>SSD only isn't really an option, from what I have seen, eventually app designers want CSD to reduce clutter and to give their apps a better native look. This is true on all platforms, see for example macOS Big Sur. This isn't about the look of applications. This is about the needs of users and developers. I personally don't have window decorations at all on my main system, I don't need them and they are useless. There's developers that ask GNOME devs to implement a feature so their app can continue to work with GNOME users. There's users that ask GNOME devs to implement a feature so that app can work in GNOME. That's the point I'm trying to drive in here. GNOME devs feel like they can just break existing behaviors and ecosystems if they feel like it and say the problem is not on their end, while other groups have cooperated and worked on a solution that works for everyone. This is also the reason I don't use wayland nor develop anything for it anymore, too many things just don't work there, and the people that actually are trying to make things work or at least work on replacements gets constantly ignored or told to go away, meanwhile a single person has done a display server, that is not just wayland and xorg compatible, it's also much more flexible and more powerful than wayland ever is going to be. https://arcan-fe.com >Your dynamic linker is effectively using dlopen/dlsym under the hood, it's not doing any type checking. What I mean by typechecking is that with…

I don't have any raw data for performance numbers and that wouldn't matter anyway because they may not be relevant to your set up; if you're concerned about that you should run a test comparing them yourself on your specific environment. I'm speaking in terms of code complexity here, if you want to follow the threaded approach then minimum two threads will do the job (one for the scenegraph, one for the sockets), and an X compositor should potentially be doing this anyway to avoid lag caused by slow rendering. The difference is that the X compositor is just storing a copy of large amounts of state from the X server, whereas the Wayland compositor would store the canonical data and wouldn't need to worry about falling out of sync with the X server. Also, the way that X does it is overly complicated and is unnecessary to have protection against window manager crashes. A similar type of crash protection could be done with a Wayland implementation and it could be done in a much simpler way than moving the entire window manager out into a separate process. You just need to have another process that can hold the client fds and cache a minimum amount of state needed to resume the clients, it wouldn't need to know as much as the X server does to accomplish that task. Prior art is in the Arcan Wayland bridge, other Wayland implementations have not implemented this but they could eventually: https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/

The people who would greatly benefit from not needing to maintain it shout from the rooftops that it is dead because they wish it was already so. In fact its probably be mainstream for another 10-15 years and existing for another 25. Look how long it took to sort of but not really kill python 2. Thus the choice today is actually X vs Wayland because those are the 2 choices that can provide a functional desktop at this point in time. As for possible Ys I see SurfaceFlinger from android which doesn't look like its suitable for a desktop Arcan a one man band that doesn't look apt to replace X soon https://arcan-fe.com/videos/ Whatever Redox uses. I don't quite understand from a casual inspection how graphics works there. I would bet money that the choice over the next 10 years will STILL be X vs Wayland with more stuff wedged in until wayland is more functional but as kludgy as X wherein someone will have the brilliant idea to replace it with something more "modern"