#mercurymicrokernel — Public Fediverse posts

@flyingsaceur OpenBSD now, #MercuryMicrokernel someday when it's ready for dogfooding.

@flyingsaceur OpenBSD now, #MercuryMicrokernel someday when it's ready for dogfooding.

So this tension I think is primarily on the #MercuryMicrokernel side to resolve. The goals with #Layover are to be more impartial and platform-portable: if you have a sandbox tech available and the ability to atomically rename directories (or at least atomically rewrite symlinks), it should be possible to make Layover work there, with some degree of platform-specific code. So Mercury needs to expose those things, and that's totally feasible.

This ends up being a really useful pressure on the OS design, to make something very intentionally sandbox-oriented from the ground up - as a permeating design concern with greenfield liberty. It requires thinking in terms of resource quotas (particularly job slots a la GNU Make jobserver rationale), daemon partitioning, and probably no kernel-universal PIDs. Ideally a container workflow doesn't require special tools, it's just the native way services are downloaded, built, and run.

So this tension I think is primarily on the #MercuryMicrokernel side to resolve. The goals with #Layover are to be more impartial and platform-portable: if you have a sandbox tech available and the ability to atomically rename directories (or at least atomically rewrite symlinks), it should be possible to make Layover work there, with some degree of platform-specific code. So Mercury needs to expose those things, and that's totally feasible.

This ends up being a really useful pressure on the OS design, to make something very intentionally sandbox-oriented from the ground up - as a permeating design concern with greenfield liberty. It requires thinking in terms of resource quotas (particularly job slots a la GNU Make jobserver rationale), daemon partitioning, and probably no kernel-universal PIDs. Ideally a container workflow doesn't require special tools, it's just the native way services are downloaded, built, and run.

So here's where I explain what tension I was originally talking about. I have two big projects I'm excited to work on, once the groundwork is laid. One of them is a package manager/software build system called #Layover, which is reasonably but irreverently summarizable as "imagine if Nix was good." Its fundamental premise is treating immutable directories of data as a logical datatype, and supporting both pure and impure operations on these directories (where the pure ones are incentivized by cacheability, remote build compatibility, etc). Its intention is to be able to work across multiple platforms, using whatever platform-specific isolation tech is available for build sandboxing.

The other tech is the #MercuryMicrokernel, which is far less formed in design right now, but will radically reject POSIX compliance in favor of high-performance async IPC and a simplified FS design that omits ownership and permission data in favor of Plan9-ish "views" and #Prone-like COW semantics.

I'd like these to get along.

So here's where I explain what tension I was originally talking about. I have two big projects I'm excited to work on, once the groundwork is laid. One of them is a package manager/software build system called #Layover, which is reasonably but irreverently summarizable as "imagine if Nix was good." Its fundamental premise is treating immutable directories of data as a logical datatype, and supporting both pure and impure operations on these directories (where the pure ones are incentivized by cacheability, remote build compatibility, etc). Its intention is to be able to work across multiple platforms, using whatever platform-specific isolation tech is available for build sandboxing.

The other tech is the #MercuryMicrokernel, which is far less formed in design right now, but will radically reject POSIX compliance in favor of high-performance async IPC and a simplified FS design that omits ownership and permission data in favor of Plan9-ish "views" and #Prone-like COW semantics.

I'd like these to get along.

One of the proto-verbal design tensions I'm turning over in the back of my mind lately is about the axes that are actually appropriate for subdividing a single-host computing environment into multiple mutually-isolated functional domains. Which is a lot of highfalutin' words, so let me point at a familiar landmark: Docker.

It's pretty easy to say Docker sucks, or containers suck (there are valid arguments there), but they don't tend to appreciate why Docker got so popular in the first place - how containers act like a "desire path" in computing. There's something important there that people needed, and even doing an approximate job with a little marketing was enough to take off in adoption dramatically. Downloadable, portable, manipulable, standardized, self-contained, with the ability to share pieces of the host FS or not, and similar flexibility for networking. Obviously that beats a world of accommodating the quirks of umpteen Linux distros.

#MercuryMicrokernel #Layover

One of the proto-verbal design tensions I'm turning over in the back of my mind lately is about the axes that are actually appropriate for subdividing a single-host computing environment into multiple mutually-isolated functional domains. Which is a lot of highfalutin' words, so let me point at a familiar landmark: Docker.

It's pretty easy to say Docker sucks, or containers suck (there are valid arguments there), but they don't tend to appreciate why Docker got so popular in the first place - how containers act like a "desire path" in computing. There's something important there that people needed, and even doing an approximate job with a little marketing was enough to take off in adoption dramatically. Downloadable, portable, manipulable, standardized, self-contained, with the ability to share pieces of the host FS or not, and similar flexibility for networking. Obviously that beats a world of accommodating the quirks of umpteen Linux distros.

#MercuryMicrokernel #Layover

Considering file system models for Mercury has me feeling like a hunched over dad in a wife beater with a shotgun in his hands. "No daughter of mine is going to have UNIX uid/gid/perm bits!" If I can't make a practical model out of P9-ish per-process trees and prefix conventions, I'm gonna drink my liver into an early retirement. I mean, not literally, but I'll definitely drink SOME about it.

#MercuryMicrokernel

Something I'm kicking around in my head about Mercury.

Despite some people thinking that using a decades old timeshare server paradigm for the desktop is "archaic" or simply "bad", often without elaboration, I actually really like that a single operating system can be usefully programmed at different layers of paradigm abstraction. I can use my hefty Vala apps that came with my distro next to ultralight homemade shell scripts like passgen and server software like nginx. That has more to do with democratizing software dev than LLMs ever have.

I'm currently pondering, given the clean slate, whether it makes sense to extend this downward to the embedded landscape. Maybe Mercury should be a viable OS in the same sort of space as, say, FreeRTOS. The idea is nice, but there are pros and cons.

#MercuryMicrokernel