Submitted by The Genode project released the fourth version of their Sculpt operating system, subtitled as “Community Experience”. The background of this slogan is the project’s ambition to remove the need for any middleman between developers and users. In contrast to today’s mainstream OSes, which rely on trusted distributions or app stores, Sculpt works completely federated. The integrity of the installed software is protected by digital signatures of the respective software providers while each piece of software is sandboxed both at installation time and at runtime. This way, users don’t need to be faithful but enter a position of ultimate control. This is capability-based security at work!
As explained in the accompanying blog posting, Sculpt CE features an new user interface to integrate software into the running system and to reveal the trusted computing base of each component.
Without a middleman between software providers and users in Sculpt OS, there is the obvious question: How can a user find software? The Genode project tries to answer this question with their community blog called Genodians.org started earlier this year. It gives Genode developers a way to announce new software while users can share their perspectives and ideas. Just like Sculpt OS, the content of Genodians.org is managed in a federated fashion.
Sculpt CE is available as a ready-to-use disk image bootable from a USB stick. The release is accompanied with comprehensive documentation that covers both the use the system and the philosophy behind it.
This release is a perfect example of what I love about Genode! After years of steadily building their OS Framework from experimental foundations into a robust platform, in 2018 they turned their attention to creating “Sculpt” as a general-purpose, end-user-focused system. Each release has incrementally improved the situation, but this one (“CE”) takes it to a new level.
The “Live Component Graph” is a novel concept, that shows each running component in the system along with the connections between them, updated in real time. Clicking on a component shows some info about the component’s resource usage, allows you to remove it, but now also highlights its trusted computing base!
But the biggest addition is the Depot concept that Norman talks about, which allows run-time software installation (from multiple sources) and configuration, in a friendly but powerful way. Again, they have approached the problem from a different direction, with a surprisingly clean but flexible result.
There is still a long way to go, but this release is definitely the time for OSNews types to check it out! (Norman didn’t mention it, but there is also a VirtualBox “appliance” on the downloads page, for those of us without supported hardware.)
I recommend reading the “Genodians” article first (https://genodians.org/nfeske/2019-03-19-sculpt-ce), which is very brief, just to get an overview. The main “Sculpt CE” article (https://genode.org/documentation/articles/sculpt-ce) is longer, but it is easy to follow, and combines an quick overview of the system design with a tutorial for getting started.
Then check out the new “Genodians.org” site, which has everything from helpful hints for beginners, to in-depth technical articles, to progress updates from third-party community members (does the Haiku userland atop Genode sound interesting?).
(P.S. If this sounds like an advertisement, it isn’t. I have no relationship with Genode Labs except as a hobbyist and enthusiast. I am bored and depressed by the state of most of the computing world, and as far as I can tell, Genode offers the best hope for the near future, with the combination of clean, trustworthy design, open software principles, cross-platform support, and excellent project management.)
(does the Haiku userland atop Genode sound interesting?).
“Damn Straight!” 🙂 🙂
/me loves Haiku.
Here are a few of the posts that chronicle the progress of the “Haiku-on-Genode” (HoG) project (with a few screenshots):
https://genodians.org/ttcoder/2019-01-09-gui-basics
https://genodians.org/ttcoder/2019-01-20-gui-chronicles
https://genodians.org/ttcoder/2019-02-06-gui-chronicles-2-mandelbrot
https://genodians.org/ttcoder/2019-03-26-hog-bounties
This is an impressive effort that has already gotten much further than any of the previous “Haiku-on-Linux” type projects that I’m aware of, and should benefit both the Haiku and Genode communities.
Mhm, I will definately check it out (though I worry how their concept of software discovery will scale / isn’t it sort of an admision of niche status of Genode? 🙁 )
Genode is better architecturally than conventional OSes in most ways, but I can see a few issues with the design. The biggest is that it uses a mostly process-per-component architecture, which multiplies the number of context switches for even simple system calls (e.g. from what I can tell on Genode under noux a single read() or write() of a disk takes at least 6 context switches: VFS->disk filesystem->disk driver and back again). IPC is cheap on typical L4 kernels, although large numbers of context switches are still going to have more overhead than either the simple mode transition within the same process that a typical monolithic kernel would use, or the two context switches that would occur on a microkernel OS that avoids intermediary servers. There is really no need to vertically split up a subsystem into a process per component in many (probably even most) cases since protection domains usually correspond to subsystem instances, not components at different levels within a subsystem. Using the example of a disk filesystem again, a disk filesystem driver and its associated disk device driver form part of the same protection domain since they are both dealing with the same data, just at different levels, and a compromise in either would be more or less equivalent). Another (although much less noticeable from the perspective of the end user) issue is its use of an IPC transport layer based on structured RPC, when it would be sufficient for the transport layer to just use unstructured streams and leave the RPC up to higher layers (the IP protocol suite gets by fine with unstructured transport layer protocols so I don’t see why a local IPC transport layer on a microkernel should be any different).
The multi-component architecture is not a must but an option. E.g., Genode allows one to mount a file-system driver (like a rump-kernel-based file system from the NetBSD kernel) directly to the application. The same goes for the TCP/IP stack. One can “mount” the Linux TCP/IP stack directly into the application’s VFS – all happens within one virtual address space. However, when doing this, only one application can work with the file system (or the NIC) at a time.
Whenever the multiplexing of an I/O resource is desired, an intermediate component must be added to the picture. For storage, multiplexing usually happens at two levels of abstraction. First, at the partition level, one physical block device is handed out as multiple virtual block devices (partitions). Second, at the file-system level, multiple applications expect to share one file system among them. Such multiplexing requirements are reflected by respective components (part_block, and file-system server). Here you get the chain of components.
Still, in a case where only one application accesses a file system that is stored directly on a physical device (no partitions), the application (including the file-system stack) can be configured to access the disk directly. In principle, this flexibility could even be extended to the block driver (shaping the application towards a unikernel). That hasn’t been done so far, but we consider it.
Regarding IPC, note that Genode doesn’t rely merely on RPC. The inter-component interfaces employ a mix of synchronous RPC, asynchronous notifications, and shared memory. These mechanisms and their combinations are discussed in detail in Chapter 3 of the Genode Foundations book (http://genode.org/documentation/genode-foundations-18-05.pdf). E.g., network packets and file-system operations are transmitted in batches over shared memory, relieving the context-switching costs.