crazyloglad

That is pretty much what we've done, but not in as "narrow" a scope as just Desktop but more as 'everything user facing in computing'. Full breakdown will be covered later this year as 'Arcan As OS Implementation' in a section on "Lua at every layer".

The entire article is from the browser internals angle. The page-writer one comes when we have tools to compile pages into app and layer in user features. The rough path for that is simpler ones first (Sile typesetter and Pandoc), then more exotic ones. An example of the later would be a "print to" modification to a browser that can preserve more content like animations and audio and not be restricted to fixed sized pages.

It is forever backwards compatible. API levels is for the rare few cases where we need to deprecate or break something on the engine side but can apply a runtime fix-up script to replicate the behaviour on the scripting level.

Decode/Encode/Network/Terminal is user-relevant insofar as the set of those are interchangeable binaries. If you want more or less (paranoia, legal environment restrictions) media format support, export or streaming capabilities, etc. those can be swapped out per site without any changes to the engine. What is being considered is to be explicit about expected formats in the manifest so that incompatibilities can be detected.

SHMIF is user relevant insofar as "wasm or low-level compiled code" running as local software can be embedded and controlled by the app, allow-listed by the user.

> No third-party storage, and maybe first-party is optional too (not sure what's the plat for this.. user prompt? explicit action?)

Can you clarify what you mean by this?

Et tu, Brute? Posit this. If you want to catch a rare kind of elusive fish that both has in-depth knowledge of a very niche topic and, rarer still, willingness to play for the greater good, how would you approach finding such a swimmer?

Failing to do so, that ticking clock, the tell-tale heart, means the engaging article will be an obit called 'Bowing Out'.

see also: the reply to you in the web post.

> User comes to an artistic website whose author thinks purple on red is a great color schema.

The outer app used as your desktop/browser-UI has two mechanisms at its disposal. The first is collaborative - it can convey the preferred colour-scheme so the 'page' you are browsing to can pick accordingly. That's actually how the terminal emulator and non-terminal shell both gets their colour schemes.

The other is enforced - just as tone mapping is needed on the composition level to deal with HDR, you can use the same facility to apply colour grading per 'page'. That's what I do to chrome right now without it knowing. If the average luminosity exceeds a threshold, it picks a colour map that enforces a dark mode regardless of what the browser wants. Similarly, if a game doesn't respond to resize requests but continues to provide a low 256x240 like output I apply an NTSC signal degradation shader pass into a CRT simulation one. By having it as a composition effect means that I can have my own view of colours, but if I 'share desktop' to someone else the original form is retained.

> - User opens the very newest website, which uses all the latest website standards, including new video codec, new font and new text rendering effect. (In regular web, this would only happen once most clients update to the very latest version of the browser, and telemetry says enough clients have updated)

It's similar to Android API_LEVELS. API breaks (we've had, I think two, since 2013) have been handled with a hook script that exposes the old behaviour. New video codec deployment is a bit special and there's a protocol level degradation path for that with a few nuances. It has mainly been used for hardware accelerated web cameras as a remote data source where it starts with direct pass-through of whatever streams it provides. If the client fails to decode (stream-cancel:reason=codec failure) it signals that and the source end reverts to a safer default from a hierarchy (h264 into zstd).

> In current web, I'd use "reader mode", or a custom UserScript if I plan to go to website often. What happens in Arcan - is this up to the "decode client"? What if the site author chose a "decode client" which has no such functionality?

Decode can be used for that but it is overkill. The hook-script facility (arcan -Hmyscript1.lua -Hmyscript2.lua myapp) can interpose every function the app has access to transparently. Reroute patterns like "load_image_asynch("something.jpg") into null_surface() there. These and other options like the set of encode/decode/permitted integration with allow-list of local software can* be preset per authentication key.

There is a PoC 'more than adblock' that uses an LLMed version of 'decode' in my bin of experiments. The first part is a hookscript that routes all image loading through a version of decode with a local classifier model asked to 'describe the contents of this image and tell me if it looks like an advertisment'. If not the default path applies. If yes it substitutes an image of puppies playing tug of war with a rubber chicken.

* code being written as we speak.

It's still around. Still doing its thing. One developer drafted a backend to ratatui for it, but he's been silent lately. I'm only marginally interested in that angle as its endgame "just" lands in TurboVision but Rust! and having to stay compatible with the feature-set of terminal emulation defeats the point.

"Good enough for your work" until issues like the one mentioned appears; You plug in a kvm, close the lid or something at the wrong time, come back and see your work gone. You then blame the client, the gpu or hardware, then the toolkit, then the compositor and everyone says "can't reproduce" because the infrastructure guys went EWONTFIX because 'difficult'. It is a design blog, it is inherently political. There's a high number of tech posts on the main site. The roadmap, the intentions, everything has been spelled out, and visible for half a decade.

Xorg is better, but not by much. On write-fail they setup an internal buffer ~16k and if that one is saturated it is closed (that + whatever the kernel has). The protocol/packing is not that busy in the server to client direction so it lasts for quite a while.

The way the disconnect happens is interesting though, I am not certain enough about the threaded-IO implementation in regards to hotplug but a quick glance looks like if a hotplug occurs at the same time a client is disconnected the sparse allocation requirement of open() could get an input device confused as a client as it is cleaned up. The odds of that happening though :D

In the wayland code it looks like they tried to have a buffer strategy at some point, but then got too clever for their own good (epoll designs + asynch-OO projected over C is... yeah) and somewhere in 'closure/write/buffering to lower #syscalls/callbacks' landed in a long chain of error propagation and immediate kill.

The best way I found (hence using it) is to have memory mapped ring buffers and just have an atomic head-tail indicator. This makes file-descriptor transfers (DuplicateHandle from win32 fame is just so much prettier) messier, but it means that you can have a recovery strategy and see the backpressure buildup and rate-limit. Since it is mostly input events or 'drag-resize' (and those can be merged) in that direction, silently dropping them and have mouse cursor 'jank' is better than losing your work. If all else fails, the watchdog handle is pulled and the client is set to migrate to a fallback server (if set).

The mechanisms in Windows changed for doing some parts of it - as far as I recall it was due to the access controls (UAC) and DRM around the Window Manager (DWM) but it was a while ago, some vendors have figured out parts of working around DWM again - see the VR desktop mentioned and Stardock WindowFX.

I am not saying that the ones that X have are great or even that good to begin with. A better set could have likely avoided the ICCCM etc. but you can do a lot with just reparent+position - WMs are mostly normal clients after all.

Compare that to say the practically obligatory 'xdg_wm_base' specification, you are much more locked down, and the objects to work with are strongly interconnected. If you want to work around that as a 3rd party developer it's a political process + waiting for n*m compositors and toolkits to adapt.

People tend to miss that Arcan is a Wayland compositor as well, but those clients gets a special path where the WM has to follow extra sets of rules because of it.

I see it as a gradient. Neither is entirely Green (Mechanism) or Red (Policy) but if you look at the sets of both sides and position, I doubt you'll assign the same colors.

> I don't know if you've noticed, but "policy over mechanism" has thoroughly won in the desktop space. The dominant desktop is Windows; even macOS has several times the mind/market share that Linux has.

Windows exposes lots of WM mechanisms to a developer, hence why something like vrdesktop.net could be built in the first place, or previous WMs like LiteStep for that matter.

It is also why WINE does not, and cannot, have a working Wayland backend while sticking to the protocol. The same is true for X, but there XWayland requires the compositor developer to implement a sideband window manager to hack around the entire Wayland protocol to get X clients to work.