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@lists.dyne.org> 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 <hilju...@so.dang.cool> 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 < >> sl...@troubleshooters.com> 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@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > > > -- > Bruce Perens K6BP > _______________________________________________ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- With best regards, Dimitri Minaev
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
