Armbian and Devuan = Armvuan
github.com
github.com
ill be sure to ask my veterinarian if once daily Armvuan is right for pickles though.
By the way, reading this, an idea just hit me. It persistantly seems evident distro maintains often struggle to maintain huge repositories in both well-tested and up-to-date state. Why don't we separate OS distribution and apps repos into separate independent projects? Perhaps it could be enough for distro authors to concentrate on maintaining the actuall OS (system packages). Probably also a humble number of essential apps. Everything else could be then maintained in form of PPAs by whoever is interested.
Even existence of distro "flavours" focusing on specific DEs always felt a quirk to me. An operation of installing and choosing a specific DE should never have been requiring any attention from the distro author. The fact it does suggesrs there are quirks which have to be addressed, these should better be polished away globally than worked around in every installation script.
Do you though? Most users just want the latest upstream release, packaged up so they don't have to deal with compiling or dependency management themselves (and have a chance of a clean uninstall), not any extra testing or integration. Hence the popularity of PPAs, Snap/FlatPak, etc..
Recompile, yes. The rest, probably not - upstream usually does that better than any distro. Distro-specific bugs are usually caused by that distro's changes made to "integrate" the package into the distro, which are usually not something the user wants. Again, hence the popularity of PPAs and Snap/FlatPak.
> Fedora often publishes even pre-release versions of some software packages, if you want to talk about "latest" version.
Fedora has the resources to do that because they're managed by a huge company, and they're big enough that upstream will likely make changes to accommodate them. Most distros aren't on that level.
The OS engineers are usually not the ones maintaining Wesnoth, and if they are it's because they want to.
There are separately updatable shared libraries via runtimes, they're just not managed by the OS (on purpose).
you mean like flatpack and snap which also have the benefit of decoupling .so dependency management?
or maybe like nix which you can run as a package manager on other dristros then NixOS?
The DDs who work on, say, kernel packaging are not necessarily the same DDs who work on Wesnoth packaging.
For one like the other comment pointed out different people internally often already work on different packages.
For the other external repositories are a thing.
But they are often not trusted, and if a package is maintained by upstream often it is only for one or two repos.
So it fix it you would need a repository which can work across distributions. Where maintainers exist independent of the distributions but also the organization is big and reputable enough so that people do trust it.
But to have that you need to use technology which abstracts over differences in distros especially wrt. .so dependencies. Like nix, flatpack or snap.
Or in other words I believe you either have what we have today. Or you have a core OS (which still needs packages and package managing!) and the rest is using technology similar to nix, flatpack or snap to provides package repos across distros.
Because applications rely on libraries in the distribution and need to be in sync for when they change.
Ways around this are Flatpak, where those shared libraries for applications are shared runtimes that are distro agnostic.
The Linux Filesystem Hierarchy Standard also tried to do what you are saying, but in a less ambitious way.
Desktops took more care, but that was still a non-issue.
But lately, especially since bookworm, things are less solid. rsyslogd is not a default install item now, and when you install it, there is no init script.
This is fine for servers which want centralized logging under systemd, because of course it can start syslog with the included unit file.
But if you remove systemd, by default you have no logging daemon, and once installed, no init script by default.
Easy to fix, but a reduced ease of use.
If you want a systemd-free Debian, then Devuan is your go-to.
It’s in the orphan-sysvinit-scripts package.
Re: other response...
None of those things require systemd under debian, and it's easy to use sysvinit. I run loads of systems without systemd.
Well, apparently the rsyslog daemon itself does not include a sysvinit script; i.e. the rsyslog developers did not write or supply one. So it falls to the distribution, in this case Debian, packager to supply such a script. The Debian packager for the rsyslog package has chosen not to do the work of maintaining a sysvinit script. Debian has further chosen not to require sysvinit scripts for every package. Since maintaining a package is volunteer work, nobody could reasonably expect packagers to do work they don’t want to do which is not required. And thus the rsyslog package does not contain a sysvinit script.
The sysvinit scripts which used to be present in many Debian packages but which the corresponding packagers have chosen to not maintain, are still offered in the orphan-sysvinit-scripts package. The sysvinit-core package “recommends” (a Debian packaging term) the orphan-sysvinit-scripts package, which means that everybody who installs the sysvinit-core package should get the orphan-sysvinit-scripts package installed by default.
Also Debian having the possibility of providing systemd alternatives now, doesn't guarantee that this will be so forever. My personal guess is that at one point, systemd will be the only de-facto working init for desktop systems on Debian.
For the other 9X%, the world has moved on
Isn't it possible to improve Devuan's toolchain so that it better supports ARM boards?
And, for that matter - isn't it possible to do the same for Debian itself, so that the delta to Devuan would inherit decent support for ARM boards?
I'm not a toolchain expert, so an answer with links to explanation of relevant concepts/jaron would be appreciated.
---
Regardless - I'm always happy to hear news about widening adoption and influence of Devuan. I believe a non-systemd distribution is the way to go and am glad Devuan offers that for the Debian space (while Debian, unfortunately, forces systemd on you and it's not just an option).
Not quite:
Armvuan = Armbian U Devuan = (Debian + ARM) U (Debian & ¬systemd) = Debian + ARM
Therefore: Armvuan == Armbian
If you look at the top of the file tree, Armbian is checked out as a submodule and forms the basis of the project. Also note that the commit history is short and makes no mention of Devuan: https://github.com/declassed-art/armvuan/commits/main
I would not say Armbian is the basis of the project. Its builder is just a useful tool. I tried to distance from it as far as possible, bearing in mind Devuan's arm-sdk as the next toy to play with. I gave it a try as well, but found Armbian builder is better.
Like, I have plenty of issues with systemd but still on span of 461 systems we manage (mostly Debian with some centos here and there) with variety of use cases (from "legacy" to k8s running on ceph cluster) it saved us tens of thousands lines of code and allowed some tricky use cases to be far more reliable than before.
Because apparently despise vehement claims sysV scripts are "simple" and "straightforward" it turns out there is plenty of edge cases that most developers don't fix in those scripts.
For example the fact doing start -> status immediately after in many Java apps will tell you your application is not running, because developer delegated Java app to write its own pid file and that takes time for JVM to start. So if something like Pacemaker does exactly that (start app, wait for start script to finish, run status, Pacemaker thinks app didn't start and fails the service).
Compare it to Runit (Void Linux, antiX, Devuan package, as well as packages for all BSDs), OpenRC (Alpine, Gentoo, Devuan package, compatible with FreeBSD and NetBSD), … with S6, which many folks (including me) do use on their Linux and BSD systems.
I, too, operate a fleet of servers without any trouble using Runit and OpenRC.
If you don't want people sticking to their principles, you should probably avoid Debian too...