I came to the conclusion a while back that systemd was symptomatic of the
fact that we had gone as far as the fundamental assumptions of the Unix API
could take us. It is 50 years old, after all.
There is room for replacement of systemd and continuation of Linux and BSD.
But we should be looking forward to something else as the next OS paradigm.
This would include features that have been seen mostly in experimental
operating systems up to now. This is what I think the "next OS" might be:

The fundamental OS concept is "Everything's an API" rather than
everything's a file.
APIs rather than libraries and linking. A mechanism to set up an API upon
request, where the details are hidden from the application. The API may run
on a different CPU. This means you need lightweight processes and fast IPC
with the capability to redirect to a slower network connection.
APIs have persistence and can own resources, and have an identifier that is
something like a file descriptor. The replacement for
open/socket/connect/accept is requesting an API with certain resources.
APIs persist until you release them or they can no longer be provided
because the other side has disconnected or a resource becomes unavailable.
No assumption that any API provider lives on your computer. It can be
anywhere, but is often on your computer for efficiency.
No distinction between an API call and a system call.
API calls are not blocking, but have an asynchronous event channel that the
application listens to.
Minimal installation for network-connected systems. API providers live on
the web and can be cached on a local server, and are locally cached on a
resource that is not user writable.
Storage is an API provider and may live elsewhere. Systems may not have any
storage, or may only have caching, or may have local storage.
Message bus appears as an API with an asynchronous event channel.
Configuration by a JSON db. The simplest is just a JSON file with an API
that edits it. It's human-editable and readable, but human editing is not
required for configuration. Local configuration overlaps site-level
configuration.
First-class sessions. This was a big missing element in Unix and I think a
lot of the impetus for systemd. Sessions are API providers and own the
facility that connects processes to all other APIs. They own the user
information and only provide you with APIs that match your privilege. They
own their own resources such as displays, audio, and input devices. You
start with a session and then create processes in it. You can't create a
process without creating a session first, but it may be a headless session,
etc.
No privilege escalation for your session. Login runs in a privileged
session and starts a less privileged user session for you. Some APIs run in
different sessions than you and thus can provide you with privileged
services.
Window systems export the same APIs as the raw display and audio - you can
run an application with or without one. You can run a window system in a
window. Request to open a new window may succeed or fail gracefully,
leaving you with only your root window.
WASM interpreter with access to APIs and privilege control to run untrusted
remote applications the way you access web sites today. They can access
local APIs and their host APIs with different privilege levels.
Both native and WASM executables are first class. Makes porting a lot
easier.

So, how does this replace systemd and init systems? What we use servers for
today gets replaced by API providers. API dependencies are part of the
metadata in applications, and an application will not start if there is no
provider available for an API. The providers will be started on demand when
the applications ask for them and may be started *before *they are asked
for, simply going by the application list and the session owner's previous
usage. API providers can be retired when the API is released, or not, again
depending on usage information and the application list. API providers may
be local or remote depending on usage data and the necessary resources - if
you use one a lot and it is not bound to a resource with a specific
location, the system can start an API provider locally, but some API
providers may rely on stronger or more specialized compute resources than
your local CPU. Migration of APIs that own resources is not supported - you
can close one and open another.

    Bruce

On Wed, Aug 3, 2022 at 1:41 PM J.R. Hill <hiljusti@???> wrote:

> There are a few things that need to be in place for a smooth transition.
>
> For general trust in the project...
>
> 1. the init system itself should be maintained by more than a single human.
> 2. the maintainers should be willing to respond to a large audience. (If a
> project is used widely across distributions and is critical to operation
> and security, it'll attract attention from armies of newbies and large
> cloud corporations alike.) This means there needs to be an ability to move
> slow (maintain backwards compatibility) and also to move fast (in security
> situations)
> 3. the project should be available from some trusted platform with
> versioning and source history.
>
> For ease of transition...
>
> 4. many init scripts need to exist, or they need to be trivial to write.
>
> I'll give some thoughts on runit:
>
> I'll start by saying that I've used Void linux for a few years now, and I
> love using runit. It's simple, it works, and it's understandable. That's
> the opposite of my experience with systemd. I'm not passionately against
> systemd (or the developers, or RedHat, or even IBM), and I think systemd is
> technically impressive and ambitious. But also I don't really want to use
> it or anything like it.
>
> > It's maintained by the Void Linux project...
>
> Unfortunately I don't think this is true. It's used by Void, but we're
> packaging it by building from the source tarball like anyone else.
>
>
> https://github.com/void-linux/void-packages/blob/master/srcpkgs/runit/template#L12
>
> They do, in effect, drive the maintenance or creation of runit scripts. In
> the event that we wanted to move many distros to runit, there are many
> examples of runit scripts to either copy or use (#4). Also it might go
> without saying, but the scripts themselves are trivial to write anyway.
>
> If I consider runit for my other points above, it doesn't look so hot.
>
> I don't see evidence that runit is maintained by more than a single person
> (#1), and given that the mailing list archive seems to be down... (And
> using the "wayback machine" archives it looks like it's been down for more
> than a year) it doesn't give me a lot of confidence that the maintainer is
> ready to respond to large audiences (#2). Also, the source is distributed
> as a single snapshot tarball on a personal website. There's no shasum, no
> GPG signature, no revision history, etc, which also doesn't give me a ton
> of confidence (#3). I don't care about seeing a lot of development activity
> or even recent activity, runit is simple. But especially for security
> reasons it's important to know the history of a project, like exactly which
> version has vulnerable code introduced and which version has a fix.
>
> Now, I really really like runit, but I don't think it's ready right now.
> For runit to be a broadly-attractive alternative, it needs a few small
> things: to move to some source control system (git/mercurial/etc) where
> more than one person has access, and the maintainers have to be reasonably
> responsive. Without that, I think FUD around runit is probably justified.
> (Of course, we can always take the tarball and shove it in
> github/gitlab/etc, that wouldn't be the end of the world)
>
> I don't know enough about S6 (using it, or the project) to comment on it.
>
> -- J.R. Hill
>
> ------- Original Message -------
> On Monday, August 1st, 2022 at 07:21, Steve Litt <
> slitt@???> wrote:
>
>
> > Hi all,
> >
> > As I said in a previous message, I see sentiment very slowly turning
> against
> > systemd. If systemd keeps losing popularity, I have no doubt the
> corporate
> > carpetbaggers will try to force an even worse atrocity on us, so we need
> to be ready
> > this time and not have the argument centered on a false choice.
> >
> > I see two init systems ready to take the baton and run with it:
> >
> > * Runit
> > * S6
> >
> > Runit is the simplest init system other than /bin/bash or an rc script.
> It's
> > maintained by the Void Linux project, so hit hard at the FUDdists who
> claim runit is
> > unmaintained.
> >
> > S6 is advancing full speed to a complete solution, implementing all the
> best
> > features of systemd, but these features are voluntary and separable. If
> you want top
> > quality, choice and performance, and are willing to accept a little more
> complexity
> > (but sane complexity), S6 plus its service manager is the way to go. In
> my opinion,
> > S6 plus its service manager offers more than OpenRC, and IMHO it's
> easier to
> > configure/manage.
> >
> > If and when systemd falls, we need to be ready, so we can get the right
> init system,
> > instead yet another corporate sponsored Rube Goldberg Machine.
> >
> > SteveT
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>


--
Bruce Perens K6BP