Arch, beyond the choice to incorporate systemd into the distribution, in the past few years it has been taking turns against its own principles. "To maintain isolated software as close to the latest release as possible, with little intervention, and alteration, independent of each other as possible, etc." Instead it is getting more and more tangled around systemd functionality and features. In many cases those are added unnecesseraly or without being intended upstream.
We would like to reverse this course.
Other distributions call themselves "free of systemd" by substituting pid1 with another init system. There are several good choices out there, but beyond init, for lack of further needed work, or sacrificed automatization that systemd provides, they adopt the remaining systemd functionality through various subsystems. Meanwhile systemd incorporates more and more traditional unix subsystems into its own mega-software which, beyond the kernel, it does it all.
To call a blob by its name, this is pure laziness and submission to fully comply with the IBM/RH doctrine. One system controls "everything". Elogind in particular, but there are others. Cgroups, dbus, sysusers, tmpfiles, net-control, chron,... the list keeps getting longer and longer.
All of those point to automation, and less user/sysadmin control. It is the Microsoftization of unix/linux. We meed to stop this trend by providing alternatives for those who understand and realize the importance of choices and customization/optimization. The rest deserve their own demise, of turning their systems into dummy-terminals of a mega-Corporation.
If we don't get this started now, it may become too complex and nearly impossible to do in the future.
Other projects that share our anxiety and discomfort, have followed independent routes, they have created wonderful core/base systems for sys-admins of servers, and other industrial uses, but lack a variety of less essential software. Let's admit it, we may not appreciate the automation and ease of access to software that Debian and Arch provide, but between more serious work and sleep, we may need a break to browse the news, play a game of poker or chess, use some design, drawing, music, video program,... and this becomes a tedious task to port this software into this "independent" base. It takes work to do this of course and human resources are at times more scarce than material resources.
There is Void, Alpine, Adelie, who appear to be well developed full distributions. Alpine and Adelie are great, but are more industrial in focus than a general distribution. Void on the other hand would have been great, if it wasn't for its lazy turn to adopt elogind, for being in some form of restructuring transition, with a package management left without an author, and no prospects of developing or adopting another. Void has made some quick U-turns in several ways in recent years, and its developers are running thin. Not as cutting edge as Arch by far now, and a mismatch between what is moving ahead and what is larking behind. Gemerally a great system with some very peculiar characters running it, and tons of contributing hours that are as appreciated as the slaves in a Roman Gallera. Just take a peak at the PR loads and "Dev-team" commits. Not a very happy workplace, that usually downgrades itself into poor software cohabitation.
Because we need a fresh start with specific goals, to get rid of udevd for example (and adopt mdevd), dbus (in need for another bus system such as the oned developed by skarnet), to do what Void has shown as possible, same structure distribution for many architectures and based on Musl as well as Glibc.
To provide a combat front against the influence and chokehold large corporations are putting on FOSS.
How?
Use Arch's approach to building and templates, pacman/makepkg, to have access to this huge database of software templates. By eliminating the presence of systemd in the Core repository entirety (done), and all of make dependencies borrowed from other repositories, (nearly done), and ensuring that everything builds together with everything else.
Maintain maximum compatibility, by making as few changes to templates/recipes/PKGBUILDs as possible, so nearly all software in Arch and AUR can be built in our system as well.
Creating a set minimal building environment, much leaner than Arch's "base-devel", to be adopted in a chrooted builder, a container, or virtual machine, have a very precise base with precise additional make dependencies per package, so at the end the system is left clean and as before, so the next package can be built reliably and in sequence. If you have 100 pkgs that only take 5-15" to build (beyond download of source-code), within a few hours the entire system can be rebuilt from 0, with little human input. Gradually adopting a similar system to Gentoo's flags, certain assumptions and choices can be adopted by the user to customize a unique built of the entire system. (we are working on this).
Systemd is 100% absent. Zstd is deactivated anywhere that it has recently been added and/or can possibly be turned off. Dbus prohibited from forcing sw failure due to its absence. ipv6 turned off in an "astounding" number of software (including Xorg-server) while we are all too unsure how we can set up network security around its peculiarities and differences from ipv4. In earlier experiments we also tried udevd substition, but this needs to wait a bit, despite of success, for mdevd better configuration scripts. Very little but important work left to do around mdevd, at least as far as X/wayland full compatibility.
Holding back on kernel rush a bit, having for now linux-lts as 5.10 and linux as 5.15 (new short life -lts), equally turning zstd and ipv6 off. Unless important security updates occur we may jump a few kernel releases as they take 3-4.5hours each to produce a binary package.
Goals of joborun-linux
Stay as compatible to Arch-Linux and packaging as possible
Build everything that makes a minimal base system and base devel tools for building software in the absence of systemd and its related libraries
Provide the user/sys-admin an easy way to build and upgrade their chosen software from source instead of relying on binary blobs built in possibly incompatible systems.
Suggest a more reasonable working graphic environment that depends less on automation and control of strange polkit, logind, dbus intercommunication, automounting and dismounting. Use a leaner more controllable and secure system.
Compliment Obarun's effort to provide a state of the art init and service supervision system without systmed/libs running dependencies, therefore releave its burden of having to build software based on Arch tools infested by systemd.
Maintain the cutting/bleeding edge contact with all upstream sources of software by following Arch-Linux testing repositories.
Discard suspiciously complex mega-corporation tools recently adopted, such as zstd (facebook's FOSS compression/decompression software), orarcle's zfs (also incorporating internally facebook's zstd), and building tools such as google's gtest (used for building zstd!) and return to good trusty alternatives such as xz, gz, bzip2, lzip etc.
Easily reconfigurable and currently tested with 0 ill effects, why have we incorporated a solution to other peoples' problems by adding ipv6 complexity to where it doesn't belong? Simply the internet is not "ours", it is "theirs", a handful of corporations and a few government agencies control its entirety. Ipv6 came to solve "their" problem, not ours. When it becomes ours we will deal with it. So to test this, we have turned ipv6 off from kernel to x11. You'll be surprised how many pieces of your software have direct ipv6 connectivity! The only few sites that can't be reached are ipv6 test sites that tell you you have ipv6 connectivity. We can't reach those, and they can't reach us!
Provide a working solution of how to compare two or more init and service supervision/management systems by making runit and s6/66 coexist in the same system, and the choice to boot and run either one. Encourage therefore the so called init freedom not in the way artix has forced the split choice but simply altering the bootloader's command.
Eventually supplement all other repositories with our own (if Obarun declines to cooperate and join the effort), still use pacman and follow Arch-Linux development but rely on solely source built software. This goal will depend on the collaborative effort of community members/joborun sys-admins.
Finally, when the conditions are right, and under collective decision, to parallely build the same system based on the musl C-library instead of the traditional GlibC, due to its size, cleaningness, and speed. If Void can do it, why not have an ARCH-musl flavor?
Help us redefine goals, principles, and direction by contributing both ideas and work. Ideas are cheap without commitment to contribute work. This project will only go as far as its involved community will like to take it.