> 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.
OK, "forever" is hyperbole - it was probably about 5 seconds. But it was enough of an annoyance for me to figure out how to install a deb packaged version. And every user having to wait an extra 5 seconds every time they open an app aggregates to a lot more time than Canonical saves maintaining packages.
That doesn't sit right with me, so my next OS upgrade will be Mint or pure Debian. I've been with Ubuntu since Dapper Drake, and I'd like to thank Canonical for making great distros all that time. But I'm not going to follow you down the snap-only path, time for me to move on.
(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).
This is interesting, because the last few days I was actually working on packaging an application of mine as a snap/flatpak.
From my PoV, they both have their fair share of issues.
Snaps enforce a sandbox, which I think is actually a good idea, because the desktop security model is somewhat broken. If your application cannot run as a sandboxed app, you need to be granted special permissions by canonical after manual review (my app needs this), where they also discuss if they can make a new permission in a safe way for your usecase that everyone can use afterwards.
On one hand this sucks because I need to ask canonical for permission to publish something, and there's no certainty that I will get these permissions as a nobody for a new app nobody ever heard of before. On the other hand, I think I like that they're doing something about the desktop security model.
The next problem is, if this is denied, how do I ship updates? Provide a self updater? Easy to write, but if everyone does that, we can just go full windows and abandon package managers. Tell people to just curl | bash? That's not more secure than a potentially shady snap.
But I do have to praise canonical for being very helpful in IRC and the forums for helping me debug issues and file bugs against snap stuff.
Now flatpak on the other hand, just feels kinda weird to me.
It sandboxes things, but every application can pretty much grant itself access to everything. This is a completely different philosophy, but if you rely on everyone tightly sandboxing their applications without granting themselves permissions for sandbox escape, I think something like landlock[0] (when it lands) or pledge is much more suited for this, and baked into the application.
Then there is this weird thing where flatpaks force a runtime on you. My application is a statically linked go binary. But flatpaks pretty much want to force me to add an entire freedesktop suite as a dependency, as you simply cannot choose no runtime.
(Community-)Support for building flatpaks? Pretty much non-existant.
So yeah, the entire linux upstream-packaging situation is still quite depressing honestly. And with the time and energy I have invested into this by now, I could have written a simple but sufficient self-updater about 10 times over.
[0]: https://landlock.io/
Like, in terms of user experience it's about as close to the Windows-style "download this .exe and run it" approach as one could get, though it'd be interesting to see a macOS-style "put this .app in your ~/Applications" approach as well (which should be doable with a daemon watching such a folder and generating e.g. menu entries and such, as an optional component or perhaps a feature of the desktop environment itself).
That's the longest spelling I've ever seen for a three-letter company.
Criticism specifically regarding Flatpak: https://flatkill.org/
Short version: Canonical does classic vendor lock-in with his Snap Store. I'm pretty sure 99.9% HN users knows what it means :)
It's a commonly requested feature and being able to move it would follow the Freedesktop.org spec, but the developers don't care.
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...)
In particular, it's easy to inspect the sources for apt packages using "apt-get source". Snap seems to have no equivalent command.
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
Also sandboxing and running apps under reduced permissions makes a lot of sense but should be seen as a tool to increase security not an answer outright as poorly used any tool can be less effective or even harmful.
Historically locking down increasingly effectively often leads to impeding things the user actually wants to do which leads to apps asking for and granting permissions with the net effect of training users click yes to enable whatever the app wants to do.
It ends up being not just a technical challenge but a psychological one as well and its less easily resolved once you start having to deal with real users.
I also think that so far Linux distributions have done very poorly when it came to cross-distribution/forward/backward compatibility of packages. This is a non-issue for popular Opensource packages since they can be easily packaged by the distributors. But not so popular packages sometimes need to be installed in a hacky way when they are not available for the target distribution. Even worse when dealing with commercial software, it can happen that it degrades with each distribution update.
Also I think that probably the package format will improve over time and add additional features, that would allow auditing for instance. Also with proper de-duplication (perhaps even on filesystem level) it should be possible to also deal with waste of space.
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.
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.
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.
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.
This does not follow at all. Third-party apt repositories work just like Ubuntu's apt repositories; you have just as much ability to audit, hold, pin, etc. in both cases.
If there is a difference in reliability (software from third-party repos is more likely to break your system--and, btw, software from Canonical's repos has also broken systems in the past, so "avoid third party repos" is not a guaranteed way to avoid software breaking your system), using snaps to install third-party software instead of third-party repos does not fix that problem: the third-party provider is still just as unreliable as before and their software is just as likely to do something stupid.
GNOME Software and KDE Discover support both Flatpak and the distribution's native package manager together. For example implementations on Ubuntu-based distributions that work out of the box, see the elementaryOS AppCenter and the Pop!_OS Pop!_Shop:
Curious... do you think that the world has moved on from the "download from website and run installer" model? Obviously that has serious drawbacks from a security perspective, but up until less than a decade ago, that was the only way to get software on Windows and macOS, and they were perfectly mainstream.
I think the majority of users out there don't understand sandboxing or permissions models or why they are useful. While I think those are the users that probably benefit from them the most, it doesn't follow that we need these things before average users will embrace a particular platform.
> A lot of people are mad at Canonical for not open sourcing the backend but no one seems to be offering to build one.
You mention Flatpak and then two sentences later claim this?
I think maybe you're just missing the point. I have been using Linux as my daily driver for a good two decades now. I don't care one bit about Linux being a mainstream desktop distro. Sure, if it was, new (and even not-so-new) hardware would get better support, and that would be a win. But getting that is not a fair trade off if what we have to accept in return is a closed-source, walled-garden software delivery model. Hard pass, no thanks.
For the most part, the only people who really care about "the year of the Linux desktop" are people trying to build a business around desktop Linux. Those aren't the sorts of people I want making decisions like this, but, unfortunately, they're often the kinds of people who have the ability to force these things on the community.
As another long time Linux guy, I have a feeling most of those obsessed with Linux becoming a mainstream desktop platform are Mac or Windows users.
Flatpak doesn't impose closed-source, we have distros which only use open source flatpak repos.
Models like Flatpak have the advantage of "download from website & install" i.e you get the apps directly from the producer (which is better for security) while having no walled garden app store but having the advantage of auto updates & permission systems
I do not like Flatpak for technical reasons but Flatpak itself is in no way a walled garden solution, the problem is Flathub.
> I don't care one bit about Linux being a mainstream desktop distro
If you still want to be able to run Linux at all (not even on new hardware) on a consumer hardware, then you should care.
- Linux doesn't run (decently) on Microsoft latest surfaces - Linux won't run on new Apple hardware - Linux doesn't run on Android phones (with a few exceptions) - once Google switch to Fushia no more Linux kernel on mobile hardware - on the long term Huawei will ditch Android and other OS for their own thing.
Linux will die on consumer hardware (except on servers) if it does not become more popular. According to Apple's keynote the future of Linux is in its cage, in a VM running on walled garden MacOS. According to Microsoft the future of Linux is WSL, running on top Windows.
If you do not like walled garden then you should definitively care about Linux getting more mainstream before no comsumer hardwares support it anymore
I used to care, nowadays I just focus on Apple, Google and Microsoft platforms instead, and leave Linux for cloud VMs.
Why? Desktop computers worked just fine for 35 or so years before app stores showed up. It's completely unnecessary.
I'm not sure that "desktop computers" as we know it were around in the 60s (I certainly wasn't), but in the early 90s software tended to come from floppy disks, before that it was a C90 cassette on a spectrum.
The iPhone launched without the AppStore. The AppStore was not the cause of Apple's success, Usability and Power were - in the sense that it allowed users to do more things (access the web from anywhere) with less effort (no booting times or ceremony). It was the first mainstream device that made it really easy to browse the web; that is what made it successful.
The AppStore was just a play to entrench that initial success by coopting third-party developers and ensure they could only sharecrop on Apple's land: "If you do anything serious with our platform, we get 30%". That's it. Nothing to do with usability. The AppStore is actually a terrible model from a usability perspective, because it collapses discovery so much that it does not scale. "Tap and run" could have been implemented as a web protocol without a centralized UI and it would have worked just fine.
The same is true of Snap. Linux does not need a centralized store, from Canonical or anyone else; that's just a play for them to get a pound of flesh from third-party developers. It has been tried so many times before in the Linux world, and it has never succeeded. Even Nokia threw a lot of money at it, and failed.
What Linux really needs, as you say yourself, is to make it easy for developers to guarantee integrity of their solutions once they reach the user. That's why Snap is getting some traction: because it promises to move power from packagers to developers and to make it easier to guarantee that a program will Just Work, without having to deal with the packaging vagaries of this or that distribution or risking that an overzealous maintainer will "improve" your stuff with crippling patches.
If Canonical were sincere in their attempts to make Linux succeed, they would concentrate on that side of things and drop the AppStore shenanigans. But that's not what they are really after.
I do not want that to be the target. Going mainstream never helped with the quality of anything. Quite the contrary: mainstream means lowest common denominator.
If you want to compromise on how much you control of your desktop os for more vendor support you already have windows and macos.
If this is what you're looking for out of a computer, then why not just use a phone, tablet, or something like ChromeOS?
Sometimes there can be tradeoffs between convenience and security, but in the case of an app store the convenience actually enhances the security, because it diminishes the chance of people running random harmful commands from the Web.
[0] https://blog.system76.com/post/616861064165031936/whats-new-...
Who says it needs to be? What if what appeals to Linux desktop users is precisely what differentiates it from the mainstream?
Snap is regressive. What we have now works better, faster, lighter, and more secure. No, you can't have a convenient means of shipping your proprietary electron 10G garbage monster to end users. We don't need it to be "mainstream".
https://en.wikipedia.org/wiki/Synaptic_(software)
Sandboxing is a laudible goal but curation is more likely to result in a system that isn't pwned in the context of current sandboxing being at present being vastly insufficient to contain real threats.
I'm not sure in what fashion flatpak is behind snap given that the former supports custom software sources served over simple existing servers, local and offline installs, runtimes, fine grained permissions via portals, and turning off automatic updates.
>A lot of people are mad at Canonical for not open sourcing the backend but no one seems to be offering to build one.
This is a very strange defense to a legitimate criticism. In what universe would anyone on earth offer to spend their own time to fork snap and write their own backend instead of using flatpak, appimage, apt or 17 other choices.
Needless to say, that was not enough for Linux to go mainstream.
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.
Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why?
> Namely they want one location to find software, and one location to serve software.
And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software.
> That and the whole aspects of malware/trust goes out the window.
Malware has already been successfully pushed to the Snap Store. The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code, we now trust software because it came from a store that removes well known malware.
If all you're doing is taking an internal repository and hosting it externally, then it takes no time. But if you make sure licenses are being used correctly throughout the code, audit to make sure no internal secrets accidentally made their way into the internal repository (this happens as much in closed source as it does in open source), and you try to remove any problematic code, commit messages or references from the code, it takes time.
Not so much proprietary software (those dependencies would be owned by Canonical and therefore released in the same lot) but I understand there is considerable dependency on deployment machinery. Documentation for that machinery will need to be split out into private (contains secrets, references to customers, etc) and public (consumable by someone looking to replicate a Snap store deployment) and so on.
> Rather than trusting software because it has verifiable source code, we now trust software because it came from a store that removes well known malware.
The world has moved to that. I don't like it. I would prefer to install only distribution-curated software. However that doesn't help me get a bunch of software that isn't available that way. Where it is (and at the version I need), I use it. Note that this particular statement of yours applies equally to AppImage, Flatpak and everything else that isn't distribution-curated. It's not just an argument against Snaps.
Im not too sure as I don't work for Canonical. However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare.
Things like potentially giving some mechanism that could enable a user to sign/publish on behalf of Canonical snaps/packages for example. That kind of thing would probably need to be removed. Deep integration between CI/operational infrastructure for things like building images. I can imagine after Canonical's experience of launchpad that they probably did hardcode aspects and it isn't some modular thing you can just spin up on docker.
>And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software.
Snaps I checked aren't there to replace apt. They don't prevent the install of flatpak, appimages or any alternative. Canonical has no agreement that prevents parties like Mozilla/KDE from only publishing on the snap store.
>Malware has already been successfully pushed to the Snap Store. We now trust software because it came from a store that removes well known malware.
There was one case of a snap bundled with a cryptominer. That was settled within 3 days and addressed to the community in a blog. Since then, it has been deliberately looked for. As someone who has published on the snap store, yes there are some checks present to ensure malicious software isn't being pushed.
>The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code,
It is really easy for me to see exactly what is being run/executed on the snaps that I install. In fact I have built/used snaps successfully without even the snap store all together.
Perhaps a business reason left unsaid is that an open source snap store would undermine Canonical's paid "enterprise edition" snap store. Why would an organization pay $30000 (https://ubuntu.com/internet-of-things) for a private app store if they could easily set up their own snap store?
The Snap server's closed-source nature is not a benefit to users, and there is no excuse that can justify this from the users' perspective.
There are always tradeoffs. I would argue there are advantages for having a trusted party vetting my software repos. It's why I even use Ubuntu because I trust Canonical to make some sane decisions when vetting their repositories.
You give multiple repository support and suddenly users have to one find a way to add another repo, and second there is no way of removing software from those repositories if they do end up malicious.
Which is why I brought up the webupd8 java instance having root access to thousands of machines.
>users can optionally add more repositories if they choose to do so.
Ubuntu is the version of Linux designed to be used by your grandmother. They want to make it as easy as possible for users to install trusted/safe software from both proprietary/free vendors.
It's kind of telling that Mozilla/Microsoft/Spotify/Jetbrains released software as a snap long before it is even possible on flatpak but nevermind that. I don't think you can even get VSCode, Spotify or Intellij on Flatpak.
Second what you describe as a defect. There being multiple sources of software is a plus it means the power is in the hands of the user to decide whom to trust. What you don't want is a situation where people must configure additional sources just to have commonly needed software. The example you provide about the Java PPA is apt, pun intended, ideally commonly required software would be provided by the vendor instead of siloed in a third party source. Of course the vendor and the license must make this possible.
Launchpad has a weird user experience and was for a long time too much focussed on bazaar when git won.
At work we used bazaar and lp for a while, but still I always have to search for the right path for getting to a project's code. The bug tracker was more useful than GitHub's but that didn't help ...
Aside from that there are the legal implications of AfferoGPL which prevent many people from touching it.
But yes, doing infrastructures is hard. I however don't know how complicated hosting is and how well it's packaged. For software starting for in-house use this often is a mess ...
I posit that this doesn't matter.
Presumably Ubuntu's infrastructure should be open source so that it can be inspected if necessary, for security reasons. It shouldn't matter if nobody else is actually hosting an alternative copy... it is still important that their copy be open source.
Operationally:
- I can trivially host and control my own apt repository, either as a mirror of some upstream repository, or with bespoke packages.
- I can't do the same with snaps.
So launchpad and snap store isn't quite apples-to-apples. It would help of course if a snap store could be statically hosted or re-implemented, but the full API is quite complex.
I just think it's weird that a supposedly open source company like Canonical would build close source infrastructure. Like, just develop it in the open to begin with?
I understand that some complex interconnected ball-of-spaghetti of microservices makes little sense to open-source, b/c no-one can run it.
But that is essentially saying: we never wanted people to run it themselves, and now we are at a point that no-one can run it, so why bother?
For years it has been recommended as the mechanism for installing Java on Ubuntu installs.
The problem is that the snap store is managed by Ubuntu without any community oversight.
By not releasing source code to the store, other distributions cannot create their own.
These are the reasons what is holding snap back for broader adoption.
That is already the case for most repos/launchpad on Ubuntu but people don't really have too much problems with that.
>By not releasing source code to the store, other distributions cannot create their own.
Other distributions wouldn't because the operational cost of operating it is too high.
>These are the reasons what is holding snap back for broader adoption.
Snap isn't being held back by adoption. It has more first party publisher support and more installs.
Ok, so the whole technology is irrelevant and should not be used then.
> Canonical already spent a large amount of investment opensourcing launchpad
Why develop it as non-open-source to begin with?
> Namely that it would be expensive to open source it with little benefit in return.
I don't think that's the real reason; I think it's that Canonical wants to maintain control. Their dream of being the App Store of linux isn't working out.
> Canonical already spent a large amount of investment opensourcing launchpad
If their development practices make open-source development expensive, that's Canonical's problem, not anyone else's. Nobody else uses Launchpad because Launchpad is not a compelling platform. It's still tied to bazaar, which frankly lost the version-control wars. Treating git as a second-class citizen is not how to engender contributors.
> Snap store specifically from what I gather is a bunch of operational machinery that doesn't make sense without also operating launchpad.
Another example of having to choose: did Canonical engineer themselves into a corner, causing all of Launchpad to become technical debt from under which Snap cannot escape? Or was it a deliberate business decision to try to maintain control of the store? An affirmative conclusion in either case doesn't look good for Snap.
> 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.
Users pretty clearly do not want this. Many people use Ubuntu expressly because of the PPA system; I'd argue that it directly caused Fedora's COPR system to exist because of the user demand. There's no mandate that PPA installation require command-line configuration; it would be trivial to create a bespoke per-PPA using e.g. Vala. Synaptic already allows configuration of PPAs via GUI. It's total non-issue.
> That and the whole aspects of malware/trust goes out the window.
They're already out the window. Snap packages are not reviewed for content and anyone can just cram software into it from random GitHub repositories. Wouldn't it be nice if it were possible to set up a 'curated' Snap store with strong promises of software quality and review? We can't, because it's apparently too hard to run. Another drag on Snap.
I'll not bother to respond to the whataboutism regarding PPAs. Literally the only difference between "a giant PPA that Canonical hosts" and the Snap store is that anyone can upload to the Snap store.
None of the problems Snap store purports to solve are compelling, so these explanations don't really further the cause.
Agreed. This is one feature of Ubuntu I miss sorely after leaving it behind for other distros.
Red herring. The Linux Mint teams' main complaints have to do with issues around the way snap wrests control from the user.
>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.
Imagine strawman-ing this hard.
Like Linux Mint is doing the same? There is no control being lost by using Ubuntu versus Mint. I could remove snapd there without people making that decision for me.
Worse would be Mint's decision of removing the only FOSS built version of chromium without offering an alternative in place. Canonical only installed the chromium snap because they did not have the resources to support a deb version instead.
>Imagine strawman-ing this hard.
It isn't a strawman. It is precisely what their reasoning was and it makes perfect sense. The snap store has already seen people attempt to install cryptominers. There is no way in Flatpak of banning known malicious flathub repos.
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.
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. snap seems to spew traces of itself all over the place on an Ubuntu install, and it's less than clear why any of them are there.
The same thing with phones. Smart phones are good at a lot of things, but they are mediocre as a telephone.
No, just roll on with it.
There was a period of time, around 2010-2015 when I really felt that computers were fast. SSDs were getting more affordable and that was a huge improvement, every action was immediately responsive. In 2020, that has somehow been undone. It takes 5 seconds to launch a calculator. Software guys really like to undo all the advances that the hardware guys are doing.
I guess people at MS test and quality departments use I7 with an SSD driver. If so, it's bad. If not it's simply hard to understand, if we leave corporate politics aside.
To me, the calculator has always been more or less OK, but the Image Viewer is a clusterfuck.
With the old viewer, it's almost instantanious opening by clicking a file in windows explorer. The new one is slow as a crawl. The first time may take 5 or 6 seconds (in a 7 year old laptop). The next time is down to 2 or 3. Compare that to milliseconds using the native app. I've never felt the need to use an specific image viewer, but now I'm happy with Irfanview, as fast as the old app, and full of features.
How do such things pass triage stages?
I now switched to xcalc. gnome-calculator is better, honestly, but it's not worth feeling in the 90ies.
> 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.
The capability is necessary because snaps can also ship proprietary software (eg. Spotify, Skype, etc). So one wouldn't expect this to be a property of (binary) snaps, just as it isn't for binary debs. apt/deb comes with "source package building tooling" (dpkg-source, dpkg-buildpackage, policy around debian/rules, etc) and so do snaps (snapcraft).
I understand why there's consternation about usability (and a steady stream of requests focused on helping novices get it up and running), but I'm not sure the project(s)/ecosystem are ready for the stress of getting strapped to a growth rocket that brings in many new non-developer general-computing users who can't reasonably contribute back.
I don't mean this in an elitist RTFM way. More users of any stripe just inevitably exert support pressure in all sorts of directions. The community is perpetually iterating on tools/automation/process issues to try and stay on the right side of the wave. I sympathize with everyone who has a tough time finding their legs, but for the near term I think it is probably a net good if ergonomics issues filter out people for whom most distros are effectively fungible.
BTW most people don't need to write a full-fledged "script" to get their system up and running. All they need to specify are some configuration variables that specifies the sort of things you'd need to specify anyways if you're going to setup a new system, like which packages should be installed. With NixOS, you write those things on a file instead of typing it on the command line.
I think Nix/Guix is going to be the bridge to the post-POSIX world where we can move away from the trend of a globally visible filesystem and into much stronger container-based approach. But it can't be in its current form; the Nix language and Guix's Guile/Scheme are too difficult and not declarative enough.
So don't lose that. Use Debian (or Devuan), or one of its properly-FOSS derivative distributions.
You don't get that for a lot of third party apt repos actually, no deb-src repo.
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":
$ sudo execsnoop.bt
Attaching 2 probes...
TIME(ms) PID ARGS
7603 29266 kubectl config current-context
7612 29272 /usr/sbin/apparmor_parser --preprocess
7614 29266 kubectl config current-context
7626 29280 /snap/core/9436/usr/lib/snapd/snap-seccomp version-info
7630 29266 /snap/core/9436/usr/lib/snapd/snap-confine --classic snap.kubectl.kubectl /snap/core/9436/usr/lib/snapd/snap-exec kubectl config current-context
7632 29266 /snap/core/9436/usr/lib/snapd/snap-exec kubectl config current-context
7634 29266 /snap/kubectl/1561/command-kubectl.wrapper config current-context
7635 29266 /snap/kubectl/1561/kubectl config current-context
Blame repo culture. In saner worlds there is no requirement for a middle man between developer and user, so users get the software when the developer releases it to them. For various reasons (only a few of which are technical), Linux has settled on this middelmen-everywhere way of doing things, and because it is FOSS all those middlemen are also volunteers, and then to top it all off there are dozens of repos and packaging formats.
AppImage (and its predecessors) have been valiantly struggling to undo this cultural brain damage.
I really don't want 187 system vulnerabilities from 12 apps which use different versions of different outdated libraries.
BSD ports had it before. And before that, Irix machines had the packages split in several CDs.
Or for that matter, regular old Debian probably has 99% of what you need.
There's a reason Arch is so famous and a meme: installation is a challenging weekend project if you've never done it, but it's the most stable distribution with the sanest ecosystem (AUR, sane defaults like systemd, fastest package manager, rolling releases, packages are kept as close to upstream as possible).
Once you go Arch you probably won't go back and you will just grow the meme further.
Can't you simply opt out of using snaps and keep using .deb with Ubuntu, no matter what Canonical is pushing as their preferred distribution?
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.
I've harbored this suspicion of GNOME developers for years. It honestly wouldn't surprise me if a lot of Canonical devs don't use Ubuntu at home.
https://bugs.launchpad.net/snappy/+bug/1620771
https://forum.snapcraft.io/t/how-can-i-use-snap-when-i-dont-...
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.
There is a negative sentiment around snap packages. Even if you are an experienced Linux user, you fall into that negative sentiment and even if an issue is small, it is a deal-breaker for you.
The "chromium" issue has been explained in 2019. Ubuntu 20.04 does not plan to package "chromium" as a deb package (too difficult to maintain properly), therefore there was a need for a backup plan if users were trying to install it.
I don't think that's fair. Apt/deb is solid, battle tested, and works. Introducing snap with this kind of instability is the source of the negativity.
> The "chromium" issue has been explained in 2019.
And the fact that it still crashes in 2020, on a flagship package on a modern laptop, is really really bad. In fact I had the same crash happen during a dist-upgrade on another laptop(!) which locked up the entire dist-upgrade.
If apt is going to call snap, it needs to be rock solid.
See "refresh.retain" from https://snapcraft.io/docs/keeping-snaps-up-to-date - the point is that you can revert an update instantly.
I'm curious, what "Canonical-oriented" features are you referring to? (besides snap)
After the move to Gnome, I've found Ubuntu to be less and less "Canonical-oriented"... which is good
Especially if the people authoring the do-release-upgrade scripts weren't aware of this being a hot-button issue.
What is the cleanest way of ditch the snap system and its preinstalled apps? I'm assuming this won't break anything important.
PS: I'm not planning on installing 20.04 any time soon. At least not until the dust really settles. I don't see the point of running the absolutely latest version until there is a strong, evidence-backed consensus on its strong and weak points.
I personally don't see the issue with using Ubuntu as a base, _if_ you remove all of the offensive bits. iirc one of the Pop!_OS dev's was asked if they were going to rebase on Debian. The response was something akin to "We already change everything on the end user facing side, so there's not really a need."
I'm so sick of the app store model. The app stores usurp control of distribution from developers which adds risk which reduces willingness to invest and the result is that app stores attract low effort, low value apps unless they're coming from a huge company. Everyone loses except the app store owners, big platforms like Facebook and Spotify, and spammers / scammers.
The app store model is one of the worst things to happen to tech in my lifetime.
That is, create your snap package and publish it on the Snap Store. Do not request to pre-approve any permissions. Arrange with your users to enable those permissions on demand.
The only reason to go on that forum is to ask for automatic permissions. If you do not do that, then it's your users who have to give you that permission.
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.
This is a mischaracterization. "chromium-browser" is a transitional package that installs the chromium snap for one reason: it is to provide an upgrade path for users of Chromium in previous Ubuntu releases to the latest Ubuntu release without breaking Chromium.
I use an example of where Debian does the same thing: on the latest Debian release, install "mysql-server" and you'll get MariaDB, not MySQL. Granted this doesn't bridge across from a deb to a snap, but the mechanism is the same and the technical reasoning is the same. It is to stop users from ending up with a regression in available software following an upgrade.
There is no "to make it some "universal installer"" going on here.
You may not like the decision, but please do not make it out to be for reasons that do not exist - at least without providing the facts to allow readers to decide for themselves.
(I work for Canonical but don't work in an area related to the Chromium snap, Snap Store, this decision, etc. I speak for myself, and not Canonical).
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.
In case you didn't know, check out the workspaces feature, it can make managing lots of windows much easier via the keyboard:
- Change Workspace: ctrl + alt + up/down
- Move Window to Workspace: ctrl + alt + shift + up/down
You can lock a workspace to a particular monitor too, while cycling other monitors
I don't use Pop!_OS, but I recommend Plasma.
It says so on the description directly next to the name: "Transitional package - chromium-browser -> chromium snap"
There only for people upgrading, so they are not suddenly surprised seeing their browser gone.
For Ubuntu 20.04, it has been explained (in 2019!) that Chromium will be only available as a snap package. To help users transition, the command `sudo apt install chromium-browser` would install the snap package. It is better than "package not found".
It is so simple, but if you are stuck in a negative sentiment on snaps (read this thread), you get crazy.
Any suggestions on what’s a good alternative distributor go with that is widely supported and easily available on the variety of cloud platforms?
To have relatively up to date software without running unstable?
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.
df -h | grep -v /snap
alias df='df --exclude-type=tmpfs --exclude-type=devtmpfs --exclude-type=squashfs'And my strong belief, is Microsoft is going to eat Linux Desktop. WSL to run your server apps and coding environment. windows for user apps. as someone who hasn't used windows in over 10 years, day by day seems windows is gonna be the future. sad to say, but true.
A common misconception about the FOSS ecosystem is that many similar projects is "wasted effort". In reality, diversity is what allows for progress and flexibility. Otherwise you end up with a single package manager which nobody can change AKA mono-culture.
> "Microsoft is going to eat Linux Desktop. WSL to run your server apps and coding environment. "
Only if Microsoft make their OS free, otherwise you're buying windows to run a translation layer of Linux (WSL) on top of it... doesn't make sense to a lot of people...
(Replying here because your comment I quoted above is dead! Vouching didn't help. Must have made someone mad.)
I don't believe the very few sites (mostly work related) I use chromium with have adsense, but it is possible here and there.
Is Ubuntu considered difficult to install? Does it not support older hardware as well as Mint? Wouldn't Ubuntu be more supported if they just ended Mint and jumped aboard?
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.
> 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.
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.
> 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.
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.
A week or so later, I guess the snap package auto-updated itself, because my go installation broke with an error about how the go tool version no longer matches the currently running version of go.
That pretty much ruined Snap in my mind, particularly for system software.
And snap is bad not just because you can't patch, or pin, or set up a snap mirror etc. The whole concept is bad.
That
There is also the issue of dependencies, and there is some elegance in the design philosophy of "package everything for a program and install it standalone" vs. having shared libraries.
So I see the benefit in an app-store. Someone below said "snap is horrible" because it's lock in. It isn't! Ubuntu hasn't taken away apt.
But simple, easy package distribution to nontechnical users, for the benefit of stability and ease of use, is a noble one.
Given up trying to compile VLC thanks to usual the usual python mess (ImportError: No module named 'nasm')
VLC don't bother distributing debs any more, just these shit snaps.
In years gone by distributions used to do a good job of keeping systems healthy.
They no longer seem to care about the old way of doing that though, things like debs and make just aren't cool any more. Instead you have 160 different package managers all fighting each other, which you then install to update your build environment to install another package manager to build a new build system to eventually dig down to generate some shitty python crap which runs a gcc command.
I don't have any issues with this behavior. I find it really annoying when I find a package I am looking for on apt and install it, only to realize that it's way out of date, and I'm supposed to install it via snap or some other means to get a reasonably up to date version. Pointing apt at the snap store is a nice convenience in my opinion.
It's a snap. instead of just launching a stupid binary (it's a f-ing calculator for christ's sake) somebody decided it was better to use a snap, mount a filesystem, add a cgroup and everything.
For me that was the last straw: I eradicated all the snaps in my system, uninstalled snapd and everything gnome-related that I could. Jesus christ.
Again, it's a f-cking calculator.
I don't need a snap for that.
That's what get people hating snaps.
For the record, I'm now using xcalc. It's less pretty but it starts IMMEDIATELY.
However, here on HackerNews i've seen many articles about how "flatpak is dangerous" lately. Is there any real concern? If yes, what would be another option? Appimages? I definitely don't want to rely on snaps now...
The conversation around snaps starts at 5:20.
It sounded to me that they genuinely tried to put themselves in both side's shoes.
Source: The Ubuntu podcast Telegram channel
> When Flatpak came out it immediately allowed anyone to create stores. The Flatpak client can talk to multiple stores. Spotify is on Flathub and they can push towards it. If tomorrow they have an argument with Flathub they can create their own store and the very same Flatpak client will still work with it. When Snap came out, it was only a client. The server was behind closed doors and the client couldn’t talk to multiple servers.
and
> Ubuntu is planning to replace the Chromium repository package with an empty package which installs the Chromium snap. In other words, as you install APT updates, Snap becomes a requirement for you to continue to use Chromium and installs itself behind your back.
Yea that seems to me to be a problem.
From the June 1st Mint blog post: https://blog.linuxmint.com/?p=3906
> ...in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. 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.
If I'm reading this right, Snap is basically trying to fix the problem of software dependencies on older packages by bundling things together (a la flatpack)... but it ALSO replaces the various repositories in different distributions of linux with a closed-source, centralized repository that points towards cannonical, and advertises ubuntu to people using other distros and potentially gives cannonical control over the distribution of sotfware in the linux ecosystem. AND it can do this behind the scenes without the knowledge of the users, who may think they're still using their normal repo system.
The whole scheme seems completely antithetical to the principles of FOSS. You don't have to go full Stallman to see this as a bad thing IMO. From that perspective, Mint's decision to drop support for Snap makes a LOT of sense.
Also, one of the reasons I enjoy running linux (I dual-boot with windows) is that it does what I tell it to do, and ONLY what I tell it to do. There's no BS like Cortana auto-installing or onedrive automatically uploading a bunch of my pictures to the cloud (yes that actually happened). I already have a linux distro that takes that benefit away, but I accept that (for now), because it's a phone. I'm not ok with losing that on my desktop.
Also by `df` and `mount` are unusable with this stuff.
0: https://lobste.rs/s/aktv9k/problem_ubuntu_20_04_snaps_where_...
I've used Ubuntu since 2014 and have been impressed at most of the decisions they've made, mainly:
- [1] Sticking to 6 month release cycles. Any features not ready, go into the next release. (Windows copied this, but constantly miss release dates)
- [2] Trying Unification of all applications, across desktop and mobile OS. But abandoning the project when it became clear it wasn't working.
- [3] Trying their own desktop manager Unity, then abandoning it when everyone was complaining and focusing on better Gnome integration.
I especially like how they try developing a technology and if it's not working or being adopted/liked, then it's abandoned by the core team... which is better than focusing on hated/dead technology...
[1] https://ubuntu.com/about/release-cycle
[2] https://www.bbc.com/news/technology-39490848
[3] https://arstechnica.com/information-technology/2018/05/ubunt...