Arcan

>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…

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/2025-05-12-an-end-to-terminal-ansi-codes/index.md#notes )

A couple of points related to contrast ratio management:

- The Mynex answer here is very informative: https://stackoverflow.com/questions/596216/formula-to-determine-perceived-brightness-of-rgb-color

- 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…

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 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/

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"