6 ms·

Didn't Snap appear first? Why is FlatPak not an example of NIH?

by willtim 10y ago

seenitall 10y ago
Exactly. Snaps grew out of the work to make Ubuntu mobile phone apps secure and easy to update. They are a great way to publish software, worth creating regardless of all the anti-canonical trolling. And they work fine across distros except where RH has actively tried to cripple them. That's their right, but wow, toxic.
- jhasse 10y ago
  > RH has actively tried to cripple them Source? Snaps require AppArmor which is used by Ubuntu and openSUSE. This makes it harder to integrate Snaps into Red Had (SELinux) distros, but I wouldn't say that this is something RH does actively to cripple them.
  - mhall119 10y ago
    Snaps need a security backend like AppArmor in order to run in confinement. Without it, they can still be run unconfined. And while AppArmor+seccomp is the only working security backend, snapd is designed to support alternate backends, so one could be made for SELinux, we just need someone with SELinux experience to write it (our in-house expertise is in AppArmor)
- vetinari 10y ago
  Snap is not vendor neutral - it has hard coded dependence on Canonical infrastructure. If you want to provide your own, tough luck. Calling to attention about that is not anti-canonical trolling. It's avoiding creating a dependence on a third-party.
  - mhall119 10y ago
    s/tough luck/patches welcome/
    - vetinari 10y ago
      Patches here: https://github.com/flatpak/flatpak https://github.com/flatpak/flatpak ;)
gens 10y ago
It is rare to see something come out of Fedora that is not NIH. As for all the mentioned package/image managers, IMO they all bring more problems then solutions (except maybe nix). Dependency resolution brings sloppiness and keeping the programs dependencies up to date would kill the internets and hard drives (compared to a normal package manager). They should just build a build bot and amen (or just not do anything). The only "problem" they solve is proprietary program distribution, and that is solved by a Filesystem Hierarchy Standard (and fd.o) compliant installer such as MojoSetup (as used by GoG).
- pmontra 10y ago
  Yeah, my worry is that when a vulnerability hits libc we have to download all the snaps again and the vulnerable libc is still there in the abandoned snaps. There are many other libraries used by many programs that would suffer from the same problem. I'm thinking about openssl. Edit: somebody answered to my doubts in a comment here https://news.ycombinator.com/item?id=13559060 https://news.ycombinator.com/item?id=13559060
the_why_of_y 10y ago
FlatPak is a rename of xdg-app, which is the successor of Glick2, which is the successor of Glick, which was released in 2007, all by the same author.

Didn't Snap appear first? Why is FlatPak not an example of NIH?

by willtim 10y ago

Didn't Snap appear first? Why is FlatPak not an example of NIH?

Exactly. Snaps grew out of the work to make Ubuntu mobile phone apps secure and easy to update. They are a great way to publish software, worth creating regardless of all the anti-canonical trolling. And they work fine across distros except where RH has actively tried to cripple them. That's their right, but wow, toxic.

jhasse 10y ago
> RH has actively tried to cripple them Source? Snaps require AppArmor which is used by Ubuntu and openSUSE. This makes it harder to integrate Snaps into Red Had (SELinux) distros, but I wouldn't say that this is something RH does actively to cripple them.
- mhall119 10y ago
  Snaps need a security backend like AppArmor in order to run in confinement. Without it, they can still be run unconfined. And while AppArmor+seccomp is the only working security backend, snapd is designed to support alternate backends, so one could be made for SELinux, we just need someone with SELinux experience to write it (our in-house expertise is in AppArmor)
vetinari 10y ago
Snap is not vendor neutral - it has hard coded dependence on Canonical infrastructure. If you want to provide your own, tough luck. Calling to attention about that is not anti-canonical trolling. It's avoiding creating a dependence on a third-party.
- mhall119 10y ago
  s/tough luck/patches welcome/
  - vetinari 10y ago
    Patches here: https://github.com/flatpak/flatpak https://github.com/flatpak/flatpak ;)

gens 10y ago

It is rare to see something come out of Fedora that is not NIH. As for all the mentioned package/image managers, IMO they all bring more problems then solutions (except maybe nix). Dependency resolution brings sloppiness and keeping the programs dependencies up to date would kill the internets and hard drives (compared to a normal package manager). They should just build a build bot and amen (or just not do anything). The only "problem" they solve is proprietary program distribution, and that is solved by a Filesystem Hierarchy Standard (and fd.o) compliant installer such as MojoSetup (as used by GoG).

pmontra 10y ago
Yeah, my worry is that when a vulnerability hits libc we have to download all the snaps again and the vulnerable libc is still there in the abandoned snaps. There are many other libraries used by many programs that would suffer from the same problem. I'm thinking about openssl. Edit: somebody answered to my doubts in a comment here https://news.ycombinator.com/item?id=13559060 https://news.ycombinator.com/item?id=13559060

the_why_of_y 10y ago

FlatPak is a rename of xdg-app, which is the successor of Glick2, which is the successor of Glick, which was released in 2007, all by the same author.