According to Canonical’s Oliver Grawert, the next long-term support release of Ubuntu will be available to download in 2 versions: a classic, deb-based version (default) and, for the first time, an immutable, snap-based build.
This makes sense, and was inevitable. I wonder how long they’re going to keep the .deb-based version around; I doubt they’d pull it any time soon. Still, competition is good, and it’s been clear for a while now that immutability is the next big thing in the desktop Linux world.
No thanks. Ill pass
Indeed, many of the snap packages are out of date and required me to uninstall and prune them before installing the apt-get version.
https://www.reddit.com/r/docker/comments/shztqs/wow_docker_works_a_lot_better_when_you_dont_have/
Does it come with free additional 16GB of RAM for each device even the ones that do not support RAM upgrades?
No.
Meanwhile, Android has already solved the dependencies problem by making packages be standalone .apk files and extracting each app’s apk to its own directory. But that’s too simple for the Desktop Linux people.
So did macOS, the Atari ST, etc. I’d mention the Amiga, but that does have a lot of library searching issues…
Dependencies isn’t even the problem with Linux though, Desktop Linux solves that by having stuff in the package management system. If you install things outside of that, it’s also solved via flatpaks, appimages, etc. Pretty simple, really.
It is really one of the main problems with Linux though. Lately I’ve found more examples of Linux installs actively trying to destroy themselves due to dependency issues, and of course the community egging the user into uninstalling every package on their system, surely intending to say “well you should have known better” after the user destroys their install. Sorry, package managers still break and introduce more issues than they solve, just like old times. These flatpak/Snap/docker things try to mitigate the issues by static linking everything, but then they tend to break down in general and none of their apps will start without repairing the container software itself. It’s lead me to firm conclusion: Desktop Linux doesn’t have the resources to program in resiliency. A Windows update can detect it’s own failure to install, Linux just lets the user find out by surprise, and then they have to fix it themselves. The Linux kernel is stable, the Linux desktop doesn’t look like it will ever be, and no one is really measuring that part.
dark2,
Give an example from a stable (non-testing) repo.
Of course I have experienced dependency issues, but in 100% of those cases I was side stepping the official repos or mixing repos in order to install an unsupported version, which IMHO is the bigger problem with official repos. But for users who stay within the repos what you are saying is not something normal users need to worry about.
Well, as kurkosdr mentioned, this is what APKs do, they include everything the program needs besides android’s own API’s. There are pros and cons to every approach and it’s fine to talk about these but the criticism is often completely hypocritical and ignores the fact that every other operating system has the same conundrum of sharing the resources or statically bundling them. The hypocrisy stinks. It seems like the motivation has more to do with flaming the platform than an objective debate.
Unfortunately for linux, it is regularly judged using higher standard than other mainstream operating systems. People will install it themselves on unsupported hardware combinations that have never been tested and expect it to work robustly out of the box. That’s an extremely high standard that no commercial operating system achieves. If you want a robust experience, you can have it, but go with an enterprise class distro, and use officially supported hardware.
Stamp and distribute. I have watched the same biased claims repeated ad nauseam.
Have been a long time openSUSE and Red Hat user. Really, if it was not for Autocad, would not touch any other OS for my own use.
Anyway, I find it to be a pain to support Windows machines, but have to admit that it is very rare to see problems on them, despite the best effort of illiterates users.
kurkosdr,
Are you only considering the RPM and DEB repositories in making that statement?
Why not consider the various desktop linux solutions that use self contained packages and can do sandboxing?
https://phoenixnap.com/kb/flatpak-vs-snap-vs-appimage
Also, while it sounds like you are just trying to snub linux, I really don’t think windows users have much room to criticize others on the grounds you are using without being quite hypocritical.
Edit: leech beat me by a minute!
Correct me if I am wrong but is that not the point of FLATPACK?
https://www.flatpak.org/
Yes, because every Android user I know intentionally searches the Web for standalone .apk files and manually extracts each app’s .apk package and manually install it to the correct directory with the software provided to them. They sure as hell don’t bother with that “official” thing for the operating system that Google provides called the Play Store. You absolutely couldn’t be more spot-on.
I think the problem with the Desktop Linux people is that they are a tiny minority compared to the server/infrastructure people for the same distro. So they will be mired to the “traditional” unixy way for a while.
Exciting. This would be completely Snap-based right down to the kernel, unlike other immutable distros (e.g. Fedora Kinoite, openSUSE Kalpa) that still use RPMs for the low-level stuff because Flatpak can’t do that.
The “problem” i see is can Canonical pull it off. That is to provide what Debian does but everything packed as a snap. If they can then this might became a viable option for general public. As i can imagine a lot of currently unavailable software getting packed as a snap and being provided to Ubuntu and other GNU/Linux distributions. But first things first. Packaging the whole Debian in snap. For something like that to happen Debian would likely need to adopt such packaging format in the future. Then it could happen. At some point i could imagine Debian to make such choice.
oh god no. lets hope not.
NaGERST,
I agree on the basis that snaps are a proprietary centralized walled garden that are hard coded around canonical.
While they likely copied the model from IOS & android, I do think many linux users are a bit offended by snap’s centralized distribution model, which is self-serving. Ftatpak and appimage have the advantage here.
https://askubuntu.com/questions/1383583/is-it-true-that-snap-has-proprietary-server
https://bugs.launchpad.net/snappy/+bug/1593151
Personally i don’t like on how Ubuntu moved away from the community and got closer with companies such as Microsoft. On the other hand end users didn’t do their part either. When Ubuntu momentum was peaking and you could actually buy hardware with Ubuntu in your local PC store. Most people rather continued to use Windows. Ubuntu and Firefox was a reasonable choice and people still rather opted for Windows and Chrome. This same people didn’t have any issues with using Android or iPhone. No GNU/Linux mobile device ever made a dent. On top of that majority of free and open source software moved to GitHub. GitHub now being a proprietary system owned by Microsoft. So i beg to differ on this one. For me it’s acceptable if we get an option where a developer can package the todo app only once. And for it to after work on majority of GNU/Linux systems. Personally i don’t particularly like Snap/Flatpak/AppImage in their current technical form. Mostly because i know their limitations and use cases where they fail. But they are the closest thing to the idea of packing a todo app once and after to distribute it across GNU/Linux ecosystem. Desktop and mobile and including updates. So i will support such effort and will fight their shortcomings. Instead of fighting the solution altogether and claim GNU/Linux shouldn’t have an universal package format. It should have it as it’s not acceptable anymore to have a need to package software for each (version) of GNU/Linux distribution out there. And even here distributions don’t want to support one packaging format. Like deb/rpm. Where you would still need to make a gazillion builds of the same package. To support all GNU/Linux distributions out there. But that would still be much more streamlined. Compared to now where not even the package format is universal. Ubuntu/Debian/Fedora/Arch … they could all support a packaging format like deb. But they chose not to. As obviously their packaging format is so so much better. Not.
Fedora Silverblue/Kinoite/Sericea pulls this off because Flatpak is actually good – convenient, well integrated into the desktop, and stuff in the main repo is up to date.
Snap, not so much. And I’m not forgetting the time they let malware into the main (and only LOL) repo. Immutable Ubuntu will go nowhere fast IMO.
When I first installed Ubuntu 22.04, I wanted to test their current snap implementation, as it was slow as a snail to me in its previous incarnations. So, I started my standard test, Calculator. It took around 20 seconds for it to open up. 20 seconds to start a f***ing calculator… Subsequent starts are faster, but after some time passes, it gets back to ~20 seconds.
For comparison, on the same machine GIMP 2.10 with gazillion plugins and whatnot starts in about 3-5 seconds (but, contrary to Calculator, it is a DEB install, not Snap).
So I searched for “how to remove snap on ubuntu 22.04” and got rid of it. Now, it seems that it is time to say “so long and thanks for all the fish” to Ubuntu (I was using it since version 6 or 8, I do not remember) and to move to Mint…
I do understand the value of isolated applications, but to me it isn’t worth the wait every time I need to run something packed as Snap. All applications packaged like that – sorry, but no way.
So I’ll be looking for a new distro. I still don’t see what snap adds other than a worse user experience.