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

Snaps are an anti-pattern on Ubuntu

techtudor.blogspot.com

Post reply on HN
Print view View original

191–198 of 198 posts

Re: Snaps are an anti-pattern on Ubuntu

#191

Post by afiori »

zrm wrote: post #170
afiori wrote: post #163

Earlier quoted context omitted.

> I want the proprietary app in a container. People want containers to be magic but they're actually a hard problem. You want the app not to be able to do anything you don't want it to but still be able to do everything you do want it to. As I see it the problem that containerization in snaps and similar solution is the isolation of system configuration. I agree that permissions are an hard problem and honestly I am…

> As I see it the problem that containerization in snaps and similar solution is the isolation of system configuration. If you drop your app's config file in /etc/ and nothing ever touches it, isolation isn't really buying you anything. If something does, that could still be what you want to happen. For example, suppose there is a P2P app that can operate either by having you forward a port from your router (which is…

I would say that more than having your own config be left alone, the complex case is when two different applications want to mess up a third party configuration.

Software repos as a whole in part exist to solve and harmonize these cases.

Re: Snaps are an anti-pattern on Ubuntu

#192

Post by WesternStar »

antpls wrote: post #188
WesternStar wrote: post #8

I honestly like snaps. I like having spotify and discord working as to his other concerns I just don't care.

Same here : I use it for Firefox and Chromium, and it just works. Another comment mentioned VLC, which should be a good candidate for frequent release too. I can understand the "proprietary store" concerns of this thread, however.

They should maybe consider adding an option for people to point at other repositories and surface them either in the ubuntu software store or in their own software store.

Re: Snaps are an anti-pattern on Ubuntu

#193

Post by schmichael »

im3w1l wrote: post #173
schmichael wrote: post #114

Earlier quoted context omitted.

> I don't understand why anybody wants this. Because creating debs is largely a completely distinct undertaking from the dependency and build management the developer of an app does. Bundles, whether via images or static binaries, allow app developers to distribute their app against the exact dependencies it was developed against -- potentially using the same build system. There's obviously tradeoffs to each approach…

Mobile apps are a hellscape. It's an example of how wrong things can go. Apps treat their privilege model as a license to abuse all their privileges as much as possible. Ability to read Contact list? Location access? Great let's upload it all to the Googbook analytics for data mining our customers.

But what's the alternative? No MAC and every app has all user privileges by default like most Linux distros?

I would argue the concept has not failed, just the implementations have fallen short. And for good reason! It's an extremely complex confluence of cutting edge technology, UX, security, privacy, etc. It's been improving, and surely the open source community can do it even better (or at least with a greater focus on privacy).

Re: Snaps are an anti-pattern on Ubuntu

#194

Post by Wowfunhappy »

enriquto wrote: post #189
Wowfunhappy wrote: post #101

Earlier quoted context omitted.

Yes, sign me up please! You don't necessarily need to go all the way down to statically linking libc, but if just about everything else could be included in the binary, that would be lovely. We have come up with such convoluted solutions to this problem—Docker, nix, Snap, etc—when the simple option is sitting in front of us. And it works! On my Mac, I don't want to install homebrew or MacPorts—Package managers make m…

You can link libc statically, it's probably smaller than the other stuff you use. If you are really worried about size you can use the musl which is quite smaller. The only problem I have found with static linking is for programs that use opengl, that need to be linked to a specific version of the graphics drivers. If you try to statically link a program that depends on libGL, it may work for you with an nvidia chips…

I'm not against linking libc statically, but the reason I brought that up is to preempt a counterargument I always see: what happens if a security vulnerability is found in libc, and just about every single program needs to be recompiled?

My response is either (A) so what, go ahead, it's worth the complexity tradeoff for static binaries, but also (B) you can link a tiny handful of core system libraries dynamically, and still reap most of the simplicity benefits of static linking.

The latter approach solves the OpenGL problem too. If there are real cases where users would need to swap that out, go ahead and link it dynamically. The goal needn't to remove all dependencies, but to avoid the quagmire of hundreds (or more) of nested dependencies.

Re: Snaps are an anti-pattern on Ubuntu

#195

Post by aj3 »

dheera wrote: post #23
SweetestRug wrote: post #5

I had been an Ubuntu user for almost 16 years, on servers, laptops, and recently containers. The snap situation with Ubuntu is just plain unpalatable, both in principal and in practice. I became so disappointed in the move by Canonical that I finally left Ubuntu altogether and no longer recommend it to friends and colleagues. It takes years to cultivate a garden, but only minutes to destroy it.

There are also these "AppImage" files. They launch, but there is no guidance on how to install them to the system. Launching Chrome: I click the Chrome icon. Launching PrusaSlicer: Start a terminal and type chmod 755 ~/Downloads/PrusaSlicer-2.2.0+linux-x64-202003211856.AppImage ~/Downloads/PrusaSlicer-2.2.0+linux-x64-202003211856.AppImage That doesn't seem like progress to me from a UX perspective.

  $ sudo install ~/Downloads/PrusaSlicer[tab] /usr/local/bin/PrusaSlicer
  $ PrusaSlicer

Re: Snaps are an anti-pattern on Ubuntu

#196

Post by ric2b »

zrm wrote: post #171
ric2b wrote: post #153

Earlier quoted context omitted.

> Libraries should have major versions and the latest of each major version should be compatible with anything using that major version Should, but accidental breaking changes are a thing. Plus flatpack more or less solves this by having standard runtimes (base collections of libraries/dependencies that flatpack apps target) that get security updates. > That requires the person configuring the app's container to have…

> Should, but accidental breaking changes are a thing. They're a thing either way. If a library has a security update that breaks your app, your choices are to have a security vulnerability or to have a broken app, until somebody fixes whatever is broken in either the library or the app. The only good option is to fix the breakage quickly -- or do better testing to begin with. > Plus flatpack more or less solves this…

This permissions model and approval process already works in mobile app stores. Yeah, if the developer doesn't understand the permissions model they ship a broken app, so what? Are we supposed to expose our computers so that incompetent developers don't break their own apps accidentally?

Re: Snaps are an anti-pattern on Ubuntu

#197

Post by zrm »

ric2b wrote: post #196
zrm wrote: post #171

Earlier quoted context omitted.

> Should, but accidental breaking changes are a thing. They're a thing either way. If a library has a security update that breaks your app, your choices are to have a security vulnerability or to have a broken app, until somebody fixes whatever is broken in either the library or the app. The only good option is to fix the breakage quickly -- or do better testing to begin with. > Plus flatpack more or less solves this…

This permissions model and approval process already works in mobile app stores. Yeah, if the developer doesn't understand the permissions model they ship a broken app, so what? Are we supposed to expose our computers so that incompetent developers don't break their own apps accidentally?

> This permissions model and approval process already works in mobile app stores.

The permissions are too coarse-grained. Flashlight apps ask for ridiculous permissions and get them. Some permissions are "too dangerous" so you can't have them even if the user trusts you completely and you have a good reason, which makes certain apps impossible. It's rubbish.

> Yeah, if the developer doesn't understand the permissions model they ship a broken app, so what?

So then they err on the side of requesting too many permissions, which is made even worse when they're coarse-grained.

> Are we supposed to expose our computers so that incompetent developers don't break their own apps accidentally?

What Linux does, to start, is to not package things from incompetent developers. If your app is nothing but a fork of Thunderbird that uploads all the user's contacts to your server, Debian isn't going to package that because there's no demand for it. But you could get the equivalent thing into the app stores, because things get there when developers push them there, not when packagers pull them there.

Then the Linux apps have the source code for anybody to view and modify. If the app was originally written to do something problematic, you can modify the app not to do that before distributing it.

That makes the permissions model much less important, because the problem of malicious apps is much reduced and all you need it for is containing bugs.

Your app isn't supposed to access the network, so you assert as such. Then if it has a bug or somehow gets compromised, the system can at least prevent it from accessing the network.

But you don't have such an aggressive tension between false positives and false negatives because more of the false positives got eliminated through having access to the source code and not packaging garbage apps to begin with. If a Debian packager doesn't restrict the app from accessing the network even though it didn't really need to, probably doesn't matter anyway. If an app store does the same thing, that was the only thing preventing the app from sucking up all your contacts and sending them to a third party server.

Re: Snaps are an anti-pattern on Ubuntu

#198

Post by nikau »

schmichael wrote: post #193
im3w1l wrote: post #173

Earlier quoted context omitted.

Mobile apps are a hellscape. It's an example of how wrong things can go. Apps treat their privilege model as a license to abuse all their privileges as much as possible. Ability to read Contact list? Location access? Great let's upload it all to the Googbook analytics for data mining our customers.

But what's the alternative? No MAC and every app has all user privileges by default like most Linux distros? I would argue the concept has not failed, just the implementations have fallen short. And for good reason! It's an extremely complex confluence of cutting edge technology, UX, security, privacy, etc. It's been improving, and surely the open source community can do it even better (or at least with a greater foc…

It would be nice to have a prompt when the phone asks for phone book access:

Allow Deny Fake

The Fake would just have generated names and numbers to pollute their data mining.

Post reply on HN