Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Armbian and Devuan = Armvuan

github.com

Post reply on HN
Print view View original

11–20 of 55 posts

Re: Armbian and Devuan = Armvuan

#11

Post by bArray »

resolutebat wrote: post #6

Expanding 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 makes no mention of Devuan: https://github.com/declassed-art/armvuan/commits/main

Re: Armbian and Devuan = Armvuan

#12

Post by qwerty456127 »

johnny22 wrote: post #10
qwerty456127 wrote: post #8

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

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.

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.

Re: Armbian and Devuan = Armvuan

#13

Post by mpol »

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?

Re: Armbian and Devuan = Armvuan

#14

Post by b112 »

mpol wrote: post #13

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?

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.

Re: Armbian and Devuan = Armvuan

#15

Post by RobotToaster »

qwerty456127 wrote: post #8

> 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 source mage tried to do that?

Re: Armbian and Devuan = Armvuan

#16

Post by dathinab »

qwerty456127 wrote: post #8

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

> independent projects? P

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?

Re: Armbian and Devuan = Armvuan

#17

Post by lmm »

qwerty456127 wrote: post #12
johnny22 wrote: post #10

Earlier quoted context omitted.

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.

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.

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.

Re: Armbian and Devuan = Armvuan

#18

Post by qwerty456127 »

lmm wrote: post #17
qwerty456127 wrote: post #12

Earlier quoted context omitted.

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.

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.

That's Okay. What I meant was just reorganizing an OS and its nonessential apps repository/ies into 2 (or more) separate projects, not making a repository compatible with every distro out there.

Re: Armbian and Devuan = Armvuan

#20

Post by qwerty456127 »

dathinab wrote: post #16
qwerty456127 wrote: post #8

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

> independent projects? P 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?

Not really. I just meant that an OS team probably should only work on engineering and shipping the actual OS and should not dedicate a minute of their time to running a repository with Audacity or Wesnoth in it (I like and use both). Someone else should (as long as they feel interested).
Post reply on HN