> Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.
This is a great summary of why people rightfully feel nervous about Snap. People run linux because they want visibility and control into what is happening on their systems. Canonical seems to want to take away that visibility and control from their users.
I can set up an internal APT mirror for my users, servers, test systems, etc., but I can't set up an internal snap mirror as far as I can tell. This means that despite having an internal repo that I can whitelist, some package installations will now arbitrarily require internet access. I can no longer install chromium on a system without access to the internet, and package installation will fail as a result.
I'd rather have an older version than a snap version, personally, but better would be two packages which Provides: the same chromium-browser, chromium and chromium-snap.
The most irritating thing here is that they're using a package distribution system which handles dependencies and updates flawlessly, and has for decades, and using it to install things using a package system which does not solve those problems, and instead ships multiple copies of multiple libraries and applications, which run slower, ignoring any settings I have in APT.
So far, it's a maintenance nightmare, and I loathe it.
I can see why Snap is like it is from Canonial's perspective - but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises
> Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.
Short version: Canonical does classic vendor lock-in with his Snap Store. I'm pretty sure 99.9% HN users knows what it means :)
You absolutely nailed it and this is why -- if I have any say in this (and I do) -- we will be moving away from Ubuntu.
It's a completely insane stance for server systems. (I believe it's still possible to run server systems without snaps with various "workarounds" etc, but we can feel which way the wind is blowing...)
Is there no way to sandbox these packages - "have you cake and eat it too?" I'm a noob to modern Linux.
Edit: Are snaps images? ...like containers?
Edit 2: answer:
> mounted dynamically by the host operating system, together with declarative metadata that is interpreted by the snap system to set up an appropriately shaped secure sandbox or container for that application
> People run linux because they want visibility and control into what is happening on their systems.
I mean, not really? Or rather, that's not the only reason, or the main reason for many users.
Many people just want to use a FOSS OS, for the reason that any buggy component can be forked, fixed, and PRed, which—if you're an IT organization yourself—often means far less turnaround time than waiting for the appropriate vendor to fix the problem for you.
Honestly, I'd be fine using Windows Server or some other "cathedral" OS, if I could fork/fix/PR its components. I want a stable operational substrate for my app that's quick to fix in an emergency; I don't care whether it's made out of tiny shell-scripts or huge C libraries, as long as it gives me that property.
In that perspective, snap seems fine (you can still fork/fix/PR a snap) just like Docker images are fine, or systemd is fine.
Maybe, in the end, I'm more of a BSD person than a Linux person. I mostly favor Linux installs for the hardware compatibility and performance, not because it really fits my philosophy.
> Canonical seems to want to take away that visibility and control from their users.
The Microsoft way: over-automated operating system DE's which attempt to make the OS appear user friendly yet create one headache after another. They suffer from massive interconnected webs of program state and logic which fails leaving you with the only sane option of rebooting. The more automation the vendor inserts the less transparency and control you have.
>People run linux because they want visibility and control into what is happening on their systems. Canonical seems to want to take away that visibility and control from their users.
tbh I just run linux because I want a good dev machine and I personally don't care if canonical abstracts updating software away, as far as I'm concerned they can keep everything up to date and do their thing, for me that's a plus for snaps, I generally find them pleasant to use.
In my experience people on HN in particular tend to vastly overestimate how much people value control vs features/abstracting routine tasks away.
But Mint are too lazy to build their own packages so they use Ubuntu binaries that are installed as root, this is IMO a PR move and a hypocrisy, if you don't trust Canonical don't use Mint use Debian or some distribution that has the capacity to host and build their binaries.
> Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them...
I think it should be noted that this generally applies to the addition of "third party apt repositories" in general, use of which is the problem that snaps fix[1]
Some snaps are built from Free Software and reproducible sources, as are some third party apt repositories.
In other words, if this criticism bothers you, then you should never install from any third party apt repositories ever. If some are acceptable to you, then so should some snaps.
If you don't want to use third party software ever, then you can still use Ubuntu without snaps.
[1] Third party apt repositories often break users' systems.
Snaps are super laggy. GNOME calculator on Ubuntu runs in a snap and it is baffling that whoever made the decision to package it in a snap by default was OK with the fact that it takes 2 seconds to launch a basic calculator on a 2017 laptop (edit: re-tested, it took 5 seconds).
To top it off, a couple months ago my calculator disappeared. For some reason I have been having problems with snap applications disappearing for a while now, even though I have made no configuration changes. How fun it is to discover that such a basic tool just no longer exists on your machine, way to fuck up a morning.
I get that snaps make application distribution easier, but please don't do it at the expense of the user. I've had more success with Flatpak and AppImages, but not enough experience with any of them to judge which is best.
This move made me 100% opposed to snap. Don't beta test on my daily-drivers as a default.
The calculator should -always- load in a couple ms. It's one of the simplest tools on the shelf! If a calculator snap can't load immediately then I have no interest in a single other snap app. Waiting more than a second is a nightmare, and I've definitely waited 5+ seconds at times. That's about how long it takes my system to boot. As far as I'm concerned it's a complete failure and I couldn't possibly trust it on any desktop or server that I manage.
This is exactly my experience. On top of that snap creates visible directories in $HOME, f-up my loop devices and snap applications can't even access /tmp. Never had any problems with flatpak and appimage. I will however use it solely for proprietary software.
I think it's because they extract compressed rootfs tar each time to be mounted in LXC container. Even with a beefy computer, it takes considerable time.
Sounds like Windows with their UWP apps. Calculator also used to take 5 secs to load. It’s down to about a second now but still baffles me to think that MS management are ok with that
It's interesting in that I quite like the idea of snap packages, just not their implementation. I recently purged snaps from my Ubuntu Mate machines after a few years of use because of the realization of only using two:
1. The micro terminal editor.
2. Chromium, because it was forced.
Well, #1 was packaged for 20.04 so I didn't need it any longer. That left Chromium. For that single package, I had to tolerate my system being spammed all over:
- Multiple irrelevant loopbacks cluttering my mounts list
- Dedicated folders in filesystem: /snap ~/snap
- Very slow startup, for chromium.
- Lots of disk space taken
- An always running daemon! (Wasn't it root too? Can't remember). apt doesn't need a daemon.
Sheesh! That's not even mentioning the store issues which others have described already.
Sorry, but a few newer packages here and there are not worth all that. I'll handle it myself, thanks. What snap does isn't actually that hard. I'd keep it around if it wasn't so obnoxious at putting itself in front and center of everything.
Snap sounds to me like the latest of many decisions by Canonical that are more like what you'd expect from a commercial vendor than a FOSS one. This is Microsoft-level coercing people into your own ecosystem.
I don't doubt for a moment that it makes business sense for Canonical, but I really wonder whether there's a market for this - the huge majority of people who don't care about this kind of thing are on Windows or Mac, or even just working happily away on their phones and tablets.
Linux' selling point for me was always that I was in control and could make the system work the way I wanted to; people more ideologically pure than me have slogans like "free as in freedom" or "binary blobs are bad".
I really don't see the market for "linux, but with commercial vendor practices". I switched from ubuntu to mint a while ago and I'm really happy about that right now.
I'm not sure I see how it even makes business sense. Trying to compete with with Apple and Microsoft by eliminating your strengths to focus on your weaknesses isn't a good play. Gnome and Ubuntu are not and will never be as smooth and integrated as MacOS, and that's okay because that's not why people use them. Take away the openness and you have a slower, uglier Mac with a worse app store.
If desktop Linux is ever going to be mainstream there needs to be an easy to use "app store" where users can use a GUI to install apps which need to be sandboxed like on a mobile phone with defined permissions. Snapcraft is way ahead of Flatpak on this and the current Ubuntu setup works well. On Ubuntu you can go to the Ubuntu software app (gui) search for software and it blends apt results with snap results. This really seems like the best way to do things, common packages can be installed through a traditional package manager while more niche ones can be installed with snap. A lot of people are mad at Canonical for not open sourcing the backend but no one seems to be offering to build one. Anyways the really important part of snap is having a unified executable for Linux (which Canonical has made open source).Snap makes it really easy for developers to target Linux with a unified executable which they won't do otherwise due to Desktop Linux's small market share.
I've been kind of disappointed by Snap. It seemed like it was a way to always have the latest version of software you care about available, but in practice, nobody updates their Snaps. I used it to get a newer version of Go, and while it is more recent than what comes with Ubuntu, it's still not the latest version. Apparently Some Guy updates it on a volunteer basis when he remembers, so it's nearly useless.
Even if people do update the Snap, it's clear that it provides too many features. It has some sort of isolation model... that every Snap I've ever installed requires you to disable.
It's also surprisingly expensive to run something in a snap. For example, getting the name of my current k8s context with "kubectl config current-context":
The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. Namely that it would be expensive to open source it with little benefit in return.
Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. Mainly because the majority of the costs are for operating an instance which most other distros aren't willing to spend.
Not even Mint operate run or operate their own launchpad infrastructure. They experienced large backlash back then, open sourced it and nobody contributed.
The same problem applies here. Snap store specifically from what I gather is a bunch of operational machinery that doesn't make sense without also operating launchpad. Such a cost operating would benefit nobody but Canonical because
nobody else is bothering footing the bill to run an instance.
Second aspect that they wanted to avoid was the same pitfalls that they experienced previously with ppas and now being experienced with flatpak. Namely they want one location to find software, and one location to serve software.
If users have to use the command line to add a external repo that has unfetted access, then that defeats any usability gains. That and the whole aspects of malware/trust goes out the window.
I will remind people that the most popular PPA to this day is a Java PPA being run by some 3rd party that doesn't offer Java. That PPA has root access to thousands of machines.
> The Linux Mint project has made good on previous threats to actively prevent Ubuntu Snap packages from being installed through the APT package-management system without the user's consent. This move is the result of "major worries" from Linux Mint on Snap's impact with regard to user choice and software freedom. Ubuntu's parent company, Canonical, seems open to finding a solution to satisfy the popular distribution's concerns — but it too has interests to consider.
An excellent and succinct summary of the issue in the first paragraph. I have to hand it to LWN for excellent synopsis/summary paragraphs in the articles. This is a lost art in today's clickbait headline where the lede is buried in the center of the Earth.
The jetbrains stuff keeps several versions around by default, which eats disk space. I'm sure there's a way to change that, but I haven't cared enough to dig.
The other day I ran `apt install chromium-browser` on a brand new install; it chose to install via snap (grr) and then snapd promptly crashed ("Waiting for restart" -- https://forum.snapcraft.io/t/installing-the-chromium-snap-in...), but apt's wrapper wasn't notified. I ended up ctrl-Cing, which left dkpg (somehow involved) in an inconsistent state. Took several iterations of dkpg reconfigure and apt update to recover. I've been on linux for 20 years, so not a big deal for me, but my experience has been that snap is less newbie friendly than apt.
I immediately thought of Linux Mint Debian Edition when I saw this. They describe it as something they are developing just in case, you know, "Ubuntu was ever to disappear." Well, excepting for some kind of Microsoft acquisition of Canonical ("we will be shifting our focus to developing Ubuntu for WSL"), I don't think Ubuntu will disappear, but it certainly might become so unfriendly to downstream distros that they have to move off of it.
Canonical's decision to abuse the power of apt packages to make it some "universal installer" is kinda gross. I get the thought but I would consider is surprising that, say, installing python-* actually installed pip and ran pip install.
This is totally going to break Gnome Software's UI since it has plugins for snap, flatpack, apt, dnf, pacman, etc.. and making it so that Chromium from apt is doing a run-round with snap makes it really confusing to the user.
I think the LWN article misunderstands what Ken VanDine meant by “pressure” in the following quote:
> By shipping such a key application as a snap it will continue to keep pressure on to ensure we keep improving the experience while also reducing our maintenance burden for the LTS and future releases of Ubuntu.
The article takes the quote to mean that “Canonical … is using [Snap] to apply pressure where it wants to see change” and implies that Canonical is trying to pressure distros like Linux Mint to support Snap. But I think VanDine meant only that using Snap in a high-profile package puts pressure on Canonical to make Snap easier to use in Ubuntu.
That’s a less controversial goal than the one implied by the article. Of course, whether Canonical’s actions are truly motivated by that goal is a separate discussion topic.
I've been wondering for a while whether the concept of "open source" and its connection to freedom are becoming meaningless.
Source code has been a dynamic thing for a while, and I think that's part of the reason the GPL (at least v2) is not very popular any more. I mean, nobody really even wants source code, it's just a maintenance headache.
Even after complexity started to take over, there was still the argument that you could audit your computer if it was doing something funny, or ask a different company to maintain it for you, instead. But that seems less and less practical as time goes on. The company that wrote the software is really the only game in town to keep it useful.
Snaps are a logical extension of this phenomenon. They cross a line in the sand, perhaps, but basically just continue a trend already going on.
Also, the unix security model seems fundamentally bad. The idea that any code you execute can delete everything in your home directory is insane. It imposes a huge burden of trust on your software distribution system for the most trivial things. That reduces the practicality of using third-party sources.
I'm not really defending snaps and I will probably avoid them as long as I can. But I sort of feel like the battle might already be lost.
I wonder if it is finally time for me to give Arch a try. It's a shame that all my lab's machines run Ubuntu; although I find it solid, this sort of controlling behavior by Canonical seems against the spirit of FOSS.
It's very funny that this article is two places above the article about how Canonical is bringing Flutter to Linux via the Snap Store. Some choice quotes from that article:
> Flutter’s native cross-platform story is growing rapidly and Canonical wanted to be at the vanguard.
> By making Linux a first class Flutter platform, Canonical is inviting application developers to publish their apps to millions of Linux users and broaden the availability of high quality applications available to them.
> Canonical will continue to collaborate with Google to further improve Linux support and maintain feature parity with the other supported platforms.
Is it time to switch from Ubuntu to Mint? Does Mint have enough repositories that work? I'm at Ubuntu 18.04 LTS, and Ubuntu 20 seems to have a host of unwanted Canonical-oriented features. I'd appreciate comments.
Just today I switched from Ubuntu to Pop_OS (I hate that name). Unity was giving me some trouble as it's starting to conflict with all the newer stuff so I had to make a decision.
I dislike Gnome Shell. It's clean and fast but the GUI is "locked" to the main monitor and I can't even switch windows without looking at it.
But I love how the distro is made focusing on a good user experience. To give you an example, the shop (software center) allows me to choose between deb packages and flatpak if available. Sounds like something obvious, but after having snaps shovelled down my throat when I was thinking I was installing deb packages, this means I can finally trust my distro again.
Now the only thing I need is a good DE. Maybe the next decade.
It just another bad move from Canonical in a long list of terrible failures, which weakend Linux fundamentally:
* Upstart vs Systemd
* Mir vs Wayland
* Snap vs. Flatpak
* Unity vs. GNOME and Gtk
* Ubuntu Phone vs. you should have teamed up with Nokia and Maemo before...
Looks like they don't learn. The fork and fight against the others and always lose.
Nowadays Ubuntu is upstreaming usefull patches to GNOME, again. Thank you! But imagine what GNOME and Gtk could be look like already, when Ubuntu had "helped" them earlier. I could be already a lot of better years ago? Mutter, Gtk, Terminal and Nautilus. GNOME is healthy! But they could so much better years ago.
Forking is good thing, when it aims initially for a merge.
I'm unclear why ubuntu needs the chromium package in apt. Seems like they should just stop publishing apt packages for chromium, only publish in snap, and steer users into using snap for installs and not apt. Seems less confusing and wins or loses on its merit.
[+] [-] psanford|5 years ago|reply
> Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.
This is a great summary of why people rightfully feel nervous about Snap. People run linux because they want visibility and control into what is happening on their systems. Canonical seems to want to take away that visibility and control from their users.
[+] [-] danudey|5 years ago|reply
I can set up an internal APT mirror for my users, servers, test systems, etc., but I can't set up an internal snap mirror as far as I can tell. This means that despite having an internal repo that I can whitelist, some package installations will now arbitrarily require internet access. I can no longer install chromium on a system without access to the internet, and package installation will fail as a result.
I'd rather have an older version than a snap version, personally, but better would be two packages which Provides: the same chromium-browser, chromium and chromium-snap.
The most irritating thing here is that they're using a package distribution system which handles dependencies and updates flawlessly, and has for decades, and using it to install things using a package system which does not solve those problems, and instead ships multiple copies of multiple libraries and applications, which run slower, ignoring any settings I have in APT.
So far, it's a maintenance nightmare, and I loathe it.
[+] [-] jonquark|5 years ago|reply
[1] https://flathub.org/home
(Disclaimer: I'm talking in a personal capacity but the company I work for in my day job now owns Red Hat - I don't work on Linux Operating Systems).
[+] [-] paulcarroty|5 years ago|reply
Short version: Canonical does classic vendor lock-in with his Snap Store. I'm pretty sure 99.9% HN users knows what it means :)
[+] [-] heavyset_go|5 years ago|reply
It's a commonly requested feature and being able to move it would follow the Freedesktop.org spec, but the developers don't care.
[+] [-] Quekid5|5 years ago|reply
It's a completely insane stance for server systems. (I believe it's still possible to run server systems without snaps with various "workarounds" etc, but we can feel which way the wind is blowing...)
[+] [-] curt15|5 years ago|reply
In particular, it's easy to inspect the sources for apt packages using "apt-get source". Snap seems to have no equivalent command.
[+] [-] craftinator|5 years ago|reply
[+] [-] ncr100|5 years ago|reply
Edit: Are snaps images? ...like containers?
Edit 2: answer:
> mounted dynamically by the host operating system, together with declarative metadata that is interpreted by the snap system to set up an appropriately shaped secure sandbox or container for that application
[+] [-] arexxbifs|5 years ago|reply
[+] [-] red_admiral|5 years ago|reply
[+] [-] derefr|5 years ago|reply
I mean, not really? Or rather, that's not the only reason, or the main reason for many users.
Many people just want to use a FOSS OS, for the reason that any buggy component can be forked, fixed, and PRed, which—if you're an IT organization yourself—often means far less turnaround time than waiting for the appropriate vendor to fix the problem for you.
Honestly, I'd be fine using Windows Server or some other "cathedral" OS, if I could fork/fix/PR its components. I want a stable operational substrate for my app that's quick to fix in an emergency; I don't care whether it's made out of tiny shell-scripts or huge C libraries, as long as it gives me that property.
In that perspective, snap seems fine (you can still fork/fix/PR a snap) just like Docker images are fine, or systemd is fine.
Maybe, in the end, I'm more of a BSD person than a Linux person. I mostly favor Linux installs for the hardware compatibility and performance, not because it really fits my philosophy.
[+] [-] musicale|5 years ago|reply
[+] [-] MisterTea|5 years ago|reply
The Microsoft way: over-automated operating system DE's which attempt to make the OS appear user friendly yet create one headache after another. They suffer from massive interconnected webs of program state and logic which fails leaving you with the only sane option of rebooting. The more automation the vendor inserts the less transparency and control you have.
[+] [-] Barrin92|5 years ago|reply
tbh I just run linux because I want a good dev machine and I personally don't care if canonical abstracts updating software away, as far as I'm concerned they can keep everything up to date and do their thing, for me that's a plus for snaps, I generally find them pleasant to use.
In my experience people on HN in particular tend to vastly overestimate how much people value control vs features/abstracting routine tasks away.
[+] [-] MR4D|5 years ago|reply
[+] [-] simion314|5 years ago|reply
[+] [-] rlpb|5 years ago|reply
I think it should be noted that this generally applies to the addition of "third party apt repositories" in general, use of which is the problem that snaps fix[1]
Some snaps are built from Free Software and reproducible sources, as are some third party apt repositories.
In other words, if this criticism bothers you, then you should never install from any third party apt repositories ever. If some are acceptable to you, then so should some snaps.
If you don't want to use third party software ever, then you can still use Ubuntu without snaps.
[1] Third party apt repositories often break users' systems.
[+] [-] emerongi|5 years ago|reply
To top it off, a couple months ago my calculator disappeared. For some reason I have been having problems with snap applications disappearing for a while now, even though I have made no configuration changes. How fun it is to discover that such a basic tool just no longer exists on your machine, way to fuck up a morning.
I get that snaps make application distribution easier, but please don't do it at the expense of the user. I've had more success with Flatpak and AppImages, but not enough experience with any of them to judge which is best.
[+] [-] enobrev|5 years ago|reply
The calculator should -always- load in a couple ms. It's one of the simplest tools on the shelf! If a calculator snap can't load immediately then I have no interest in a single other snap app. Waiting more than a second is a nightmare, and I've definitely waited 5+ seconds at times. That's about how long it takes my system to boot. As far as I'm concerned it's a complete failure and I couldn't possibly trust it on any desktop or server that I manage.
[+] [-] clktmr|5 years ago|reply
[+] [-] jeffdavis|5 years ago|reply
The same thing with phones. Smart phones are good at a lot of things, but they are mediocre as a telephone.
[+] [-] CSDude|5 years ago|reply
[+] [-] aritmo|5 years ago|reply
[+] [-] flipchart|5 years ago|reply
[+] [-] RMPR|5 years ago|reply
[+] [-] znpy|5 years ago|reply
I now switched to xcalc. gnome-calculator is better, honestly, but it's not worth feeling in the 90ies.
[+] [-] coronadisaster|5 years ago|reply
[+] [-] mixmastamyk|5 years ago|reply
1. The micro terminal editor.
2. Chromium, because it was forced.
Well, #1 was packaged for 20.04 so I didn't need it any longer. That left Chromium. For that single package, I had to tolerate my system being spammed all over:
- Multiple irrelevant loopbacks cluttering my mounts list
- Dedicated folders in filesystem: /snap ~/snap
- Very slow startup, for chromium.
- Lots of disk space taken
- An always running daemon! (Wasn't it root too? Can't remember). apt doesn't need a daemon.
Sheesh! That's not even mentioning the store issues which others have described already.
Sorry, but a few newer packages here and there are not worth all that. I'll handle it myself, thanks. What snap does isn't actually that hard. I'd keep it around if it wasn't so obnoxious at putting itself in front and center of everything.
[+] [-] boring_twenties|5 years ago|reply
[+] [-] nemetroid|5 years ago|reply
https://bugs.launchpad.net/snappy/+bug/1620771
https://forum.snapcraft.io/t/how-can-i-use-snap-when-i-dont-...
[+] [-] philliphaydon|5 years ago|reply
[+] [-] red_admiral|5 years ago|reply
I don't doubt for a moment that it makes business sense for Canonical, but I really wonder whether there's a market for this - the huge majority of people who don't care about this kind of thing are on Windows or Mac, or even just working happily away on their phones and tablets.
Linux' selling point for me was always that I was in control and could make the system work the way I wanted to; people more ideologically pure than me have slogans like "free as in freedom" or "binary blobs are bad".
I really don't see the market for "linux, but with commercial vendor practices". I switched from ubuntu to mint a while ago and I'm really happy about that right now.
[+] [-] Miraste|5 years ago|reply
[+] [-] pjfin123|5 years ago|reply
[+] [-] jrockway|5 years ago|reply
Even if people do update the Snap, it's clear that it provides too many features. It has some sort of isolation model... that every Snap I've ever installed requires you to disable.
It's also surprisingly expensive to run something in a snap. For example, getting the name of my current k8s context with "kubectl config current-context":
This adds 32ms of latency before the app runs for absolutely no good reason.[+] [-] kd913|5 years ago|reply
Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. Mainly because the majority of the costs are for operating an instance which most other distros aren't willing to spend. Not even Mint operate run or operate their own launchpad infrastructure. They experienced large backlash back then, open sourced it and nobody contributed.
The same problem applies here. Snap store specifically from what I gather is a bunch of operational machinery that doesn't make sense without also operating launchpad. Such a cost operating would benefit nobody but Canonical because nobody else is bothering footing the bill to run an instance.
Second aspect that they wanted to avoid was the same pitfalls that they experienced previously with ppas and now being experienced with flatpak. Namely they want one location to find software, and one location to serve software. If users have to use the command line to add a external repo that has unfetted access, then that defeats any usability gains. That and the whole aspects of malware/trust goes out the window.
I will remind people that the most popular PPA to this day is a Java PPA being run by some 3rd party that doesn't offer Java. That PPA has root access to thousands of machines.
[+] [-] aphexairlines|5 years ago|reply
> Snap packages are effectively black-boxes; they cannot be reproduced independently as the packaging data is controlled by the package maker alone.
One of the nice properties of debian packages is the ability to `apt-get source` and build it locally. Would be a shame to lose that.
Maybe Nix and Guix can provide the best of both worlds here: self-contained software but reproducible builds too.
[+] [-] ed25519FUUU|5 years ago|reply
An excellent and succinct summary of the issue in the first paragraph. I have to hand it to LWN for excellent synopsis/summary paragraphs in the articles. This is a lost art in today's clickbait headline where the lede is buried in the center of the Earth.
[+] [-] flavor8|5 years ago|reply
The jetbrains stuff keeps several versions around by default, which eats disk space. I'm sure there's a way to change that, but I haven't cared enough to dig.
The other day I ran `apt install chromium-browser` on a brand new install; it chose to install via snap (grr) and then snapd promptly crashed ("Waiting for restart" -- https://forum.snapcraft.io/t/installing-the-chromium-snap-in...), but apt's wrapper wasn't notified. I ended up ctrl-Cing, which left dkpg (somehow involved) in an inconsistent state. Took several iterations of dkpg reconfigure and apt update to recover. I've been on linux for 20 years, so not a big deal for me, but my experience has been that snap is less newbie friendly than apt.
[+] [-] pyrophane|5 years ago|reply
[+] [-] Spivak|5 years ago|reply
This is totally going to break Gnome Software's UI since it has plugins for snap, flatpack, apt, dnf, pacman, etc.. and making it so that Chromium from apt is doing a run-round with snap makes it really confusing to the user.
[+] [-] roryokane|5 years ago|reply
> By shipping such a key application as a snap it will continue to keep pressure on to ensure we keep improving the experience while also reducing our maintenance burden for the LTS and future releases of Ubuntu.
The article takes the quote to mean that “Canonical … is using [Snap] to apply pressure where it wants to see change” and implies that Canonical is trying to pressure distros like Linux Mint to support Snap. But I think VanDine meant only that using Snap in a high-profile package puts pressure on Canonical to make Snap easier to use in Ubuntu.
That’s a less controversial goal than the one implied by the article. Of course, whether Canonical’s actions are truly motivated by that goal is a separate discussion topic.
[+] [-] jeffdavis|5 years ago|reply
Source code has been a dynamic thing for a while, and I think that's part of the reason the GPL (at least v2) is not very popular any more. I mean, nobody really even wants source code, it's just a maintenance headache.
Even after complexity started to take over, there was still the argument that you could audit your computer if it was doing something funny, or ask a different company to maintain it for you, instead. But that seems less and less practical as time goes on. The company that wrote the software is really the only game in town to keep it useful.
Snaps are a logical extension of this phenomenon. They cross a line in the sand, perhaps, but basically just continue a trend already going on.
Also, the unix security model seems fundamentally bad. The idea that any code you execute can delete everything in your home directory is insane. It imposes a huge burden of trust on your software distribution system for the most trivial things. That reduces the practicality of using third-party sources.
I'm not really defending snaps and I will probably avoid them as long as I can. But I sort of feel like the battle might already be lost.
[+] [-] jefft255|5 years ago|reply
[+] [-] trashburger|5 years ago|reply
> Flutter’s native cross-platform story is growing rapidly and Canonical wanted to be at the vanguard.
> By making Linux a first class Flutter platform, Canonical is inviting application developers to publish their apps to millions of Linux users and broaden the availability of high quality applications available to them.
> Canonical will continue to collaborate with Google to further improve Linux support and maintain feature parity with the other supported platforms.
[+] [-] Animats|5 years ago|reply
[+] [-] Darmody|5 years ago|reply
I dislike Gnome Shell. It's clean and fast but the GUI is "locked" to the main monitor and I can't even switch windows without looking at it.
But I love how the distro is made focusing on a good user experience. To give you an example, the shop (software center) allows me to choose between deb packages and flatpak if available. Sounds like something obvious, but after having snaps shovelled down my throat when I was thinking I was installing deb packages, this means I can finally trust my distro again.
Now the only thing I need is a good DE. Maybe the next decade.
[+] [-] ho_schi|5 years ago|reply
It just another bad move from Canonical in a long list of terrible failures, which weakend Linux fundamentally: * Upstart vs Systemd * Mir vs Wayland * Snap vs. Flatpak * Unity vs. GNOME and Gtk * Ubuntu Phone vs. you should have teamed up with Nokia and Maemo before...
Looks like they don't learn. The fork and fight against the others and always lose.
Nowadays Ubuntu is upstreaming usefull patches to GNOME, again. Thank you! But imagine what GNOME and Gtk could be look like already, when Ubuntu had "helped" them earlier. I could be already a lot of better years ago? Mutter, Gtk, Terminal and Nautilus. GNOME is healthy! But they could so much better years ago.
Forking is good thing, when it aims initially for a merge.
[+] [-] jwlake|5 years ago|reply