I think most snap haters mostly hate, that Canonical forces snap upon them, an wouldn’t hate so much about it if they had the choice.
Yeah, who’d hate using a package manager that increasingly slows down your boot time with every package installed, or that uses a closed source store to provide you FOSS
Maybe there’s a reason canonical has to force it on their users
I also hate that it creates a loopback device for every installed snap
There’s a lot I dislike about snap. This is the thing I hate.
Yeah typing “apt install firefox” and getting the Snap version does loudly and obnoxiously disqualify Ubuntu from any devices owned by me or my family.
Thanks to snap I switched to arch. It gave a linux beginner so much drive to learn the terminal and install a harder os lol. The firefox snap was the worst shit.
Isn’t that kinda the same with, for example, Fedora and Flatpaks? Or Debian and debs? Or Ubuntu and debs? Or Fedora and rpms?
The packaging system that your distro provides gets you the packages you get. For a small number of packages that were a maintenance nightmare, Ubuntu provides a transitional debs to move people over to the snaps (e.g. Firefox, Thunderbird), but if you want to get it from another repo, you can do exactly what KDE Neon does by setting your preferences.
No, Debian doesn’t take your
apt install ...command and install a snap behind your back…I don’t understand how a transitional package that installs the snap (which is documented in the package description) is any different from a transitional package that replaces, say,
ffmpegwithlibav.$ apt show firefox Package: firefox Version: 1:1snap1-0ubuntu5 Priority: optional Section: web Origin: Ubuntu Maintainer: Ubuntu Mozilla Team <[email protected]> Bugs: https://bugs.launchpad.net/ubuntu/+filebug Installed-Size: 124 kB Provides: gnome-www-browser, iceweasel, www-browser, x-www-browser Pre-Depends: debconf, snapd (>= 2.54) Depends: debconf (>= 0.5) | debconf-2.0 Breaks: firefox-dbg (<< 1:1snap1), firefox-dev (<< 1:1snap1), firefox-geckodriver (<< 1:1snap1), firefox-mozsymbols (<< 1:1snap1) Replaces: firefox-dbg (<< 1:1snap1), firefox-dev (<< 1:1snap1), firefox-geckodriver (<< 1:1snap1), firefox-mozsymbols (<< 1:1snap1) Task: ubuntu-desktop-minimal, ubuntu-desktop, kubuntu-desktop, kubuntu-full, xubuntu-desktop, lubuntu-desktop, ubuntustudio-desktop, ubuntukylin-desktop, ubuntukylin-desktop, ubuntukylin-desktop-minimal, ubuntu-mate-core, ubuntu-mate-desktop, ubuntu-budgie-desktop-minimal, ubuntu-budgie-desktop, ubuntu-budgie-desktop-raspi, ubuntu-unity-live, edubuntu-desktop-gnome-minimal, edubuntu-desktop-gnome, edubuntu-desktop-gnome-raspi, ubuntucinnamon-desktop-minimal, ubuntucinnamon-desktop Download-Size: 77.3 kB APT-Manual-Installed: no APT-Sources: http://us.archive.ubuntu.com/ubuntu noble/main amd64 Packages Description: Transitional package - firefox -> firefox snap This is a transitional dummy package. It can safely be removed. . firefox is now replaced by the firefox snap.Well, that’s your problem for not understanding the massive difference, not mine.
If you don’t want to explain, you’re perfectly welcome to not explain. But saying what amounts to “if you don’t know I’m not telling you”, especially when you weren’t specifically asked, is a pretty unkind addition to the conversation.
One selects a different package, same source repo.
The other completely changes the installation, invisibly to the user, potentially introducing vulnerabilities.
Such as what they did with Docker, which I found less than hilarious when I had to clean up after someone entirely because of this idiocy.
The differences seem quite clear.
deleted by creator
In both cases, the packages are owned by the same people? (Fun fact: mozilla actually owns both the Firefox snap and the firefox package in the Ubuntu repos.) I’m non sure how that “potentially introduces vulnerabilities” any more than “having a package which has dependencies” does.
I’m not sure what you’re referring to with Docker. Canonical provides both the
docker.iopackage in apt and thedockersnap. Personally I use the snap on my machine because I need to be able to easily switch versions for my development work.
you are the reason people hate Linux users, so high and mighty.
the thing people dislike about that is that you’re silently moved from an open system to a closed-source one.
Debian’s .deb hosting is completely open and you can host your own repository from which anyone can pull packages just by adding it to the apt config. fedora, suse, arch, same thing.
only Canonical can host snaps, and they’re not telling people how the hosting works. KDE seems to upload their packages to the snap store for Neon, judging from their page.
also, crucially, canonical are not the ones doing the maintenance for those apt packages. the debian team does that.
the thing people dislike about that is that you’re silently moved from an open system to a closed-source one.
Yeah. I didn’t realize I had fallen for it until I tried to automate a system rebuild, and discovered that a bunch of the
snapback end seems to be closed and proprietary.And a lot of it for no reason. Reasonable
aptandflatpakalternates existed, but Canonical steered me to their closed repackaged versions.While Canonical’s particular snap store implementation is closed source, all of the client software as well as the store API are open, and snap isn’t even tied to using snaps from their store. One could easily make a client app that treats
snapdmuch the wayapttreatsdpkg. (In fact givenapt-rpmI think it would probably be feasible to quite literally use apt for that.)KDE seems to upload their packages to the snap store for Neon, judging from their page.
KDE also maintains most of the flathub.org packages for KDE apps. Not sure what the point is here.
canonical are not the ones doing the maintenance for those apt packages. the debian team does that.
This is wrong in two ways. First, Canonical are the primary employers of a lot of Debian developers, including to do Debian maintenance or development. This includes at least one of the primary developers of apt. Canonical also upstreams a lot of their work to Debian. Second, of the three (!) whole packages that Canonical decided to make transitional packages to the snap, none were coming from upstream Debian. Firefox was being packaged by Mozilla (and Mozilla were the ones who decided to move it to the snap), Thunderbird’s package had been something Canonical was packaging themselves due to the Debian/Mozilla trademark dispute that they never moved back to syncing from Debian due to technical issues with the port, and Chromium was, at least at the time, remaining frozen at old versions in a way that was unacceptable to Ubuntu users.
Good info. thanks.
One could easily make a client app
sure, and convince people to switch. it’s been done before of course but it’s a big effort. And anyway, the main point with the closed-server issue is that it’s impossible to know what the server does other than serving packages. this is true for other package repositories to a certain extent since there’s no real guarantee that they run the source code they show, but there’s a distributed trust network there. as for the snap store, they could be doing anything in there.
KDE also maintains most of the flathub.org packages for KDE apps.
what i was trying to get at is that they’re not hosting their own thing. they do host their own flatpak repo but it seems to be only for nightlies so that point wasn’t as strong as i originally thought.
Canonical are the primary employers of a lot of Debian developers, including to do Debian maintenance or development. This includes at least one of the primary developers of apt.
that does not mean that the particular developer agrees with or even approves of the snap thing. it’s good to know though. i know they upstream, but that’s sort of the bare minimum expected of them.
i’ve not really used ubuntu desktop lately, but i’ve been hearing more complaints from friends about it deciding to install snaps instead of debs lately. steam was a big one that a friend had trouble with, and they just installed that though apt i’m pretty sure.
sure, and convince people to switch. it’s been done before of course but it’s a big effort
I agree! But this, IMO, is a better argument for how flathub.org being (theoretically) open source doesn’t actually make it any better than snapcraft.io. The technical hurdle, either of writing another snap store or of setting up a flatpak host, pales in comparison to the social hurdle of getting people to switch. Which is likely why the previous open snap store implementation died. Nobody wanted to host their own and convince people to switch, because at the end of the day there wasn’t any benefit.
that does not mean that the particular developer agrees with or even approves of the snap thing.
Never said it did, although in the particular case of the developer I mentioned, he’s also an Ubuntu Core developer, which depends entirely on snaps. I can’t imagine he’d have put himself in that position if he were particularly anti-snap
steam was a big one that a friend had trouble with, and they just installed that though apt i’m pretty sure.
Ubuntu has never had a
steampackage in their apt repos, and thesteam-installerpackage still behaves the same way as ever. Personally, I do use the Steam snap and haven’t had any issues with it, though I do know that others have.
Fedora with Flatpaks is open and up front about whether you’re getting a Flatpak or a system installed package, and lets you choose if both are available. And installing through dnf/yum isn’t going to do anything at all with Flatpak.
And what about Debian with debs? That’s literally what apt was designed to work with. If it gave you Flatpaks, or the flatpak command installed debs, that would be more like what Ubuntu is doing.
The fact that Canonical shoehorned snaps into apt is the problem. I’ve heard bad things about snap, but I wouldn’t know because I’ve never used it, and I never will because of this.
When I tell my computer to do one thing and it does something completely different without my consent, that is a problem, and is why I left Windows. I don’t need that in Linux too, and Canonical has proven they can’t be trusted not to do that.
There are big differences between Snaps and Flatpaks.
- both the flatpak server and the client are open source
- flatpak does not publish 3rd party apps, promoting them as verified (https://news.itsfoss.com/valve-steam-snap-ubuntu/)
I never used snap, always use official repo > multilib > extra > chaotic aur > aur > flatpak > FUCK IT, I BUILD FROM SOURCE CODE FROM SHADY GITHUB REPO
FUCK IT, I BUILD FROM SOURCE CODE FROM SHADY GITHUB REPO_*
I feel seen.
curl shit | sudo bashis just so convenient.I hope you mean
https://shit.http://mysite.net | sudo bashYes, always from
https://gìthub.comOf course, you will certainly not regret piping curl into bash from GitHub.com.
The safest install method \s
Thread made by canonical employee
Lol imagine a canonical employee using nixos
Now also throw GNU Guix, Homebrew and some AppImages in there
deleted by creator
Why?
People using Linux should take their heads out of their asses sometimes and just let people enjoy things they way they prefer.
Fuckin preach it friend!
That’s the joy of Linux, the “have it your way” approach to an OS
yeah well, you can’t have it your way on Ubuntu when Canonical FORCES you to use snaps (heck they even hacked apt to prefer snaps instead of debs)
You’re still missing the point.
and what point would that be? That you can’t have it your way, actually?
No, that some people’s way involves using snap, and that’s fine.
These are two incredibly persistent pieces of misinformation…
- Canonical provides snaps for Ubuntu. This is no more “forcing” you to use snaps than they force you to use debs, or than Fedora forces you to use flatpaks/rpms.
- Apt doesn’t “prefer snaps” by any means. Canonical provides transitional packages for certain packages that got migrated from debs to snaps, but the steps for using another apt repository to replace one of these transitional packages are the same as the steps for replacing any other package provided in your base repos with one from a different repository: You add the other repository, and you tell apt to prefer that repository for the specific packages.
If you were running a previous version of Ubuntu, where you had deb packages which worked, over the course of a few updates, they replaced half of your programs with snaps (without telling you), which were unable to see additional hard drives, USB pens, printers, scanners or cameras, couldn’t use plug-ins, couldn’t use 3rd party templates or presets, and didn’t respect any system settings for fonts/text size, icon placement and so on.
Snaps were fine for “aisleriot solitaire” or “calculator” (assuming you didn’t mind a 5 minute loading time) or other things which didn’t need to interact with any file or system or device, but for actual programs for people trying to do work? Bag of shite.
Now, I imagine some years later they must have fixed some of this rubbish, and I read recently they might have finally done something about permissions, but no, they didn’t ask anyone before they swapped working programs for completely broken snaps. They forced it on their existing users, and some of us bear grudges.
over the course of a few updates, they replaced half of your programs with snaps (without telling you),
You don’t need to lie. A full list of debs that have been transitioned to snaps is:
- Firefox
- Thunderbird
- Chromium
Sorry, I might have misremembered the exact process (this was probably three or four years ago), though no need for the nasty aggressive attitude (though my apologies if I offended you somehow).
Maybe it was version upgrades (e.g 18.04 to 20.04) instead of updates, or clean installs/new installs/reinstalls? I expect it was some of one and some of another.
At the time I used to (casually) maintain a bunch of Ubuntu computers for a few community projects, small organisations and older people who live nearby. I don’t remember the specifics, I just remember the phone calls of “the printer isn’t working” “Linux has broken my USB pen” etc, and the fix being “remove the snap version and install the deb version”. It caused a lot of problems.
If that is true, then why are deb packages provided by Canonical for Ubuntu dummied out?
Canonical FORCES you to use snaps, there is no other way to look at this.
They do not prevent you from adding repos and installing from those. They don’t even try to make it slightly more difficult to do so than it was before. Microsoft force you to use edge. Cannot really disable it. Can’t remove it. Can’t simply switch away from it. See the difference?
I haven’t kept up with Edge Shenanigans since I no longer use Windows, but the last time I used it I had no issues using Firefox instead of Edge.
Yeah sure you can add repositories to replace Canonical Sources to evade those dummied out packages, but you really really shouldn’t need to do that in the first place.
So the only difference is: MS enforcement is more stringent than Canonical, but they both force their respective ways onto the user (which may or may not versed enough to actually add/remove apt repositories).
you can install firefox, but even if you click ‘make firefox my default browser’, it won’t. It will open the settings, wait a second and then show you another button. Clicking that will do what you wanted - for web links. Pdf files? Html files? Searches from the start menu? Still all open edge.
On ubuntu it takes maybe a minute to remove the firefox snap, add the mozilla repo and install from there. Those dummie packages are more for convenience than anything nefarious. I agree that snaps have been made unavoidable if you’re not paying attention, but I disagree that it’s a bad thing. Ubuntu is migrating from .debs to snaps, so it makes sense that those become ever more prominant.
Canonical provides transitional packages for packages that they’ve decided to provide as snaps. They’re not forcing anyone to use snaps, they’re saying “if you want the default we provide you, we’re providing you with a snap.” KDE Neon (my current distro, which is downstream of Ubuntu) has decided that they want to use the deb packages from packages.mozilla.org, so they provide an override. If you want to use the deb from packages.mozilla.org, you could grab KDE Neon’s repository deb and install that, or just set up the mozilla repository and use the same pin file they already have.
This is like saying “Debian FORCES you to use libav” Debian moved from ffmpeg to libav for a while. No, they provided libav and made transitional packages for this drop-in replacement. Some people didn’t like that and made their own ffmpeg repos, and the process for using their separate ffmpeg rather than Debian’s transitional packages was the same as the process for using Firefox from a different repository. (I was one of the people used some third-party ffmpeg repositories, and I was glad when they switched back to ffmpeg and provided libav to ffmpeg transitional packages.)
Does the fact that the Ubuntu repositories don’t contain Keysmith mean “Ubuntu PROHIBITS you from using Keysmith?”
Canonical provides transitional packages for packages that they’ve decided to provide as snaps. They’re not forcing anyone to use snaps, they’re saying “if you want the default we provide you, we’re providing you with a snap.”
Uhm… and why does the user have to transition to snaps? Why does Canonical provide those transitional packages while there are perfectly valid debs for the same thing? Certainly not because they have a vested interest in forcing it right?
you instantly refute yourself, kudos!
Uhm… and why does the user have to transition to snaps?
They don’t. But Canonical will no longer be providing debs in primary Ubuntu repositories, so those transitional packages exist so that users don’t wind up with an abandoned, old version of Firefox.
Why does Canonical provide those transitional packages while there are perfectly valid debs for the same thing?
For the same reason neither Ubuntu nor Debian provide debs for Google Chrome, despite Google having an official apt repository? Those debs exist in somebody else’s apt repository. If you want to add that apt repository, you’re welcome to. But those external packages aren’t part of the system they provide.
you instantly refute yourself, kudos!
Your unwillingness to accept what I’m saying doesn’t make what I’m saying contradictory.
Heck yeah! There’s so much gatekeeping and tribalism that it kinda sucks out the joy a little bit
It’s a shame that snaps are forced to use Canonicals closed source backend because they are really good, and a fully snap system is a very compelling idea for immutable systems
They’re not forced to do so. You can install snaps locally (or provide a distribution system that treats
snapdmuch the wayapttreatsdpkg), or you can point snapd at a different store. The snap store API is open and documented, and for a while there was even a separate snap store project. It seems to have died out because despite people’s contention about Canonical’s snap store, they didn’t actually actually want to run their own snap stores.I don’t know why you’re getting downvoted. It makes perfect sense that Cannonical made it’s own proprietary package ecosystem and while technically anyone can build their own snap store, ain’t nobody got time for that.
I don’t agree that it made any sense to do that. If they wanted to containerize apps, there has been an open source solution to that for years; Flatpak.
ain’t nobody got time for that
As an app maintainer, that wants to support Ubuntu, why would I prefer to deploy a snap server, instead of publishing deb files, or creating a Flatpak?
It’s Cannonical. They prefer implementing everything themselves fast, rather than developing a more sustainable project with the rest of the community over a longer timescale. It makes sense that when they do that, there will be very little buy-in from the wider community. Much like Unity and Mir.
As you say - why would others put time into the less supported system? Better alternatives exist. If Canonical want their own software ecosystem, they’ll have to maintain it themselves. Which, based on Mir and Ubuntu Touch, they don’t have a good track record of.
Can you explain why it makes perfect sense?
It’s Cannonical. They prefer implementing everything themselves fast, rather than developing a more sustainable project with the rest of the community over a longer timescale. When they do that, there will be very little buy-in from the wider community.
Others could technically implement another snap store for their own distro, but they’d have to build a lot of the backend that Cannonical didn’t release. It’s easier to use Flatpak or AppImage or whatever rather than hitch themselves onto Cannonicals’s homegrown solution that might get abandoned down the line like Mir or Ubuntu Touch.
Because people who just want their daily Two Minutes’ Hate rather than actually having nuanced takes.
Snap is bad. I only say this as someone who did a lot of OS security work for Linux and Unix, so take that with a grain of salt.
Would you mind explaining why? I’m genuinely curious
snap bad indeed
I use nix like the AUR for debian.
I have NODE installed using snap lmao. Why? Installing it the normal way just gives me tons of errors that I’m too bored to deal with. I’m sure there’s a fix, but I’m too lazy to debug all that. Of course, I don’t use snap node for hosting servers and stuff. I just use it for react native. Regardless, it works n I’m happy lol
Yeah. I don’t mind
snapat all for cases where a better package doesn’t exist.What made me give up Ubuntu was how it railroaded me into
snapversions of packages that work better, for me, as native.debinstalls.Oh definitely. Canonical forcing us to use snap Firefox was very shitty. I mean I still use Ubuntu because I’m lazy, but I did change the snap Firefox thing to the apt libraries or whatever.
I really don’t understand why they don’t just adopt flatpak.
I don’t believe Flatpak has the ability to package something like node. It certainly can’t package kernels or system services (at least not without leaving the user with a ton of manual work to do that would make it not much better than getting a tarball).
