neat! which direction is systemd going these days?
All directions.
Armbian and Devuan = Armvuan
41–50 of 55 posts
Re: Armbian and Devuan = Armvuan
#42Expanding out the stack here, Armvuan = Armbian + Devuan = ARM + Debian + Debian - systemd, so Armvuan = systemd-less Debian for ARM?
> Expanding out the stack here, Armvuan = Armbian + Devuan = ARM + Debian + Debian - systemd, so Armvuan = systemd-less Debian for ARM? 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…
Daedalus is the codename of Devuan's current release (same as bookworm in Debian) and it's on the top of tree too. Well, almost. Anyway, it's visible on gh.
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.
Re: Armbian and Devuan = Armvuan
#43Expanding out the stack here, Armvuan = Armbian + Devuan = ARM + Debian + Debian - systemd, so Armvuan = systemd-less Debian for ARM?
> Expanding out the stack here, Armvuan = Armbian + Devuan = ARM + Debian + Debian - systemd, so Armvuan = systemd-less Debian for ARM? 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…
btw Armbian U Devuan is wrong, hn replaces + with and in title which is incorrect in this context
Re: Armbian and Devuan = Armvuan
#44Is Devuan still having a usecase? No offense, I am simply curious. Lately I see statements that you can use standard Debian and have it instaled without systemd. It won't be the default I assume, but how do Devuan and Debian (without systemd) compare nowadays?
Of course it has a use-case. The target audience may be small but for them it is important.
For the other 9X%, the world has moved on
Re: Armbian and Devuan = Armvuan
#45> It is built in the simplest way, using Devuan debootstrapped system with kernel, dtb, u-boot, and board support packages from Armbian 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 cou…
> 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
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.
Re: Armbian and Devuan = Armvuan
#46Earlier quoted context omitted.
If you don't want to use something like snap/flatpak then all the distributions using your PPA repository have to provide the same libraries packaged the same way, and at that point what are they going to even gain from being different distributions in the first place? If someone wanted to make a fork of Ubuntu but all the packages and contents are exactly the same as mainline Ubuntu then they'd just use Ubuntu.
Provide source packages. It works for hundred thousand of packages, so why your package is an exception?
It evidently isn't working well enough - why are snap and flatpak a thing at all if source packages are good enough? Why do users want programs to get picked up as part of a distro's repositories?
Re: Armbian and Devuan = Armvuan
#47> It is built in the simplest way, using Devuan debootstrapped system with kernel, dtb, u-boot, and board support packages from Armbian 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 cou…
I think you are describing GNU auto tools. It ends up being too complicated because projects have anti-dependencies with each other. The Linux Filesystem Hierarchy Standard also tried to do what you are saying, but in a less ambitious way.
Actually come to think that didn't the Linux Standard Base have some goal of binary compatibility?
Re: Armbian and Devuan = Armvuan
#48Earlier quoted context omitted.
Does it matter how many users there are if the people who made it are happy with their work?
Are they ? Because all of that looks like posturing on principles. 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 vehe…
> Because all of that looks like posturing on principles.
If you don't want people sticking to their principles, you should probably avoid Debian too...
Re: Armbian and Devuan = Armvuan
#49Earlier quoted context omitted.
How would that solve the issue of keeping repositories in a both well-tested and up-to-date state? It seems to me it would only make the problem worse because we'd have different, possibly incompatible or unmaintained PPAs
It would just let the OS engineers concentrate on the OS. Potentially making better OSes, maybe also more OSes to choose from, these being actually diverse with original ideas rather than making different app/version choices their key differences. "Just don't do what you can't really do well with reasonable ease, better just do the job which actually is yours".
The point of an OS is to facilitate the applications; there's an old law of project management that improvement happens mainly at the interfaces. The idea of making an OS that will run the same applications with the same interfaces but somehow be better is fundamentally incoherent.
Re: Armbian and Devuan = Armvuan
#50Earlier quoted context omitted.
Provide source packages. It works for hundred thousand of packages, so why your package is an exception?
It evidently isn't working well enough - why are snap and flatpak a thing at all if source packages are good enough? Why do users want programs to get picked up as part of a distro's repositories?
As user, I want application to be tested and integrated with my distro by a competent maintainer. As application developer, I want to deliver latest version of my application to all users without additional testing, integration, and discussions with maintainers of all Linux distributions.