dinit comes with a sample service set that can technically result in a bootable system, but it hardly makes full use of dinit's potential nor it provides something that would be useful as a reasonable base for all dinit-using distros to share
that means everybody is sort of doing their own thing, which means software upstreams will not be able to ship distro-independent service files like they can with systemd, which is bad for serious adoption
i've been meaning to make my dinit-chimera https://github.com/chimera-linux/dinit-chimera largely reusable, and i believe it's currently the most advanced core service set that exists for dinit; but it's downstream regardless (and currently it makes some assumptions that might not be viable for everybody, but that will change, the most notable thing right now is usage of systemd-tmpfiles but i plan to have a custom helper come with it later instead), so i wonder if we could put some effort into making a common system? not a mandatory one, but at very least something officially recommended for potential adopters, so that software has something specific to target
Activity
9
q663y agohaving some names available would be a good baseline at least, though sooner or later some things may have to rely on service-manager-related infrastructure beyond dependencies, but we'll see i guess...
davmac3143y agoyeah, the tmpfiles issue is a good example of that. Let's see if anything else comes up. The service names is a good baseline as you say, we can start with that and build on it as necessary.
mohamad-supangat3y agosee https://wiki.artixlinux.org/Main/Dinit and https://github.com/mohamad-supangat/dinit.d
who knows will help
adamjonn2y agoi second that, rather the moving to Artix rather remove systemd in arch and have a quickest boot possible into a xinit session. gonna give it a stab some very good starters above, but a very bare minimal boot setup into a xsession would be very handy right handy right now rather then hacking systemd
notramo1y agoI'm working on an unofficial dinit setup for Void Linux, and I want to write an unofficial setup for Alpine Linux too.
Reusability of service files and scripts is probably not possible, because dinit does not provide enough features for it, and provides too much flexibility (less lock-in) compared to systemd. For example, Void Linux uses chpst -u for changing the user/group of the process, which is a Void-specific tool. Other distros might use sudo -u. In systemd, it's solved by having a built-in User= config value, and user/group changing is done inside systemd, but in dinit, it has to be done by external tools.
Some distros might prefix system users with _, e.g. _ntpd-rs instead of ntpd-rs (Void does this), this is another point where reusability is not possible. Standardization could require distros to use unified system user names for the services, however, it would make unofficial setups much more difficult (e.g. Void Linux with dinit).
In Void Linux, many services have some setup commands before starting the service. Maybe it's needed in Alpine too. These are shell scripts. Shell scripts use coreutils. There are many incompatible coreutils implementations: Busybox, Toybox, FreeBSD core utils, uutils, or the most widely used GNU coreutils. The shell scripts can be at least replaced per-distro, e.g. Chimera can supply a certain script based on FreeBSD coreutils and a Busybox-based one can be used in Alpine.
Non-Linux systems use different boot procedures and CLI tools, which introduce even more difference.
However, I think that the names of services and targets can be standardized, and it would be a welcome addition.
notramo1y agoThanks for the reminder, I'm quite new to dinit, and didn't know that. Unfortunately, it still can't change the group, only the user (if it's not the primary group of the user). Also, it does not solve the other points mentioned in my comment. But still it's good to know.
q661y agochanging the group of the process to something that is different from the user's actual primary group makes no sense
and also you are missing the point of this whole issue, because the issue is about core early-boot services
Sounds like a great idea to me. We can standardise the set of base services (particularly targets) that can be relied on to be available (eg. the names you have currently for chimera as per link above) and offer your current set as an example implementation, for example.