6 ms·

Every Linux distro needs to adopt something like the Arch User Repository (AUR). It is hands down the nicest way to install packages out of all OSes, including

Every Linux distro needs to adopt something like the Arch User Repository (AUR). It is hands down the nicest way to install packages out of all OSes, including Mac and Windows. Everything is in the AUR, and if it isn't it is fairly easy to wrap it up and put it there yourself. Or one can just use Arch + `yay` and move on already!

_-david-_ 5y ago
It seems better to use flatpak, snap or appimage. These can be created once and run on any distro. Flatpak and snaps also include permissions on a per application basis so you can have some level of sandboxing. It is also easy to have proprietary applications which could help with more widespread Linux usage.
- ElijahLynn 5y ago
  That does seem better in the long run, especially if one has a very large disk drive. Until all packages are packaged up correctly, which could be many years from now. Something like AUR will be a necessity.
  - _-david-_ 5y ago
    Flatpak allows for sharing dependencies so disk space is less important. Often times software don't use the same versions though.
- pantalaimon 5y ago
  flatpak and snap feel so heavy - the startup times are reason enough to dislike them
  - AnIdiotOnTheNet 5y ago
    Flatpak also has unescapable limitations. For instance, Flatpak-installed Wireshark cannot actually capture packets. There is no way to give it the permissions at all.
    - esarbe 5y ago
      As mentioned in the issue[0], these limitations are not inescapable. It's just tedious to specify the permissions portal and currently there are no other applications that would require such a portal. So, not really a low-hanging fruit but certainly not insurmountable. [0] https://github.com/flathub/org.wireshark.Wireshark/issues/4 https://github.com/flathub/org.wireshark.Wireshark/issues/4
      - AnIdiotOnTheNet 5y ago
        As far as I can tell the escape is run dumpcap on the host and pipe the results through a fifo into the sandbox. Frankly that's pretty ridiculous and makes the flatpak nigh-useless. I'm not sure why flatpak is unable to support the ability to just not sandbox the application at all to allow for this sort of thing.
        esarbe 5y ago
        I guess that's because "this sort of thing" is really a very special use-case that is the primary focus of flatpak. That said: nothing prevents people from specifying an appropriate portal. I guess the intersection of people that a) want to run a network package capture program that for even for "normal" use requires root privileges or privilege escalation and b) want to run said app as a distro-independent software is rather small. Since the aim of flatpak is to provide easy sandboxing out of the box, I guess that running applications without sandboxing is not rally high priority for the developers. > Frankly that's pretty ridiculous and makes the flatpak nigh-useless. Not really. There are plenty of use-cases where flatpak shines.
        AnIdiotOnTheNet 5y ago
        > I guess the intersection of people that a) want to run a network package capture program that for even for "normal" use requires root privileges or privilege escalation and b) want to run said app as a distro-independent software is rather small. I don't see how these two things are at all related. There's no fundamental reason I can't have distro-independent software that is also able to run with root privileges if the user desires it. So it seems to me that Flatpak has baked-in this limitation (along with a bunch of others, but I digress). > Since the aim of flatpak is to provide easy sandboxing out of the box, I guess that running applications without sandboxing is not rally high priority for the developers. It would seem to me that not sandboxing something would actually be much easier than sandboxing it, but perhaps I'm unaware of a fundamental implementation detail of Flatpak. > Not really. There are plenty of use-cases where flatpak shines. That specific flatpak, not flatpak in general.
  - esarbe 5y ago
    There's no reason for a flatpak application to load slower than a 'native' application. It just namespacing[0] to separate the application Do you have measurements? Snap seems to be deeply flawed however. They use compressed files to store things that need to be mounted when one wants to run an application[1]. [0] https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap [1] https://www.freecodecamp.org/news/managing-ubuntu-snaps/ https://www.freecodecamp.org/news/managing-ubuntu-snaps/
zepearl 5y ago
I did use the AUR a few years ago when I was installing some Kodi component on an Arch distro, but I wasn't thrilled about it. I personally prefer Gentoo's way: user-owned "overlib"s for special stuff (and you would check the overlib's history to understand how committed the owner is), the rest merged into the main repository (if if manages to be merged, depending on QA).
AnIdiotOnTheNet 5y ago
> It is hands down the nicest way to install packages out of all OSes, including Mac and Windows. Hard disagree. The best way to install software of all the OSs I've ever used was the original Macintosh way: Just copy a single file. The same thing was used in RiscOS, NeXT, and a few others and is the inspiration for AppImage.

_-david-_ 5y ago

It seems better to use flatpak, snap or appimage. These can be created once and run on any distro. Flatpak and snaps also include permissions on a per application basis so you can have some level of sandboxing. It is also easy to have proprietary applications which could help with more widespread Linux usage.

ElijahLynn 5y ago
That does seem better in the long run, especially if one has a very large disk drive. Until all packages are packaged up correctly, which could be many years from now. Something like AUR will be a necessity.
- _-david-_ 5y ago
  Flatpak allows for sharing dependencies so disk space is less important. Often times software don't use the same versions though.
pantalaimon 5y ago
flatpak and snap feel so heavy - the startup times are reason enough to dislike them
- AnIdiotOnTheNet 5y ago
  Flatpak also has unescapable limitations. For instance, Flatpak-installed Wireshark cannot actually capture packets. There is no way to give it the permissions at all.
  - esarbe 5y ago
    As mentioned in the issue[0], these limitations are not inescapable. It's just tedious to specify the permissions portal and currently there are no other applications that would require such a portal. So, not really a low-hanging fruit but certainly not insurmountable. [0] https://github.com/flathub/org.wireshark.Wireshark/issues/4 https://github.com/flathub/org.wireshark.Wireshark/issues/4
    - AnIdiotOnTheNet 5y ago
      As far as I can tell the escape is run dumpcap on the host and pipe the results through a fifo into the sandbox. Frankly that's pretty ridiculous and makes the flatpak nigh-useless. I'm not sure why flatpak is unable to support the ability to just not sandbox the application at all to allow for this sort of thing.
      - esarbe 5y ago
        I guess that's because "this sort of thing" is really a very special use-case that is the primary focus of flatpak. That said: nothing prevents people from specifying an appropriate portal. I guess the intersection of people that a) want to run a network package capture program that for even for "normal" use requires root privileges or privilege escalation and b) want to run said app as a distro-independent software is rather small. Since the aim of flatpak is to provide easy sandboxing out of the box, I guess that running applications without sandboxing is not rally high priority for the developers. > Frankly that's pretty ridiculous and makes the flatpak nigh-useless. Not really. There are plenty of use-cases where flatpak shines.
        AnIdiotOnTheNet 5y ago
        > I guess the intersection of people that a) want to run a network package capture program that for even for "normal" use requires root privileges or privilege escalation and b) want to run said app as a distro-independent software is rather small. I don't see how these two things are at all related. There's no fundamental reason I can't have distro-independent software that is also able to run with root privileges if the user desires it. So it seems to me that Flatpak has baked-in this limitation (along with a bunch of others, but I digress). > Since the aim of flatpak is to provide easy sandboxing out of the box, I guess that running applications without sandboxing is not rally high priority for the developers. It would seem to me that not sandboxing something would actually be much easier than sandboxing it, but perhaps I'm unaware of a fundamental implementation detail of Flatpak. > Not really. There are plenty of use-cases where flatpak shines. That specific flatpak, not flatpak in general.
- esarbe 5y ago
  There's no reason for a flatpak application to load slower than a 'native' application. It just namespacing[0] to separate the application Do you have measurements? Snap seems to be deeply flawed however. They use compressed files to store things that need to be mounted when one wants to run an application[1]. [0] https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap [1] https://www.freecodecamp.org/news/managing-ubuntu-snaps/ https://www.freecodecamp.org/news/managing-ubuntu-snaps/

zepearl 5y ago

I did use the AUR a few years ago when I was installing some Kodi component on an Arch distro, but I wasn't thrilled about it. I personally prefer Gentoo's way: user-owned "overlib"s for special stuff (and you would check the overlib's history to understand how committed the owner is), the rest merged into the main repository (if if manages to be merged, depending on QA).

AnIdiotOnTheNet 5y ago

> It is hands down the nicest way to install packages out of all OSes, including Mac and Windows. Hard disagree. The best way to install software of all the OSs I've ever used was the original Macintosh way: Just copy a single file. The same thing was used in RiscOS, NeXT, and a few others and is the inspiration for AppImage.