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 system without
systemd/libs/elogind running dependencies and libraries, 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!
Eventually supplement all other repositories with our own, 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.
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.