Snaps. Why? Please Stop
forums.linuxmint.com
forums.linuxmint.com
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) ......
The kicker is sometimes when you use apt to install a package, sometimes it installs a snap! It's madness!
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.
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.
I suspected it had something to do with snapd, so I downloaded the .tar.gz release of Firefox and it worked. I kept investigating and figured it must have something to do with snap.firefox.firefox apparmor profile because the VPN client was symlinking the /etc/resolv.conf to /opt/.../resolv.conf
However, updating the apparmor profile didn't help so I ultimately realized that snap has a hardcoded list of paths that get mounted into the app container [1] and there's no way to change this.
There are a number of reasons to hate on snapd, but this almost made me flip the table.
Also, as a bonus point, if you look at the apparmor profile I mentioned it has a ton of comments about chrome, so someone must've just copy pasted it and modified to work with Firefox. GrEaT SeCuRiTy!
[1]: https://github.com/snapcore/snapd/blob/3a88dc38ca122eba97192...
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.
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.
Is your chosen distro Ubuntu?
I am a Debian user since 1999.
Also app auto updates, browser extensions, ...
(Not to mention that, in the case of pnpm at least, everything's installed into a store directory in your HOME. Seems fine to me.)
I dislike snaps as much as the next person but I wonder if we do need another discussion about it.
And later responses by the OP of that thread further convince me that this was not a question asked in earnest.
That’s just one of the things that is messed up and annoys me.
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.
Other than Apples, which are those "a lot of laptops" that come with soldered storage?
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.
Surface Go is available in eMMC version.
https://www.youtube.com/watch?v=dpkT8JwgnAI
https://www.amazon.com/s?k=laptop+emmc
Basically anything under $700 has a chance to be an eMMC laptop.
Most? Nope.
Many? Yes, especially cheap and not so cheap ones.
Yes I'm sure all the three Surface Go owners in the world will be devastated.
>Basically anything under $700 has a chance to be an eMMC laptop.
You must be joking. Maybe like sub 300 USD. I have a 700 Euro Laptop and it came with a 1TB NVME and most cheap sub 500 Euros laptops I find are all still with SSDs not eMMC.
SSDs are now so cheap you'll find them everywhere instead of eMMCs. You really need to go out of your way and scrape the bottom of the barrel to find them today in new products.
Thankfully for Microsoft you and your hate are not the ones who buys Surface Go
> You must be joking. Maybe like sub 300 USD
Did you even bothered to check that Amazon link? With laptops at $500 clearly labeled having an eMMC storage? You must be joking.
> SSDs are now so cheap
And eMMC is cheaper. If it wasn't there would be no laptops with eMMC.
How much percentage wise are they of total sales of laptops?
How many consumers actually buy them?
Those are important numbers, the statistics. Not your Amazon findings trying to spin it into an overexageration.
Emmc laptops are by no means a majority in consumers hands.
> to hunt down some junky Emmc laptops
> by actively searching for them on Amazon doesn't mean anything.
No, I didn't 'hunt down', 'actively searched' or whatever. I just typed it in. Also it means what you are didn't bothered to visit that link and you are in denial, because it doesn't suit your views.
> How many consumers actually buy them?
Ah, yes, let me call MS/ASUS/whoever president and tell him to handover the stats, because noname from the Internet demands them or 'didn't happen'
>trying to spin it into an overexageration
Ah, yes, multiple models with eMMC sold everywhere is just an overexageration, it's like a special plot from vendors to... what for, actually?
How come there are models on the market with eMMC when nobody buys eMMC laptops? Can you explain that without overexagerating your snobism?
> Emmc laptops are by no means a majority in consumers hands.
Yes, and this is addressed in my first comment in this thread.
The tech is already there, no need for soldered on stuff.
Soldering is kind of a "Worst possible solution except all the other ones" kind of technology.
And you can't stop me.
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?
I see it as a necessary evil since a proper permissions system will make the attack surface for desktop apps much smaller in the long run, and the flatpak portals have the advantage of being much more visible and controllable by ordinary users than AppArmor or selinux (if there were even profiles) before them.
That being said I don’t see FlatSeal as a solution to the permission issues but merely a bandaid until a proper first citizen solution is developed by flatpak.
Discord also works, it doesn't support some features, but that has nothing to do with flatpak and everything to do with Discord on Linux in general.
I've got a dozen or so other flatpak apps that work flawlessly.
One major complaint though is it can keep old unused versions of runtimes around and you manually have to remove them, Nvidia and Mesa runtimes for some reason consistently have this issue. Even running `flatpak uninstall --unused` does not remove them.
Traditional package management is a terrible fit for modern systems and apps.
If you have dozens of apps and they each have dozens of dynamically linked dependencies, you'll probably get an occasional compatibility issue.
At first I really liked Flatpak, but the ecosystem isn't there. Everything I use is in Snapcraft, with Flatpak I still would occasionally have to hand install something or add a custom deb repo.
My only real complaint is the proprietary backend. It doesn't directly affect me much, since it's not like I'd want to use an alternate store when the official one has everything, but it does get in the way of adoption without seeming to benefit canonical that much.
Companies are way too afraid of FOSS competitors, they forget how much users like convenience and standardization and sticking with stock settings.
Deb packages are rock solid for the most part if you use standard distro packages, but the moment you want something newer or third party, there's no guarantee it will work well with some other random third party thing you also have.
Especially when sometimes apps might even depend on bugs and break when they get fixed.
Snaps mostly solve the reduced integration issues(Or at least try to, some stuff isn't perfect yet?) with all their plugs and interfaces and whatnot.
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.
Which makes it additionally frustrating that Canonical is insisting on forcing it on all the desktop users.
No one is installing server software through the Software Center. So why does that have to prioritize Snaps?
Canonical could very well have promoted snap as an option to package server software and used flatpaks or even debs for desktop software. There is no reason the 2 couldn’t exist as primary options at the same time for different use cases.
I finally caved and gave up on LXC. Removed it and snapd. Load immediately dropped to 0.5 again.
I. Hate. Snapd.
Went back to Debian stable and zero issues.
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.
I also remove some of the crap that Ubuntu put in /etc/update-motd.d. From memory 10-help-text, 50-motd-news, 88-esm-announce, 91-contract-ua-esm-status are pointless and annoying.
Ditch Ubuntu.
Although cups has a hardwired dependency on libsnapd-glib1 so you can't remove that library, but the nosnap.pref file will prevent snapd from ever being installed again.
Or if you use Arch, just install it using pacman or the AUR.
If the money spent on the salaries of the CADT developers making this were spent on the Debian package maintenance, many problems would vanish.
My system logs bloated into the gigabytes with constant errors about some snap or other having faulty security settings. Absolutely no user-facing indication of any type that there's an error, just endless log messages.
I use Arch now. It's still just as miserable, but at least my problems are my own fault this time.
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.
Life is good. We are free.
You're possibly using it wrong.
Seems like I am not alone. If the problem does not affect you much, does not mean it does not exist.
Yeah, the usual "works for me" attitude has had never helped anyone. So, good for you.
Haven't had any major dependency related issue in years.
He knows the answer, he just doesn't like it for stupid ideological reasons.
That’s why.
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.
This is a reductive argument.
It's not more effort if Snap is already included in the Linux distribution.
This argument only applies if Snap is your only distribution channel.
Otherwise, you could say that distributing a Linux version of the software implies more effort from the user, because they'd need to install Linux first. We're talking alternatives here.
So flatpak?
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.
But just to strongman package managers:
With an AppImage you don't get security updates, and it isn't a distribution mechanism.
Not everything is network connected and security critical. Auto-updates are a huge pain for a lot of workflows.
Imagine Microsoft having to package the millions of distinct Windows applications.
Personally I ship static executables, but that doesn't work for GUI apps.
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.
https://build.opensuse.org/ https://en.opensuse.org/openSUSE:Build_Service_supported_bui... https://github.com/openSUSE/open-build-service
> 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?