33 ms·

Armbian and Devuan = Armvuan

67 points by axy 3y ago

v55a 3y ago
neat! which direction is systemd going these days?
- hedora 3y ago
  All directions.
genericacct 3y ago
major kudos to anyone making rk3318 images out of this..
- genericacct 3y ago
  looks feasible https://github.com/armbian/build/blob/b7bc0015b064b825cb0340c7fd6492c3f3e78e2e/config/boards/rk3318-box.tvb https://github.com/armbian/build/blob/b7bc0015b064b825cb0340...
einpoklum 3y ago
> Both Armbian and Devuan have their own toolchains for ARM boards and both have fatal flaws: the former is locked to systemd-based distros, the latter has poor support for ARM boards. 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).
- axy 3y ago
  Everything is possible, the question is who will do that. I'm not an expert in anything either. Both toolchains make me depressed. But I'm glad I can run Devuan on my boards at last. Many thanks to both projects.
resolutebat 3y ago
Expanding out the stack here, Armvuan = Armbian + Devuan = ARM + Debian + Debian - systemd, so Armvuan = systemd-less Debian for ARM?
- bArray 3y ago
  > 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 makes no mention of Devuan: https://github.com/declassed-art/armvuan/commits/main https://github.com/declassed-art/armvuan/commits/main
  - axy 3y ago
    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.
  - axy 3y ago
    btw Armbian U Devuan is wrong, hn replaces + with and in title which is incorrect in this context
qwerty456127 3y ago
> 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 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.
- johnny22 3y ago
  that's the way the "immutable" distros are going. they provide a base system and then a ton of packages come from containers or flatpaks. Like things based on OpenSuSE's MicroOS or Fedora's Silverblue and Kinoite but it does require the flavors currently, since the DE are considered core packages.
  - qwerty456127 3y ago
    Can't we still have traditional repositories though? I personally dislike snaps and flatpaks because they usually are shipped with libarries hard-baked in rather than using separately-updatable libraries in the OS, using them also often means app duplication on per-user level and at least Snap didn't support Guest sessions (because of non-standard home directory path) the last time I checked.
    - lmm 3y ago
      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.
Schiphol 3y ago
Choosing the opposite syllables for the portmanteau would have given Debian, which has a nicer ring to it.
- popey 3y ago
  Devian, shirley?
- nimbius 3y ago
  all i know is i doubt my insurance covers armbian but i know it definitely already covers Devuan for my 19 year old arthritic cats seizures... ill be sure to ask my veterinarian if once daily Armvuan is right for pickles though.
mpol 3y ago
Is 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?
- b112 3y ago
  Since the change, you could always use debian without systemd. It was trivial, especially for servers. 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.
  - teddyh 3y ago
    > rsyslogd is not a default install item now, and when you install it, there is no init script. It’s in the orphan-sysvinit-scripts package.
    - b112 3y ago
      What a strange place to put it, there's loads of sysinit scripts still, but thanks for the heads up. 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.
      - teddyh 3y ago
        > What a strange place to put it, there's loads of sysinit scripts still 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.
ilyt 3y ago
I'm sure all six users of it will be happy
- nor-and-or-not 3y ago
  Does it matter how many users there are if the people who made it are happy with their work?
  - 0xpgm 3y ago
    Especially if the 6 users are completely happy with it, then that is validation that it has a solid use-case. It means there are possibly many more who would use it, just that they've not heard about it yet.
  - ilyt 3y ago
    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 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).
    - yjftsjthsd-h 3y ago
      > 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...
    - nor-and-or-not 3y ago
      Why do systemd proponents always compare it to SysVinit? 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.
throeaenndn 3y ago
[dead]

67 points by axy 3y ago

v55a 3y ago

neat! which direction is systemd going these days?

hedora 3y ago
All directions.

genericacct 3y ago

major kudos to anyone making rk3318 images out of this..

genericacct 3y ago
looks feasible https://github.com/armbian/build/blob/b7bc0015b064b825cb0340c7fd6492c3f3e78e2e/config/boards/rk3318-box.tvb https://github.com/armbian/build/blob/b7bc0015b064b825cb0340...

einpoklum 3y ago

> Both Armbian and Devuan have their own toolchains for ARM boards and both have fatal flaws: the former is locked to systemd-based distros, the latter has poor support for ARM boards. 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).

axy 3y ago
Everything is possible, the question is who will do that. I'm not an expert in anything either. Both toolchains make me depressed. But I'm glad I can run Devuan on my boards at last. Many thanks to both projects.

resolutebat 3y ago

Expanding out the stack here, Armvuan = Armbian + Devuan = ARM + Debian + Debian - systemd, so Armvuan = systemd-less Debian for ARM?

bArray 3y ago
> 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 makes no mention of Devuan: https://github.com/declassed-art/armvuan/commits/main https://github.com/declassed-art/armvuan/commits/main
- axy 3y ago
  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.
- axy 3y ago
  btw Armbian U Devuan is wrong, hn replaces + with and in title which is incorrect in this context

qwerty456127 3y ago

> 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 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.

johnny22 3y ago
that's the way the "immutable" distros are going. they provide a base system and then a ton of packages come from containers or flatpaks. Like things based on OpenSuSE's MicroOS or Fedora's Silverblue and Kinoite but it does require the flavors currently, since the DE are considered core packages.
- qwerty456127 3y ago
  Can't we still have traditional repositories though? I personally dislike snaps and flatpaks because they usually are shipped with libarries hard-baked in rather than using separately-updatable libraries in the OS, using them also often means app duplication on per-user level and at least Snap didn't support Guest sessions (because of non-standard home directory path) the last time I checked.
  - lmm 3y ago
    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.

Schiphol 3y ago

Choosing the opposite syllables for the portmanteau would have given Debian, which has a nicer ring to it.

popey 3y ago
Devian, shirley?
nimbius 3y ago
all i know is i doubt my insurance covers armbian but i know it definitely already covers Devuan for my 19 year old arthritic cats seizures... ill be sure to ask my veterinarian if once daily Armvuan is right for pickles though.

mpol 3y ago

Is 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?

b112 3y ago
Since the change, you could always use debian without systemd. It was trivial, especially for servers. 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.
- teddyh 3y ago
  > rsyslogd is not a default install item now, and when you install it, there is no init script. It’s in the orphan-sysvinit-scripts package.
  - b112 3y ago
    What a strange place to put it, there's loads of sysinit scripts still, but thanks for the heads up. 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.
    - teddyh 3y ago
      > What a strange place to put it, there's loads of sysinit scripts still 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.

ilyt 3y ago

I'm sure all six users of it will be happy

nor-and-or-not 3y ago
Does it matter how many users there are if the people who made it are happy with their work?
- 0xpgm 3y ago
  Especially if the 6 users are completely happy with it, then that is validation that it has a solid use-case. It means there are possibly many more who would use it, just that they've not heard about it yet.
- ilyt 3y ago
  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 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).
  - yjftsjthsd-h 3y ago
    > 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...
  - nor-and-or-not 3y ago
    Why do systemd proponents always compare it to SysVinit? 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.

throeaenndn 3y ago

[dead]