Quite a few of these concepts for the new OS remind me of Erlang BEAM. Does
this comparison make sense?

On Wed, Aug 3, 2022 at 10:36 PM Bruce Perens via Dng <dng@???>
wrote:

> 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
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>


--
With best regards,
Dimitri Minaev