[HN Gopher] Snaps. Why? Please Stop
___________________________________________________________________
Snaps. Why? Please Stop
Author : throw555chip
Score : 76 points
Date : 2023-11-23 18:23 UTC (4 hours ago)
(HTM) web link (forums.linuxmint.com)
(TXT) w3m dump (forums.linuxmint.com)
| beretguy wrote:
| My concern is that a lot of laptops come with soldered in, non
| replaceable hard drives and all these sandboxed programs take up
| a lot of space. So if you buy cheap laptop with 256GB storage and
| start installing snap/flatpak/appimage eventually you'll run out
| of disk storage and won't be able to upgrade it (storage, that
| is). And the only solution is to buy upgradable laptop or a
| laptop with a lot of storage upfront.
|
| That's just one of the things that is messed up and annoys me.
| danieldk wrote:
| It's fine. I don't know about Snap, but Flatpack uses shared
| runtimes. Sure, there is also vendoring, but sharing takes a
| lot of dependencies out already.
|
| This model has been used on phones and Macs for ages, and for
| most people it's not an issue. Photos, videos, and game assets
| are taking up all the space.
| michaelt wrote:
| Snap retains multiple versions of each package, following a
| setting called "refresh.retain" which defaults to 3.
|
| Install Blender? That's 3x 323MB. Chromium? 3x 158MB Firefox?
| 3x 242MB
|
| And don't think you're going to get away with just 3 copies
| of a snap like 'core' or 'gnome' - you're getting three
| copies of core18 and three copies of core20 and three copies
| of core22 and three copies of gnome-3-28-1804 and three
| copies of gnome-3-38-2004 and three copies of gnome-42-2204.
| At 497MB each.
|
| You might think you could avoid that by reducing the setting
| to 1, but you're not thinking like the creators of snap -
| they've decided the minimum value of refresh.retain is 2.
| FirmwareBurner wrote:
| _> is that a lot of laptops come with soldered in, non
| replaceable hard drives _
|
| Other than Apples, which are those "a lot of laptops" that come
| with soldered storage?
| mike_d wrote:
| New Dells are using fixed storage:
| https://www.youtube.com/watch?v=BPBk9sIK-PQ
|
| Most (all?) Chromebooks use eMMC storage attached to the
| board.
|
| Even laptops with M.2 connectors still require a hundred
| screws, guitar picks, heat guns, and other insane things to
| "replace" storage.
| FirmwareBurner wrote:
| _> New Dells are using fixed storage_
|
| Meh, that's just one model out of dozens form one of a
| dozen manufacturers. Hardly conclusive to validate the "a
| lot of laptops" claim. I'm sure someone else in the
| comments will point out some other obscure laptop from Acer
| or Lenovo that's thinner than a razor blade and has
| soldered storage. Fine, but still not "a lot of laptops".
| Just don't buy those 3 models in the world that solder
| their storage and you'll be fine.
|
| _> Most (all?) Chromebooks use eMMC storage attached to
| the board._
|
| Thanks but Chromebooks are just ChromeOS devices akin to
| your tablet or phone, not actual laptops, nor do I buy
| garbage laptops with eMMC, nor would I know where to find
| one even if I did want to buy a laptop with eMMC since I
| haven't seen one for sale since the Asus EEPC from 2011, so
| no issue there.
|
| _> Even laptops with M.2 connectors still require a
| hundred screws, guitar picks, heat guns, and other insane
| things to "replace" storage._
|
| That's a gross overexaggeration. I fiddled with the innards
| of several models of laptops from several brands and all of
| them are easy to replace the M.2 SSDs without special fancy
| tools and pain, just a screwdriver. Only Microsoft glues
| their machine together but nobody buys them anyway so don't
| you do it either and you'll be fine.
|
| Conclusion: Myth busted. Most laptops on the market DON'T
| have soldered storage, and they're also quite easy to
| replace. Keep calm and carry on.
| sshine wrote:
| You're a company and your software actually runs on Linux. You
| want to reach as many people as possible. So you make a .deb for
| Ubuntu. Or you go with a package manager that is cross-distro.
|
| That's why.
| tryauuum wrote:
| ehhhh.... If I want to reach as many people as possible I would
| build rpm, deb, docker images, provide source code. I would
| _not_ use snaps because it would imply more effort from the end
| user -- they first need to install snapd and only then my app.
| loxias wrote:
| Yup. This is what's true in my experience (working for
| companies that sell software that runs on linux
| distributions).
|
| I don't have any gross snaps or unpackaged stuff on my
| laptop, how could I expect paying customers, with an
| operations department, to accept anything less.
| HunOL wrote:
| > Or you go with a package manager that is cross-distro. >
| That's why.
|
| So flatpak?
| Alupis wrote:
| Well, flatpack still doesn't address the non-gui app/utility
| part of the equation.
| stonogo wrote:
| And snap doesn't address the fact that the server
| components that talk to the snap 'store' software is
| closed-source and only available from Canonical.
| Alupis wrote:
| Never claimed it did. Snaps are yet another half baked
| Canonical tech...
|
| Those of us using immutable distros would love a
| "flatpack for cli utils". OS-tree layering defeats many
| of the points of immutability, and pet containers are a
| bigger pita than they should be. There has to be a better
| way.
| snovv_crash wrote:
| Just make an appimage and be done with it.
| DiabloD3 wrote:
| I won't use Snaps.
|
| Please stop trying to work around my chosen distro's package
| maintainers.
|
| If I want to use your program and there isn't a package for it,
| I'll build it from source myself.
| loloquwowndueo wrote:
| Other than the clickbaity title, the second paragraph begins "
| Traditional package managers are perfect" - which is untrue. Then
| the post ends " Educate me." - such a "change my mind" attitude
| seems rather trollish.
|
| I dislike snaps as much as the next person but I wonder if we do
| need another discussion about it.
| wilkystyle wrote:
| > _Then the post ends " Educate me." - such a "change my mind"
| attitude seems rather trollish._
|
| And later responses by the OP of that thread further convince
| me that this was not a question asked in earnest.
| dschuetz wrote:
| Why? Because of Dependency Hell. Apt sometimes even tries to
| solve "circular dependencies". Ridiculous.
| smallerfish wrote:
| I haven't run into dependency hell in 15 years of using deb on
| Ubuntu.
| jacquesm wrote:
| Lucky you.
| loxias wrote:
| I haven't had problems with dependency hell since the early
| 2000s. And even then, looking back, I'm entirely sure the
| problem was not in myself.
|
| You're possibly using it wrong.
| jandrese wrote:
| Dependency issues usually only appear on Ubuntu when you start
| adding third party repos, especially for software that has a
| version in the main repo. If you stick to the main repo you
| will basically never have them.
| MrDresden wrote:
| Have plenty of PPAs on my system but also make sure to do
| propper pinning.
|
| Haven't had any major dependency related issue in years.
| gumballindie wrote:
| Linux doesnt force either upon you.
|
| Life is good. We are free.
| felixhammerl wrote:
| There are so many half baked takes, but this is my favorite:
|
| > There will always be a market for stable-over-latest software,
| especially for businesses.
|
| That market is called the nvd.nist.gov at best and 0 day brokers
| at worst. Why do people stil not accept the fix forward supremacy
| and patch their mess?
| yjftsjthsd-h wrote:
| Because people aren't fond of things randomly breaking or
| forcing reconfiguration in order to get their security patches.
| tryauuum wrote:
| seriously, I don't understand why would any linux user use them.
| If I need some bleeding edge software I would install it through
| docker
| ssl232 wrote:
| > If I need some bleeding edge software I would install it
| through docker
|
| Or if you use Arch, just install it using pacman or the AUR.
| IshKebab wrote:
| > Sure, Snaps make it easy to install 3rd party software, but I
| just find this problematic, causing fragmentation, and just all
| around a bad idea.
|
| He knows the answer, he just doesn't like it for stupid
| ideological reasons.
| yjftsjthsd-h wrote:
| For reasons, yes, perhaps even ideological reasons, but if
| you're going to call them stupid you should at least try to
| give a reason.
| fragmede wrote:
| (2019)
| kalekold wrote:
| I use Ubuntu and i'm sick of having snaps forced on me. When I
| next install, i'm either completely ridding the system of snap or
| i use another distro. I'm fed up with it.
|
| The kicker is sometimes when you use apt to install a package,
| sometimes it installs a snap! It's madness!
| jstanley wrote:
| I recommend Pop!_OS (despite the stupid name). It is basically
| Ubuntu without the annoying bits.
| mikeywazowski wrote:
| Pop!_OS is good, but going from Ubuntu to Pop!_OS doesn't
| really help with the Snaps issue.
| patch_cable wrote:
| Does it not? Pop!_OS uses Flatpak, I believe.
| tehbeard wrote:
| Unless I purposely removed it and blanked the memory of it,
| Pop just deals in deb's and flatpak.
|
| Not that I'm entirely jazzed with flatpak.. Poor
| construction of the permissions can lead to shitty
| experience that doesn't happen with a deb.
| MrDresden wrote:
| What are the programs that you've had to install through snap?
|
| Or are you talking about the existence of snap on the system in
| general?
|
| Personally I have not a single snap packge installed, and am
| usually able to find sources for the programs I use elswhere
| than in the snap ecosystem.
| TheChaplain wrote:
| I think what really put me off when it comes to Snap was when I
| wanted to use a yubikey with Firefox, but Snap tries it hardest
| to make it difficult to add a pkcs11 device.
| new_user_final wrote:
| I don't hate Snap. I am glad that Snap exists. But docker install
| using Snap sucks.
| kkfx wrote:
| Why? Simple: because commercial sw want them, they need something
| they can made at home without giving ANYTHING to the community,
| ESPECIALLY if the software is crap, as 99% of commercial sw are,
| to avoid being depicted for what they are: vendor of crapware.
|
| Why all such systems state they add security while they do the
| contrary? Because they demand to the upstream handling all deps,
| witch means that a generic student who have write a simple chat
| client need to take care of new releases of SSL who he/she do not
| even know much because that's just a deps of some wrapper he/she
| use. They state "but they are isolated", true, but they need to
| punch holes here and there because your snappyfied firefox need
| to download files, let's say pdfs, your external reader can read
| and so on.
|
| That's just playing the Windows game not knowing it and refusing
| to know what a modern FLOSS system should be, like Guix or Nix.
|
| Unfortunately most FLOSS devs see commercial software and try to
| mimic it without understanding that ideas behind it might be also
| technical but in general they are economical, and to support a
| business model they accept technical crap. Much FLOSS devs fails
| to understand that FLOSS model is superior IF done the FLOSS way,
| inferior if it try to mimic some other models not knowing why.
|
| If only people knew the past, the classic desktop OS with the OS
| as a single application where anything is just a bit of added
| code in the hand also of the end users, no commercial software
| today would be able to compete. But most do not even know the
| past, do not even know that some modern tech was invented in the
| past in better ways than today and do not understand that the
| Conway's law is more generic than it appear, goes beyond Lisp and
| have a generally valid meaning in paradigmatic terms.
| baggy_trough wrote:
| Snaps are one of the two main reasons I'm ditching Ubuntu for
| basic Debian. The other is apt spam berating me to upgrade to
| their pay security service.
| theshrike79 wrote:
| Same here, and the fact that it's way too easy to get in "you
| can't upgrade" -limbo with Ubuntu on servers I haven't touched
| for a while.
|
| Went back to Debian stable and zero issues.
| theshrike79 wrote:
| Same here, and the fact that it's way too easy to get in "you
| can't upgrade" -limbo with Ubuntu on servers I haven't touched
| for a while.
|
| Went back to Debian stable and zero issues. The main reason I
| went to Ubuntu was that stable Debian used to be veritably
| ancient. But nowadays I run most of my software in Docker
| anyway, so it doesn't matter.
| apitman wrote:
| Package managers are not a sustainable solution to application
| distribution. It puts way too much on package maintainers, which
| is a thankless job. Whether or not you like Flatpaks, Snaps, etc,
| it's clear that we need some sort of cross distro (and preferably
| cross platform) application format that's simple for developers
| to target.
|
| Personally I ship static executables, but that doesn't work for
| GUI apps.
| xet7 wrote:
| Godot can save GUI app to static executeable, mobile and web.
| apitman wrote:
| Do you have a link to instructions on how to do this? I don't
| think I've ever seen a GUI app on Linux that wasn't
| dynamically linked to X11 or Wayland.
| mid-kid wrote:
| I think having a standard way to specify exact program
| dependencies (not package names, but e.g. pkgconfig files,
| command binaries, deps for specific languages, etc, so they can
| be translated back to the package name for each distro), as
| well as allow packagers to check for updates, would go a long
| way in easing sustainability. We already have other metadata
| covered by metainfo.xml files.
|
| Packaging software is almost automatic these days. If the
| program uses the standard build system for their language, and
| the language's build system cooperates with the way of linux
| (e.g. C, C++, python, perl, ...), packaging software is as easy
| as telling the package manager what build system to use and
| giving it a download URL.
|
| I figure that if we manage to have some standard like that, you
| could easily have a set of docker containers build your program
| for every major distro and publish it in a repository, without
| much distro-specific fuss. Of course, flatpak is probably
| better if publishing to all distros is your specific goal, but
| it'd make the life of distribution developers significantly
| easier.
|
| My biggest fear with regards to flatpak is that people will use
| it as an excuse to create bespoke and broken build systems that
| only work on a very specific system, patch all their libraries
| or require very specific git versions that cannot easily be
| updated, or etc etc. I've already seen this happen with a few
| flatpak apps I've tried to package.
| mike_d wrote:
| It is basically a solved problem for developers.
|
| https://build.opensuse.org/
| https://en.opensuse.org/openSUSE:Build_Service_supported_bui...
| https://github.com/openSUSE/open-build-service
| popey wrote:
| This is a four year old thread.
| lxe wrote:
| Can confirm, snap / flatpack / appimage has been nothing but slow
| bulky disjoint nightmare.
| apatheticonion wrote:
| Ignoring Snaps - what are Flatpaks like today?
|
| Totally understand the value in a distribution model like
| Flatpaks and am willing to adopt them but I haven't had the
| smoothest experience with them in the past so I tend to avoid
| them right now.
|
| The last time I tried them was longer than 12 months ago - I
| installed Discord and it was missing some features at the time
| due to sandboxing (I don't remember exactly, it was either push-
| to-talk, hot-mic, or showing what game you were playing that
| didn't work).
|
| I also had some other issues with other Flatpaks - I think there
| were theming issues.
|
| How is it today? Can I install VSCode, Chrome, VLC, Steam,
| Discord as flatpaks and have no idea they are Flatpaks?
| xet7 wrote:
| This is discussion at 2019-2021.
|
| There are many distros where snapd is not installed by default,
| including Linux Mint:
|
| https://snapcraft.io/docs/installing-snapd
|
| Nobody is forcing you to use distro that includes snapd by
| default.
|
| Snap has advantages for server software that are using Snap
| strict sandbox:
|
| - Strict sandbox does not allow read access outside of
| /var/snap/APPNAME/common . Only common directory is writeable.
|
| - Snap code at /snap/APPNAME is read-only and can not be modified
|
| - When new version is released, for example with security fixes,
| it is automatically updated worldwide, keeping servers secure.
|
| Linux Mint has MintUpdate, that has options to enable automatic
| update of .deb and FlatPak packages, keeping everything up-to-
| date and secure without any clicking. Windows and Mac does not
| have that, you need hundreds of clicks to update each software
| separately, having many apps still vulnerable.
| belval wrote:
| I have ~8 self-hosted services with docker-compose and one with
| snap (nextcloud). While I get that snap gets some flak for how
| cavalier it can be with _your_ system, ultimately my nextcloud
| is always up to date and I 've had very little effort to put
| into it in over 7-8 years, which is not something I can say
| from my running docker containers. It might not be for
| everyone, but from a security standpoint it's much less fussy
| than basically everything else that I've tried.
| tapoxi wrote:
| Why not just write something (or use a pre-existing tool) to
| update your docker containers? I know on Kubernetes there's
| plenty of tooling around Helm.
| XorNot wrote:
| I redid my docker stuff with podman and quadlet recently
| and it's been great. Quadlet turns the containers into
| behaving like regular systemd services (i.e. you can
| trigger them with timers), and "auto update" is just
| setting Pull=true when the container re-runs (there's a
| heck of a lot of good reasons to also not do this).
| Ferret7446 wrote:
| I believe flatpak provides all of those advantages too
| TriangleEdge wrote:
| I feel like this xkcd perfectly encapsulates Snaps:
| https://xkcd.com/927/
| hurryer wrote:
| Snaps move the packaging burden from the distribution to the
| software maker, which is how it should be. It's the only scalable
| way.
|
| Imagine Microsoft having to package the millions of distinct
| Windows applications.
| PlutoIsAPlanet wrote:
| But they also move the gatekeeper from the distribution to
| Canonical, and only Canonical (sideloading does not count when
| the repo is hard coded and server is closed source).
| idontknowwhynot wrote:
| snaps is starting to give me a headache. I installed chromium in
| my ubuntu and it installed it as a snap (even through apt, it
| just a transitional package that installs the snap.), and for
| some reason it has a dependency with cups (printing software).
| Every time i delete cups it is reinstalled..again and again, i
| couldn't find any solution.
| mike_hock wrote:
| > i couldn't find any solution
|
| Ditch Ubuntu.
| dark-star wrote:
| The thing I hate most about snaps is how they pollute the mount
| namespace with loop mounts. Install a few apps and 2/3rds of your
| `mount` output will be /dev/loopX devices. Especially annoying
| since I often do loop-mounts myself and picking them out from the
| flood of unrelated snaps is a pain.
|
| If they could somehow hide the mounts (in a different mount
| namespace maybe?) that would be cool. I mean still, I would
| prefer more open formats such as flatpack and appimage (since
| with snaps you buy into the Canonical ecosystem with no way to
| provide alternative appstores) ......
| hackeraccount wrote:
| I think that's why I gravitated to Flatpak instead of Snap.
| That and maybe the store experience - flathub.org - was better.
| Tanoc wrote:
| One of the experiences that formed my hatred of Snap was when
| trying to install Notepad++ while trying to find a worthwhile
| editor to migrate to. Running via WINE it was 20.6MB installed,
| and even WINE itself was 1.2GB, but that 1.2GB was shared by
| other programs. On one machine due to package conflicts
| preventing an appropriate Mono install and laziness in sorting my
| multitude of prefixes I couldn't get Notepad++ to run via WINE
| and had to install it via Snap. The Snap install of Notepad++
| took up 1.3GB all by itself. On a 32GB drive.
|
| It hasn't gotten any better in the five years since for total
| Snap install sizes, because with the way they work they often
| install every single dependency siloed. Imagine if you had to
| install a new instance of DirectX12 for every game you had, or
| install a new instance of Python 3.12 every time you wanted to
| set up Tensorflow. Firefox when installed via apt is currently
| 63MB and its total size after being run and configured with
| things like session data and add-ons is 243MB. If I install via
| Snap its somewhere around 190MB in size and when actually run and
| configured jumps up to around 550MB for reasons I don't
| understand. And that's not even including the /var/ spam which
| actually managed to fill both the 32GB drive and a later
| replacement 80GB drive to the point where Linux had 0KB of free
| space. It happened so often I copied a shell script just to clean
| /var/ and edited it to run every twelve hours, like cleaning
| calcium buildup out of a fountain pump before it clogs.
| Thoreandan wrote:
| Hear hear. It's really inexcusable -- if there's a bug in a
| shared library, that library should be fixed across the board.
| That, and the implementation is cartoonishly bad, for example you
| can't extend a partition while the system is running the way that
| you could before, because you've got random read-only file
| systems mounted over root.
|
| If the money spent on the salaries of the CADT developers making
| this were spent on the Debian package maintenance, many problems
| would vanish.
___________________________________________________________________
(page generated 2023-11-23 23:02 UTC)