Re: [DNG] elogind on a server?
On Wed, Aug 03, 2022 at 09:55:23AM +0200, Joril via Dng wrote: > Hi everyone! > > I've just installed a minimal Chimaera on a VM from > devuan_chimaera_4.0.0_amd64_server.iso > > I see that it has installed elogind, but is this required on a server? What > will I miss if I remove it? I don't have elogind installed on my server, and don't seem to have problems. I suppose you can try to purge it, and see what else it wants to remove before answering yes or no. Greg -- web site: http://www.gregn.net gpg public key: http://www.gregn.net/pubkey.asc skype: gregn1 (authorization required, add me to your contacts list first) If we haven't been in touch before, e-mail me before adding me to your contacts. -- Free domains: http://www.eu.org/ or mail dns-mana...@eu.org ___ 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
[DNG] Init respawns - was: Be prepared for the fall of systemd
Two empire falls recorded during the last two millenia it are the fall of the mighty Roman Empire and that of the Ottoman Empire. Both were extremely powerful influencing most of the worlds of their times, but they fell. What I expect from systemd and its adoption by many distributions is to recognise its problems and work harder to implement any advantages it may have had. Like many Devuaneers (users and advocates of Devuan), I expect an init system to remain an init system and package modularity to persist. I also expect a predictable behaviour from an init system. On my Raspberry Pi, systemd occasionally lists sound cards erratically breaking their ID number. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Init respawns - was: Be prepared for the fall of systemd
marc: > Steve Litt: > > 1) Does Busybox init require the daemon to background itself? > > So I seem no reason why "nohup daemon > /var/log/logfile &" isn't sufficient > for this, or is there something I am not aware of ? The requirement for deamons not to background is so that the process manager: 1, will get a SIGCHLD when the process terminates instead of scanning running processes or log files 2, don't need a pid file to find the process for the purpose of terminating it or something else 3, will get log output from a file descriptor instead of scanning syslog possible other things... Depending of your own requirements, that might be important or not. > > 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. ... > TL;DR: just install better daemons ;) ACK. But you have to write them also, what others write is usually out of your hands. 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
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
[DNG] elogind on a server?
Hi everyone! I've just installed a minimal Chimaera on a VM from devuan_chimaera_4.0.0_amd64_server.iso I see that it has installed elogind, but is this required on a server? What will I miss if I remove it? Thanks! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Init respawns - was: Be prepared for the fall of systemd
> Thanks Karl, > > Some questions: Hello > 1) Does Busybox init require the daemon to background itself? So I seem no reason why "nohup daemon > /var/log/logfile &" isn't sufficient for this, or is there something I am not aware of ? > 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. At the risk of pinning my own interpretation on this: I suppose for quick, dirty and crashy hacks maybe automated restarts are useful to paper over some problems. But if the daemon you are running is likely to crash, it might also just hang in an infinite loop or leak file descriptors, or fill up a partition or grind through swap, things that a respawn doesn't really solve ... We are often told that "thesedays computers are cheap and programmers are expensive" as an excuse for writing flaky software, and from the perspective of the greedy and immortal AI that is a corporation, this makes sense - a bit of bespoke software, even if flaky, might do the work of a human more quickly and cheaper while the costs are externalised. But the free software universe things are different - unreliable or bloated software wastes the time and hardware resources of thousands, perhaps millions of people. And even if you are happy to ignore the environmental costs (electricity, more hardware bought more often), then maybe some other reasoning might be persuasive: I certainly often marvel at the craftsmanship of people from previous ages - from as small as an excellent hand tool to as expansive as a church, mosque or similar - those things were made not "meh, good enough", but as good as humanly possible, and I would think that the free software world has some similarities there - while software might be written to scratch an itch, the solution is often created for the joy of it, for the satisfaction of building something really good - be it just for fun, the desire to leave a legacy or building a contemplative mandala. TL;DR: just install better daemons ;) regards marc ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
