Our great sponsors
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
Fun fact, the “incident will be reported” message was close to being removed from sudo recently: https://github.com/sudo-project/sudo/commit/6aa320c96a37613663e8de4c275bd6c490466b01
i don't think openbsd userland port is very interesting either; it won't give you any benefit over freebsd's when running on linux, you will only lose features (without anything to make up for it, it won't even be significantly smaller), and what is left will be more or less the same, especially considering the amount of cross-pollination that is happening on the BSDs; i'm also somewhat skeptical that a multi-call single-binary arrangement is actually possible without major rewrites, I had previously investigated this for my own userland port (https://github.com/chimera-linux/chimerautils) and concluded that it's not really worth it or viable (I might take another look at a later point, but...)
artix support for all the inits is half-baked because they essentially do the bare minimum required to get things booting in a way equivalent to what a classic sysv-style boot would be, and then write service files against that core set, but without ever considering anything beyond that - you can easily tell the difference with dinit which i've seen many artix people talk about - artix dinit implementation is based around the sample service files that come with dinit and not only do not properly utilize dinit to its full extent, but also do not bother to provide any sort of reasonable infrastructure for other services to use, or put any effort towards having a standard service set that multiple distributions could use so that upstreams can easily provide compatible dinit service files - meanwhile chimera has its https://github.com/chimera-linux/dinit-chimera suite, which implements a flexible set of oneshots, support for service targets that can be used for reliable ordering, support for systemd-compatible binfmt files and other helpers and so on, all while ensuring it can be used in a cross-distro manner, as well as https://github.com/chimera-linux/turnstile which provides first-class user service support and session tracking so that you can have reliably managed user processes (e.g. dbus session bus, sound server, etc) and so on
artix support for all the inits is half-baked because they essentially do the bare minimum required to get things booting in a way equivalent to what a classic sysv-style boot would be, and then write service files against that core set, but without ever considering anything beyond that - you can easily tell the difference with dinit which i've seen many artix people talk about - artix dinit implementation is based around the sample service files that come with dinit and not only do not properly utilize dinit to its full extent, but also do not bother to provide any sort of reasonable infrastructure for other services to use, or put any effort towards having a standard service set that multiple distributions could use so that upstreams can easily provide compatible dinit service files - meanwhile chimera has its https://github.com/chimera-linux/dinit-chimera suite, which implements a flexible set of oneshots, support for service targets that can be used for reliable ordering, support for systemd-compatible binfmt files and other helpers and so on, all while ensuring it can be used in a cross-distro manner, as well as https://github.com/chimera-linux/turnstile which provides first-class user service support and session tracking so that you can have reliably managed user processes (e.g. dbus session bus, sound server, etc) and so on