Re: [DNG] Be prepared for the fall of systemd
Joel Roth via Dng - 05.08.22, 21:56:01 CEST: > On Fri, Aug 05, 2022 at 03:05:54PM +, jkinney23--- via Dng wrote: > > On Thursday, August 4, 2022, 02:53:33 p.m. PDT, Bruce Perens via > > Dng wrote: > > > I haven't followed more modern experimental operating systems. > > > Mostly you don't hear as much about them these days, I think a > > > lot of researchers use an existing Open Source OS as a base for > > > some specific facility.> > > That's a little disheartening to hear. I have been trying to find a > > program in Canada where I can go study operating systems. Is there > > no one anywhere doing serious OS research anymore? ...I guess I > > will stay with Youtube and the Devuan mailing list then :) > > Jöchen Liedke, who died a few years ago, was doing some > interesting work: the L3 operating system, leading > to the L4 microkernel and hypervisor framework. > Looks like Pistachio is the latest, without much > recent activity. > > https://l4ka.org/ > > The L4Linux project is still active: > > https://l4linux.org/ Also Genode and SculptOS are being actively developed. https://genode.org/ https://genode.org/download/sculpt I did not review those yet. They have mailinglists: https://genode.org/community/mailing-lists Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
On Fri, Aug 05, 2022 at 03:05:54PM +, jkinney23--- via Dng wrote: > On Thursday, August 4, 2022, 02:53:33 p.m. PDT, Bruce Perens via Dng > wrote: > > I haven't followed more modern experimental operating systems. Mostly you > > don't hear as much about them these days, I think a > > lot of researchers use an existing Open Source OS as a base for some > > specific facility. > > That's a little disheartening to hear. I have been trying to find a program > in Canada where I can go study operating systems. Is there no one anywhere > doing serious OS research anymore? ...I guess I will stay with Youtube and > the Devuan mailing list then :) Jöchen Liedke, who died a few years ago, was doing some interesting work: the L3 operating system, leading to the L4 microkernel and hypervisor framework. Looks like Pistachio is the latest, without much recent activity. https://l4ka.org/ The L4Linux project is still active: https://l4linux.org/ -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
On Thursday, August 4, 2022, 02:53:33 p.m. PDT, Bruce Perens via Dng wrote: > I haven't followed more modern experimental operating systems. Mostly you > don't hear as much about them these days, I think a > lot of researchers use an existing Open Source OS as a base for some specific > facility. That's a little disheartening to hear. I have been trying to find a program in Canada where I can go study operating systems. Is there no one anywhere doing serious OS research anymore? ...I guess I will stay with Youtube and the Devuan mailing list then :) Jason ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
On Thu, 2022-08-04 at 14:53 -0700, Bruce Perens via Dng wrote: > > This goes way back. Mach did lightweight messaging and more (and survives > in MacOS, I think), Plan 9 did the graphics API == window system API. I pretty much like GNU/Linux just as it is, but I'd love to have a sane graphics built into the OS so I don't need to choose between entangled mess X and forever second-rate tragically modern Wayland. I wonder how the OS for the Atari ST did graphics. Now THAT was a machine! SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
On Thu, Aug 4, 2022 at 7:01 AM wrote: > Do you have some pointers to thoose experimental operating systems > so I can get a taste of what you are talking about ? This goes way back. Mach did lightweight messaging and more (and survives in MacOS, I think), Plan 9 did the graphics API == window system API. I haven't followed more modern experimental operating systems. Mostly you don't hear as much about them these days, I think a lot of researchers use an existing Open Source OS as a base for some specific facility. Thanks Bruce ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
On Thu, Aug 04, 2022 at 05:19:18PM +0200, Didier Kryn wrote: > Le 04/08/2022 à 00:36, Bruce Perens via Dng a écrit : > > The fundamental OS concept is "Everything's an API" rather than > > everything's a file. > > APIs rather than libraries and linking. > > etc... > > It seems to me that "everything is a file" could do it yet: the kernel > implements such an API though /proc, with netlink for asynchronous > signalling. A filesystem equivalent to /proc for user space, plus inotify > capability would just do it. And keep it simple stupid. I may be missing > something but I like to stick to simple concepts. Like in Inferno? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
Le 04/08/2022 à 00:36, Bruce Perens via Dng a écrit : The fundamental OS concept is "Everything's an API" rather than everything's a file. APIs rather than libraries and linking. etc... It seems to me that "everything is a file" could do it yet: the kernel implements such an API though /proc, with netlink for asynchronous signalling. A filesystem equivalent to /proc for user space, plus inotify capability would just do it. And keep it simple stupid. I may be missing something but I like to stick to simple concepts. -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
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 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 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 sho
Re: [DNG] Be prepared for the fall of systemd
What do we as a community need to do to get S6 into a "corporate friendly" state? What can I do to help? "Corporate-friendly" is not really the problem here. The problem is more "distro-friendly". Distributions like integrated systems. Integrated systems make their lives easier, because they reduce the work of gluing software pieces together (which is what distros do). Additionally, they like stuff like systemd or openrc because they come with predefined boot scripts that, more or less, work out of the box. There are two missing pieces in the s6 ecosystem before it can be embraced by distributions: 1. A service manager. That's what's also missing from runit. Process supervisors are good, but they're not service managers. You can read why here[1]. In case you missed it, here is the call for sponsors I wrote last year, explaining the need for a service manager for s6: [2]. It has been answered, and I'm now working on it. It's going very slowly, because I have a lot of (easier, more immediately solvable) stuff to do on the side, and the s6-rc v1 project is an order of magnitude more complex than what I've ever attempted before, so it's a bit scary and needs me to learn new work habits. But I'm on it. 2. A high-level, user-friendly interface, which I call "s6-frontend". Distros, and most users, like the file-based configuration of systemd, and like the one-stop-shop aspect of systemctl. s6 is lacking this, because it's made of several pieces (s6, s6-linux-init, s6-rc, ...) and more automation-friendly than human-friendly (directory-based config instead of file-based). I plan to write this as well, but it can only be done once s6-rc v1 is released. Once these pieces are done, integration into distributions will be *much* easier, and when a couple distros have adopted it, the rest will, slowly but surely, follow suit. Getting in is the hard part, and I believe in getting in by actually addressing needs and doing good technical work more than by complaining about other systems - yes, current systems are terrible, but they have the merit of existing, so if I think I can do better, I'd rather stfu and do better. Here are some ideas: - easier access to the VCS (git, pijul, etc) The git repositories are public: [3] They even have mirrors on github. All the URLs are linked in the documentation. I don't see how much easier I can make it. Note that the fact that it's not as easy to submit MRs or patches as it is with tools like gitlab or github is intentional. I don't want to be dealing with an influx of context-free MRs. Instead, if people want to change something, I'd like *design discussions* to happen on the ML, between human beings, and when we've reached an agreement, I can either implement the change or accept a patch that I then trust will be correctly written. It may sound dictatorial, but I've learned that authoritarian maintainership is essential to keeping both a project's vision and its code readability. - Issue tracking system The supervision ML has been working well so far. When bigger parts of the project (s6-rc v1 and s6-frontend) are done, there may be a higher volume of issues, if only because of a higher volume of users, so a real BTS may become an asset more than a hindrance at some point. We'll cross that bridge when we get to it. - CI/CD build chain (being careful not to make it too painful to use) Would that really be useful? The current development model is sound, I think: the latest numbered release is stable, the latest git head is development. The s6 ecosystem can be built with a basic configure/make/make install invocation, is it really an obstacle to adoption? I understand the need for CI/CD where huge projects are concerned, people don't have the time or resources to build these. I don't think the s6 ecosystem qualifies as a huge project. It won't even be "huge" by any reasonable metric when everything is done. It needs to be buildable on a potato-powered system! - "idiot proof" website - quick start / getting started guide - easier access (better?) Documentation I file these three under the same entry, which is: the need for community tutorials. And I agree: the s6 documentation is more of a reference manual, it's good for people who already know how it all works but has a very steep learning curve, and beginner-to-intermediate tutorials are severely lacking. If the community could find the time to write these, it would be a huge help. Several people, myself included, have been asking for them for years. (For obvious reasons, I can't be the one writing them.) Turns out it's easier to point out a need than to fulfill it. It's the exact same thing as the s6 man pages. People can whine and bitch and moan for ages saying that some work needs to be done, but when asked whether they'll do it, suddenly the room is deathly silent. For the man pages, one person eventually stepped up and did the work[4] and I'm forever grateful to them; I ha
Re: [DNG] Be prepared for the fall of systemd
What do we as a community need to do to get S6 into a "corporate friendly" state? What can I do to help? Here are some ideas: - easier access to the VCS (git, pijul, etc) - Issue tracking system - CI/CD build chain (being careful not to make it too painful to use) - "idiot proof" website - quick start / getting started guide - easier access (better?) Documentation On Thu, 4 Aug 2022, 09:21 Steve Litt, wrote: > On Wed, 2022-08-03 at 17:19 +, J.R. Hill 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. > > This hasn't been the case with runit. It's so darn simple people *do* > trust it, even > though it was written by one guy and he stepped away. > > > 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) > > True. All I can say is runit does one thing and does it well, appears to > have no > known security flaws, has a small attack surface, so there's little call > for > updates. > > > 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. > > The originator of runit gives many example scripts, AND they are trivial > to write. > See http://smarden.org/runit/runscripts.html . > > > > > > 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. > > I guess what I meant was https://github.com/void-linux/runit . That's the > source > code, maintained by the Void Linux project, and it's up to individual > distros to > package it for their distro. > > SteveT > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
Bruce Perens: ... > 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. ... Do you have some pointers to thoose experimental operating systems so I can get a taste of what you are talking about ? Regards, /Karl Hammar ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
On Wed, 2022-08-03 at 15:36 -0700, Bruce Perens 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. I find it symptomatic of the fact that a guy wrote some Rube Goldberg code and a corporation decided it would be a great idea to spend millions getting the Rube Goldberg code into many major distros. As far as us running our of road with the Unix API, systemd solves no problem and offers no improvement that couldn't have been solved or improved in a dozen different ways, almost all of which would have been more modular and less prone to vendor lock in. [snip] > There is room for replacement of systemd and continuation of Linux and BSD. Exactly! And if Redhat/IBM ever stops spending millions per year to keep systemd from collapsing under its own weight, that room becomes a necessity. > But we should be looking forward to something else as the next OS paradigm. In the preceding sentence, I'd change the "But" to "Also". SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
On Wed, 2022-08-03 at 17:19 +, J.R. Hill 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. This hasn't been the case with runit. It's so darn simple people *do* trust it, even though it was written by one guy and he stepped away. > 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) True. All I can say is runit does one thing and does it well, appears to have no known security flaws, has a small attack surface, so there's little call for updates. > 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. The originator of runit gives many example scripts, AND they are trivial to write. See http://smarden.org/runit/runscripts.html . > > 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. I guess what I meant was https://github.com/void-linux/runit . That's the source code, maintained by the Void Linux project, and it's up to individual distros to package it for their distro. SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
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 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
Re: [DNG] Be prepared for the fall of systemd
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 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
Re: [DNG] Be prepared for the fall of systemd
Steve Litt: ... Busybox doesn't do what I guess you want, for that you just fire up a process supervisor, there are a few to choose among. Remember busybox init is just a minimal init, everthing else is some other programs responsibility. You can think of busybox init as sysv init but with just one runlevel. But since you asked: > 1) Does Busybox init require the daemon to background itself? No, just place it last in /etc/rcS, and there can only be one such process. > 2) Does Busybox init give you a reasonable way to automatically restart the > process > after the process terminates? You can run it in its own console, and there you can have it to respawn just like a getty. > 3) Does Busybox init give you the choice of auto-restart or not for each > different > process? If it does, that's something specifically missing in Runit. Yes, start the process either in /etc/rcS or in its own "getty" line. Regards, /Karl Hammar ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
On Tue, 2022-08-02 at 11:25 +0200, k...@aspodata.se wrote: > Steve Litt: > ... > > * Runit > > * S6 > ... > > Why not busybox init, it handles gettys and the rest is up to > /etc/rcS, which you are free to make it do whatever you like. > > As a direct replacement for sysv init, you can use > for i in /etc/rcS.d/S* /etc/rc2.d/S* > do > $i start > done > > in rcS and similar for shutdown. Thanks Karl, Some questions: 1) Does Busybox init require the daemon to background itself? 2) Does Busybox init give you a reasonable way to automatically restart the process after the process terminates? 3) Does Busybox init give you the choice of auto-restart or not for each different process? If it does, that's something specifically missing in Runit. Thanks, SteveT ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
Steve Litt: ... > * Runit > * S6 ... Why not busybox init, it handles gettys and the rest is up to /etc/rcS, which you are free to make it do whatever you like. As a direct replacement for sysv init, you can use for i in /etc/rcS.d/S* /etc/rc2.d/S* do $i start done in rcS and similar for shutdown. Regards, /Karl Hammar ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Be prepared for the fall of systemd
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
