1. 20
  1. 17

    This sounds a lot like what we were trying to build with Étoilé. I’d still love to see it and a lot of what I’ve worked on over the last decade or so has been building the missing tools that made it hard to realise this vision.

    A lot of component-based systems have been proposed, but they all struggle with either security or performance. A COM object, for example, has complete control over the process that embeds it. You can fix this by using DCOM, but now you need to have a lot of copies.

    • With Capsicum, we now have a good way of building DCOM(/PDO/CORBA/…)-like things where the component runs with no access to OS resources unless explicitly delegated, but we still have latency issues around scheduling (still hoping someone can be persuaded to implement something Doors-like on FreeBSD).
    • With CHERI, we can do fast synchronous domain transitions and safe sharing, so we have a proper mechanism for building these things. And we’ll see it in mainstream processors any decade now…
    • With Verona, we have a programmer model for interacting with untrusted components, so we will be able to actually build these things sensibly, once we have a finished language spec and a compiler (and CHERI hardware to run it on).

    It might be possible to use WAsm as a building block. That comes with some perf cost, but computers are fast now. It doesn’t solve the problem of copying, but some of the WAsm interface type work looks potentially promising here.

    Arcan is the only project that I’ve seen that seems to be evolving in a direction that I get excited about.

    1. 6

      Relatedly, I remember seeing Étoilé years ago and thinking it was really cute and clever - sadly, it seems the project got lost in the sauce of making an Objective-C document framework, as well as general lapse of interest.

      Arcan is the only project that I’ve seen that seems to be evolving in a direction that I get excited about.

      I really wish there was a good explainer on Arcan. Every time I see it, it feels impenetrable to get an explanation of what exactly it does and what makes it different.

      1. 4

        Relatedly, I remember seeing Étoilé years ago and thinking it was really cute and clever - sadly, it seems the project got lost in the sauce of making an Objective-C document framework, as well as general lapse of interest.

        The document framework was a core part of what we wanted:

        • A consistent persistence model, inspired somewhat by Newton Soup and other similar systems, where user-visible objects (e.g. images, videos, paragraphs of text) had identities and could be embedded in larger documents.
        • A diffing and merging model that could be used to build collaborative editing, offline editing and syncing, and so on.
        • A decoupling of data model and view model so that a single document could be viewed in different ways by pluggable viewers.

        Objective-C was a fairly reasonable language for building this (late binding everywhere) but GNUstep wasn’t really mature enough for the GUI parts and never saw the contributions that it deserved. I was also working on adding other languages on top of the same runtime (Smalltalk, a JavaScript dialect, and some more specialised things) so that we could allow users to extend things without writing unsafe C code. All of that ended up requiring a security model that it was basically impossible to retrofit to C on current hardware, which led me to work on CHERI (now we have the mechanism) and Verona (and a way of surfacing it to programmers in a comprehensible way).

        I really wish there was a good explainer on Arcan. Every time I see it, it feels impenetrable to get an explanation of what exactly it does and what makes it different.

        I get the impression that this is deliberate. The author wants a high barrier of entry so that he gets contributors (maybe) but doesn’t get ZDNet or Phoronix writing uninformed articles that set up misleading expectations.

      2. 4

        I am aware of Capsicum and Cheri, but what’s Verona in this context? Is it https://github.com/microsoft/verona ?

        1. 4

          what’s Verona in this context? Is it https://github.com/microsoft/verona ?

          Yes. Verona has a region abstraction for plugging in different memory management models (and for isolating complex data structures so that they can be passed around between concurrently executing entities). This same abstraction can be used to provide a programmer abstraction supporting multiple instantiation of foreign libraries. We have a prototype of this using Capsicum or seccomp-bpf (which is so much more painful to work with) for process-based isolation, using CHERI would be much more efficient.

        2. 2

          I’ve been independently working on similar ideas. Security+performance is a good goal. My idea is to create a virtual machine that enforces the safety and security properties, and compile the VM instructions to efficient machine code. This doesn’t require CHERI hardware. The WASM VM doesn’t enforce the safety and security properties I want within a single address space, so it’s not what I want.

          1. 1

            Have you looked at the MSWAsm work? It adds a lot of the guarantees that I want (and actually uses our CHERI branch of llvm to compile C/C++ to their target). Their overheads are a lot higher than CHERI, but they offer a nice migration path: you can run MSWAsm code on existing hardware, it will just be much faster on a CHERI CPU.

            1. 1

              Yes, I see, thanks for the MSWAsm reference. I’m going down a different path, though.

              A lot of component-based systems have been proposed, but they all struggle with either security or performance.

              Objective-C was a fairly reasonable language for building this … All of that ended up requiring a security model that it was basically impossible to retrofit to C on current hardware

              C/C++/Objective-C initially look like a good choice for a high performance extension language, due to the inherent high performance of the language, and the availability of libraries. But you have a big problem imposing a security model on C. It requires special hardware that is currently unavailable, or you isolate components in separate processes (which affects performance), or you impose a large performance overhead, as in the MSWAsm VM. And frankly, I don’t see CHERI as being sufficient to support my goal of a capability based security model.

              My solution is to use an inherently safe and secure high level language as the high performance extension language (not C). This language can be compiled into efficient machine code and untrusted components can efficiently interact with one another within the same address space. Works on standard hardware (doesn’t need CHERI) and works on standard operating systems (doesn’t need a special capability based OS), because the language and its VM is a layer between the hardware/OS and the extension code, that enforces the safety and security properties. I think this approach will be faster and easier to implement.

              1. 2

                Not supporting C is likely to be a deal breaker. Conservatively, there is around a trillion dollars worth of C code on GitHub. If you are starting from a perspective of having to rewrite all of that then, even if your new environment makes developers an order of magnitude more productive than C and you can prioritise and ignore a lot of things, you need a minimum of a few tens of billions of dollars of investment just to get some core things to parity. This is why things like Squeak remain interesting niches rather than competitive environments.

                Rust is paying around a 20% perf cost from all of the dynamic checks that it does (you can turn them off in the compiler and measure this). A lot of things that nontrivial software does are impossible (or, at least, computationally infeasible) to statically prove correct. Something has to enforce them. Either something like CHERI does it in hardware, or you do it in software and accept that speculative execution means that your security model has integrity guarantees but no confidentiality guarantees. Or you use MMU isolation and pay a big performance cost and require a lot of copies because you can’t do fine-grained sharing (Chisnall’s law: isolation is easy, safe sharing is hard).

        3. 5

          Look and feel of a tool is less important than how it works alone and how it works with other tools. In contrast to the statement in the article, the modern macOS is still the most customizable environment available. Nothing competes with the customizability of AppleScript. It lets you orchestrate multiple tools with a few lines of code.

          1. 3

            The author mentions Windows environments, GNOME, and Mate, but makes no mention of KDE or i3wm. GNOME/Mate is great, but not flexible. For example, I wish the terminal would save tab sessions like Konsole, but there is no ability to configure such a feature as it is simply unsupported. If looking for flexibility, KDE is fantastic.

            The simplicity of i3wm is awesome, which allows flexibility through building complexity on top.

            1. 2

              Re composability: This is a really good point, I wish the author referenced earlier demos to show what’s been possible, such as with smalltalk where alan kay states “Windows here are views of tools and the kinds of resources authors use to create the writings of the future…” https://m.youtube.com/watch?v=AnrlSqtpOkw&t=4m19s (Via https://twitter.com/i/web/status/881029891860307969 )

              Re ui customization: I sit a bit on the other side of the fence around this, erring towards finding a design language that enables a balance of accessibility and general flow. Think there needs to be writing framed around the tradeoffs, as I find myself loving large titlebars and some of the touchscreen-accomodating design decisions the gnome team has been making.

              1. 1

                One more digression, it may be worth exploring how an IDE like VSCode could be easier to compose/composition collections of tools to spread availability of a workflow.

                Something I’m currently exploring..doesn’t necessarily relate to the desktop environment idea but brings up a lot of questions around why we end up with ‘apps’.