obarun stands for OpenboxRunit … but has been the home for arch based s6 implementation with tools (currently 66) to make s6 less hostile to MOST users of linux. Runit only lasted a few weeks before s6 was implemented and runit dumped. Currently featuring a graphic installer of base, openbox, jwm, xfce4, and plasma desktops and a setup of s6/66 to get you going.
joborun stands for JwmOpenBoxObarunRunit, so it is everything Obarun can be, plus runit that can coexist and alternatively boot instead of s6/66, but also replaces most core Arch pkgs with ones built in vaccuum of systemd/logind/udevd. Currently not including an installer, or an iso image, but an old fashioned tarball of the base and instructions on how to make it a bootable system within minutes. Joborun is basically a source based distro, although it provides 2 tarballs, base system, and builder system, and binary repositories of all packages it provides source for. You always need a binary system to build your binaries, joborun just makes the process easier and quicker, without frustrating fails.
What Obarun does with packages that include aspects and functionality of systemd tools is during installation eliminate those parts by deleting them, through a pacman hook. Joborun instead rebuilds all arch: core packages and most of their dependencies without systemd and libs. This provides a cleaner base system.
Joborun is also a proposal for independence, something Joborun developers hope would be a goal for Obarun as well, to escape the pressure by Arch to do updates when Arch decide updates should take place. This would of course require manpower and involvement in these projects. At least we now know it is possible when before we only thought it was theoretically possible. If the core utilities are there then everything else can be built. Well, almost everything, crap such gnome and KDE monstrosities heavily violating every sense of the term FOSS have no need to be built.
Joborun also builds kernels, where Obarun seem to have done so in the past but long abandoned the practice, leaving very outdated packages in the repositories. Kernel configuration appears to be consistent among 5.4 5.10 5.15 6.0 and 6.1, with clear preference for 5.10 being the most logical kernel for most systems, new and old. Joborun avoids zstd wherever possible, even inside the kernel, and turns off ipv6 capabilities in all software it can. Other than that it is as closely compatible with all obarun and arch packages. Gentoo users would call this a layer, but really it is an infrastructure for Obarun to run cleaner.
Speculators would say this makes no difference, but there are doubters as well of that view. Some packages have automake and autoconf capabilities and the environment you built software on makes a difference to the outcome. Simply, why would anyone need an init and service supervision system and libraries present in a clean chroot building environment? You don’t and shouldn’t.
There is also another characteristic of Joborun. In most distros you find a bootable system and a building environment being one and the same. A system that needs to boot and run software already packaged doesn’t need building/compiling/packaging tools. The opposite is also true, a building environment just needs the least amount of tools necessary to compile and build packages, it needs no kernel, modules, init, services, etc. unless specific software call for them as dependencies, such as kernel headers, or the entirety of udev/eudev, or init specific software. So Joborun linux separates the two as two different systems. One includes the minimal base to install X, wayland, a window manager, or a simple console system, the other, “jobbot” is a building system you can chroot to and build. In jobbot you have /src as a place to clone the joborun repositories (jobcore, jobextra, jobcomm) and the minimal chroot. You enter each pkg directory, install “deps” –> make dependencies for the pkg, acquire the signature key for the source if available –> sh key, then makepkg, and then removde “deps”, run the clean script, and the package is made and the environment is just as it was before you started. Simple, clean, easy to learn. You can use a script with the list of all packages and have a bootable system built entirely from source, in as much time as your machine’s capability allows.
So, before you cry that your messing around of s6/66 trees, services, and modules, made your system unbootable, you just add init=/usr/bin/runit-init to your bootloader’s linux line and your system will boot with runit instead. By comparison, 100% same services running, runit will boot faster and with less ram. From that point on though runit can’t keep up with s6, a much superior and advanced system. It is good to know you have a 2nd choice for when experimentation has gone bad.
Maybe someday joborun and obarun will become one project, the 66 developer will withdraw to his 66 work and leave the rest for packagers to worry about, instead of trying to do 7 jobs at once.
There is a future here, and there is constant work done on both sides, work that is complimentary not competitive. Work that is accumulating and shared, openly and freely. Eventually this make a big difference when comparing to some “system” starting yesterday with 20 packages available telling you you can built anything you like.
One of joborun’s drawbacks is a spread out use of resources and lack of its own server.
osdn for binary repository (cloud mirrors)
git.disroot.orgfor source repository (gitea)
email@example.com for email (trully open and trully free with 0% downtime)
a guest in pozol.eu website and joborun.neocities.org (open free with no ads, marketing, and intrusive scripting)
and wiki in wiki.joborun (same as git.disroot.org)
support center at joborun @ reddit (a bit of a zoo of a platform, but hey, if it works as a single support site for void it should work for joborun as well)
While everything for obarun is under obarun.org, web, wiki, irc/chat, git, OUR, binary repositories and archives, source documentation, forum, … each in need of maintenance and security by the 66 developer.
Unconventional distros for unconventional users who refuse to submit to power and market forces. As obarun’s moto says, take control of your data, through knowledge.
For everyone else there is elogind and make pretend systemd free distros.
12 thoughts on “Joborun vs Obarun linux”
As a one of the early user of Joborun and tester I find it rock solid and a charming distro except that getting its binary packages from OSDN repos is a big pain as somehow I always land with mirrors which only give me download speed at KB/S speed only and I wish someday the repos are shifted to some faster server.
May Obarun Live be used to facilitate the installation of Joborun?
I think you could but installation given on Joborun wiki is very simple and straightforward to follow
Joborun is my daily driver, the only Arch based distro that is fully committed against dbus, zstd and other pests. Yes, it’s based on Obarun but with a more hardcore attitude and i wish it could walk on its own legs in the near future, since Eric is on his own now and who knows how long will he be able to sustain the effort. The “perfection” would be achieved if Joborun will be able to get rid of GNU utilities and adopt musl, llvm, clang and so on, but it would require an enormous endeavor that the tiny devs team can’t afford at the moment. Hopefully the manpower will grow though the lead dev has stated that he does not want to target a broad audience.
Does Joborun have dbus-less rebuilds of gtk3 webkit-gtk etc.?
AFAIK the dev compiles packages turning off the dbus dependency everywhere he can’t, in some cases i get warnings in the console about dbus service not being enabled. If you inspect their repos you will see all the packages that have dbus off at source level, i can’t recall exactly if gtk3 and the like belong to them.
What would be suitable as substitute for GNU utils in Joborun? Busybox? Toybox? Suckless base? Openbsd userspace ports?
This isn’t clear at the moment. There is just an intention of adopting musl c library in a “distant future” but no mention of utils, it would be a nice question to submit to their reddit.
Hyperbola has got arch-install-scripts available, so I may try to install Jobarun from there. There is no documented way to do install Jobarun without arch-chroot.
As Jobarun is aro;;ing distribution, it would give me too many headaches as a daily driver, though. So NetBSD will continue in that role.
arch-chroot is nothing but a little script that has worked fine used on any linux (probably, only tried a few, void being one of them). It basically mounts proc sys dev and some tmpfs into the system that is chrooted at. This way you can install and make a boot image within this chroot with ro access to the host’s subsystems.
Is zsh mandatory on joborun? The maintainers seem to be obsessed with it.
within a few days there seem to be at least three comments/questions about joborun. It would be nice if you used directly their support forum (reddit.com/r/joborun) to address the project directly.
Most (nearly all) distros seem to suggest bash as a default shell, while there seems recently to be a term arising bashism/counter-bashism. Zsh is a potent alternative while maintaining compatibility.
Also, /etc/passwd is a simple place one can replace the default shell of a user or root. Whether zsh is additionally included in the base of the system I can’t imagine it is perceived as a burden. Furthermore, bash is mandatory by pacman. No bash no pacman/makepkg. Many scripts within pacman’s pkg are bash specific. zsh is also the default shell in Obarun from which I believe joborun inherited its use.