Just as we concluded our first NLnet grant, it is also time to say goodbye to the second phase of the project, ‘anarchy on the desktop’, and enter the third and final one.

As per the old roadmap, 0.7 is the last window of opportunity for any trailing features. For 0.8 we finally get to pull out the performance tuning tricks, 0.9 for hardening the attack surfaces, to be followed by me disappearing in a puff of smoke.

I am also happy to say that we have received two new NLnet grants, one administrated by me, the other by Cipharius. Both of these build on the networking layer. For my part we’ll extend the directory server end to have a more flexible programmable remote side, for supporting linking multiple ones together and making the entire stack ‘turnkey’ easy to deploy and use.

In the other end there will be a simpler access layer for letting a device join your ‘one desktop, many devices’ network and extend it with its storage and sensors (cameras, displays, IMUs, and so on), or act as a portable viewer, Smash, for accessing it from within the confines of the corporate walled gardens.

I have often and, rightly so, been accused of not being a very public person. As an exemption to that rule I did partake in an interview by the venerable David Chisnall which can be read over at lobste.rs here: https://lobste.rs/s/w3zkxx/lobsters_interview_with_bjorn_stahl — if you are at all curious about my background and motivation.

Let’s briefly look at the building blocks in place:

IPC system – SHMIF.

Way out of terminal insanity – From The Dawn of a new Command Line Interface into The Day of a new Command-Line Interface: Shell.

Covering special needs – accessibility, debugging and security.

Networking – A12: Visions of the Fully Networked Desktop.

Legacy Strategy – SHMIF and A12 were both verified to ensure that anything that could be done (arcan vs Xorg part 1, part 2) through previous popular tools and protocols can still be done and persist onwards (missing – bringing X along).

All these latch into the scheme layed out in ‘Arcan as OS design‘.

Now we can braid these strands together into one rope, whip it into shape and see what should dangle from it.

This release doesn’t have many demonstrable items for the core engine itself, mostly fixes all across the board. Instead we will recap some changes and ongoing work for Lash#Cat9 and Xarcan. Our reference desktop environment, Durden, will get a separate release post when some of the tools has received more polish work.

As a teaser though, the following clip shows how the network tool can map in the key-local private file store and route it to our decode plumber:

In a similar vein, the following clip shows the same approach to picking a file from the directory store, setting it as the drag source and then dropping it into Cat9 and letting it expand it into a job view.

This act as the development baseline for more things, particularly letting controller appls running server-side define other namespaces, scan / index and annotate, distribute across a network of directories and search.

Other highlights for that release will be a new streaming/sharing composition tool; trainable mouse gestures; new initial setup configuration helper; desktop icons; on-screen keyboard; input typer helper with dictionary/IME completion; stereoscopic support for Xreal Air style glasses and more bespoke displays such as Looking Glass (lenticular) and Tilt5 (projected, retroreflective AR).

Lash#Cat9

Technically, Lash is a Lua scripting environment that is wrapper around our curses replacement, libarcan-tui, adding some convenience features to make it easier to write a command-line shell. Cat9 is the current reference shell for this.

The major features added to Cat9 over the last ~2 years since its inception has all received individual write ups:

In A spreadsheet and a debugger walk into a shell we cover a Debug Adapter Protocol Implementation as well as an interactive spreadsheet that can be populated by regular shell commands. The following two clips come from that article:

In Cat9 Microdosing: stash and list we cover a ‘ls’ replacement that effectively turns it into a file manager, and a scratchpad for accumulating files into a workset of files to monitor for changes, or forward to compression / transfer tools. The following two clips from that article:

In Cat9 Microdosing: each and contain we add the option to absorb the output of previous or current jobs into a collection that can then be referenced by other commands as a single unit, as well as defining asynchronous processing options over a range of data from other jobs (best used with the stash mentioned above). The following two clips come from that article:

The next planned such write-up contains a social timeline for things like mastodon and email timeline by frontending ‘madonctl’ and ‘himalaya’ as well as more developer tools like scm based integration. The following clip is a sneak peak from that:

Xarcan

In the last release post we hinted at how Xarcan can be used to keep your own window manager, letting Arcan act as a display driver — as well as a security, control and configuration plane that selectively merge in arcan native clients with options for how, or if, X clients gets to see inputs and clipboard action.

The following clip was used for that:

It’s almost as if what Adam Jackson said long ago rings true: (https://lists.freedesktop.org/archives/wayland-devel/2017-September/034960.html)

One thing I’ve never really been thrilled with about the Xwayland design is that the wayland compositor wants also to be the X window manager, and that all the related state about window position and whatnot is just internal to the compositor. xwin and xquartz don’t have this problem, you can run twm as your window manager and still move windows, but in xwayland that doesn’t work because wayland refuses to allow you to position your own window for (what I consider) essentially religious reasons [5]. And as a result the compositor gets a lot more complicated and you _still_ need to change the X server to get things to work. What I’d have preferred is a wl_x11_interop protocol that Xwayland could use to send this kind of advisory state, which mutter could optionally only expose to Xwayland if it really wanted to be less functional than X.

‘Essentially religious’ reasons indeed. What really happens is that Xarcan synchronises X11 ConfigureWindow and Stacking information with the corresponding VIEWPORT events.

This lets the Arcan side of the WM equation take the output video and decompose it into degenerate regions of linked coordinate spaces. It then uses these regions to determine if it should forward input or not.

For Arcan clients, it creates empty placeholder windows in X11 space, and swaps out its contents for the real one during scanout. It lets the X11 side know there is an object there, but prevents it for having access to its contents – unless desired.

That last part can be solved with controlled sharing. In the following clip you can see how I drag the contents of an Arcan window into it, letting legacy ‘screen sharing’ or ‘screenshotting’ (as flawed as those concepts are, but that is a long rant) applications see and capture it:

There is quite a lot more going on and planned:

An interesting coming change to arcan-shmif will have it re-use the ‘platform’ layer in Arcan that is responsible for managing input devices and controlling displays when there is no other arcan-shmif server to connect to.

This will effectively turn the Xarcan DDX into a standalone Xserver that works as expected, but at the same time keep up to date with features and changes to the KMS/GBM part of the graphics stack.

This lets us drop a whole lot of cruft from Xorg: XNest/Xephyr is no longer needed, neither is XAce or XFree86. We can eliminate quite a few slowdowns and pitfalls in startup.

Since it’s trivial for us to compartment and apply policy based on client origin, it will also be possible to partially share in the other direction, such as letting Xarcan act exclusively as an input-driver in order to bring xf86-input-wacom and XIM along.

Before then we have a few minor immediate cleanups left, mainly fixing regressions in GLAMOR caused by changes to DRI3 and PRESENT and some work-arounds for XDND to be able to work between multiple, networked, X servers. It’s not hard, just tedious.

Now it’s time to head off to 38c3. See you next year for the final reveal.