3 ms·

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

> 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.
    - qwerty456127 3y ago
      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.
      - CorrectHorseBat 3y ago
        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
        qwerty456127 3y ago
        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".
        CorrectHorseBat 3y ago
        An OS with missing and/or broken packages is not a better OS. The OS engineers are usually not the ones maintaining Wesnoth, and if they are it's because they want to.
        lmm 3y ago
        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.
    - oneshtein 3y ago
      Provide source packages. It works for hundred thousand of packages, so why your package is an exception?
  - jcastro 3y ago
    > using separately-updatable libraries in the OS There are separately updatable shared libraries via runtimes, they're just not managed by the OS (on purpose).
- Vogtinator 3y ago
  MicroOS doesn't require flavors. You can select whatever package selection you want during installation.
RobotToaster 3y ago
I think source mage tried to do that?
dathinab 3y ago
> 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?
- qwerty456127 3y ago
  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).
  - dsr_ 3y ago
    You are describing the current state of Debian, just with multiple repos instead of one. The DDs who work on, say, kernel packaging are not necessarily the same DDs who work on Wesnoth packaging.
  - dathinab 3y ago
    We already have that. 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.
hedora 3y ago
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.
- yjftsjthsd-h 3y ago
  Actually come to think that didn't the Linux Standard Base have some goal of binary compatibility?
PlutoIsAPlanet 3y ago
> 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.

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.
  - qwerty456127 3y ago
    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.
    - CorrectHorseBat 3y ago
      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
      - qwerty456127 3y ago
        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".
        CorrectHorseBat 3y ago
        An OS with missing and/or broken packages is not a better OS. The OS engineers are usually not the ones maintaining Wesnoth, and if they are it's because they want to.
        lmm 3y ago
        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.
  - oneshtein 3y ago
    Provide source packages. It works for hundred thousand of packages, so why your package is an exception?
- jcastro 3y ago
  > using separately-updatable libraries in the OS There are separately updatable shared libraries via runtimes, they're just not managed by the OS (on purpose).
Vogtinator 3y ago
MicroOS doesn't require flavors. You can select whatever package selection you want during installation.

RobotToaster 3y ago

I think source mage tried to do that?

dathinab 3y ago

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

qwerty456127 3y ago
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).
- dsr_ 3y ago
  You are describing the current state of Debian, just with multiple repos instead of one. The DDs who work on, say, kernel packaging are not necessarily the same DDs who work on Wesnoth packaging.
- dathinab 3y ago
  We already have that. 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.

hedora 3y ago

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.

yjftsjthsd-h 3y ago
Actually come to think that didn't the Linux Standard Base have some goal of binary compatibility?

PlutoIsAPlanet 3y ago

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