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.
Snaps. Why? Please Stop
51–60 of 115 posts
Re: Snaps. Why? Please Stop
#52Package 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.
Godot can save GUI app to static executeable, mobile and web.
Re: Snaps. Why? Please Stop
#53The 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 prefe…
Re: Snaps. Why? Please Stop
#54This 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 writeab…
Re: Snaps. Why? Please Stop
#55Why? Because of Dependency Hell. Apt sometimes even tries to solve "circular dependencies". Ridiculous.
Re: Snaps. Why? Please Stop
#56It 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.
Re: Snaps. Why? Please Stop
#57Earlier quoted context omitted.
>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?
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.
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.
Re: Snaps. Why? Please Stop
#58My 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.…
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.
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.
Re: Snaps. Why? Please Stop
#59If the money spent on the salaries of the CADT developers making this were spent on the Debian package maintenance, many problems would vanish.