Since 16.04, Snaps have been a huge pain for me with running LXC in production environments.
By default, Snap applies updates and restarts Systemd services anytime it likes, and there's no way to turn this behavior off! The only way to get around it is to download the Snap package binary and install that directly. Then Snap won't "know" where to get updates.
(Caveat emptor: "Workarounds" like this can easily lead to a bad security scenario, since any critical security patches won't be installed by any standard system update process)
Did I mention that a fair percentage of the time the Snap updates would leave LXC in a completely broken state? In production (and development, too)!
The final nail in the coffin in this scenario comes in the form of Snap being the official recommended way to install LXC. I don't know if Stéphane and friends even publish Debian packages anymore.
I get the idea behind snap and appreciate it, but the lack of configurability and no clear definition of what stable really even means . . .
1. prevent machines in the fleet from pulling the broken LXD update
2. rollback broken machines to the previously working LXD version on the same channel, since it no longer existed in the Snap Store™.
What a joke! Now we're burnt on snap _and_ LXD.
Some developers are trying to package for Debian. The work is in progress at https://wiki.debian.org/LXD
The following distributions package LXD (that I know of):
* Void Linux
* Alpine Linux
* Arch Linux
Some of those are more suitable for production installs than others, but if you know what you are doing and manage your deployments well, all of them could work.
I've been looking into .deb packaging for Caddy but it really feels like they require us to jump through too many hoops to make it happen. I'd much rather just ship a prebuilt binary.
Security. Dynamically linking stuff is always going to be better than statically linking. Do you trust upstream to keep track of security issues and rebuild in the absurd dependency tree that is Golang software? Or the multi-year old effort which is the current Debian security team?
The reason why it's absurdly complicated is solely on the Golang team, not Debian.
It's clearly not production stuff, but it works very well for a quick test bed before production deployments.
I really have no idea what people are thinking sometimes.
The automatic startup of newly installed services (before you even have the opportunity to configure them) on Debian (and derivatives) has always bothered me and is a (small) factor in my decision.
Fortunately, there are a few "workarounds" to prevent newly installed services from being automatically started!
First, there's the brute-force / heavy-handed approach -- override the systemd presets  to set all services to disabled by default:
$ cat /etc/systemd/system-preset/00-disable-all-services.preset
$ ln -s /dev/null /etc/systemd/system/nginx.service
$ apt install nginx
# ... configure nginx as desired ...
$ systemctl enable nginx
$ systemctl start nginx
(I'd recommend avoiding the latter entirely and going with whichever of the first two options better suits your needs.)
EDIT: Just remembered another method but I'm not sure if it still works:
$ RUNLEVEL=1 apt install nginx
A cultural acceptance of WIP software seems common, in free software communities, in my experience.
On the one hand, yeah it's harder to complain when something is only built in someone's spare time for free. On the other hand... is non-FOSS really any better? Has Windows yet managed to re-merge the old and new control panels?
The first is a fact of life. The second is bad judgement.
Even if people should be updating regularly, forcing them feels completely antithetical to the Linux ethos of users having control over their devices.
Since 2017: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053
I feel bad for the maintainers; it must be difficult to deal with all the rude and borderline disrespectful comments -- and particularly for something you're donating your time for free after all. But I must say that the architectural decision of creating a ~/snap was a colossal mistake.
It's not an argument. It's freeness is a completely irrelevant property.
I am on the rolling releases already but I'm not going to install an LTS version that is so deeply integrated with the distributor while at the same time ignores the directory standards so incredible blatantly.
I think the (not that bad) manual installation process might keep some folks from installing it, but it makes you learn to choose from the very beginning.
After the initial install, update it on your schedule, and install things as you decide they are needed.
Ubuntu is the opposite -- install the world, then go madly trying to disable and remove the phone-home, forced-update, bloat.
I'll also admit that I can't for the life of me get Arch to properly install with all the tools and features that are normally built-in to desktop environments to work on first boot. I'm sure I can make it work if I give it another try now that I've gotten more used to using Manjaro, but the Arch installation experience is not something I want to go through again any time soon.
I understand that most Arch users will want to decide exactly how they set up their system and all, but for my personal (non-work) machine I just want an operating system that works, allows me to mess with the standard Linux stuff and manages to install itself without me holding its hand. I'd much rather tick a box that says "enable full disk encryption" than manually configure cryptsetup and LUKS parameters. It's just too much effort for what I get out of it.
Ubuntu users may be more tech proficient than average users but even for developer machines, I think it takes a lot of concern out of the equation if the software is up-to-date.
As far as I'm concerned this doesn't deserve an '/s'.
With Ubuntu I just wait until the next LTS.
Due to LXC now being a snap, the file is simply not there.
I guess it's 5 layers deep in namespaces, overlayfs and other stuff.
I was so fed up with this that I removed Ubuntu (and replaced it with Gentoo).
I can't understand why they would break such fundamental thing and seemingly don't care about it.
(Same-but-different for enforcing non-interactive mode on installs.)
The idea with LTS is to be predictable and stable.
Put another way:
- desktop people want ALL UPDATES NOW.
- server people want NOTHING TO CHANGE EVER.
(yes, not exactly that, but kind of)
It is a seriously difficult thing to get right. I always applaud people to take on difficult problems and try to solve them, but I would not expect it to have any sort of robustness for another 5 years at least.
Dear snap developers, don’t make false assumptions that every user in Linux has to have home directory as /home/username just because standard Ubuntu installer does this. Only thing that you should care about here is $HOME
I uninstalled it on all my Ubuntu systems and put it on hold. No new Ubuntu installs, switched to Debian.
I think I am going to have to start figuring out a plan to migrate them all over to RHEL...
I don't know how must be installed on your version, but on 19.10, snap can be completely removed: the only draw back is that pulseaudio depends on it, but I guess that for a server it's not that much of a problem.
For context: https://forum.snapcraft.io/t/disabling-automatic-refresh-for...
Snap developer responses are hilarious. No matter what your use case is, Snap developers know better than you, you silly irresponsible sysadmin/user. Snap is basically just another App store.
I actually really like snaps and that's the only bad experience I've had. I don't know why LXC would come in that form, very weird.
Snaps break debain's stable release model. They allow upstream to ship updates outside of the normal 6 month ubuntu releases. There are times when you might want this, but it should be opt in not mandatory. I thinking specifically of lxd which is only shipped via snaps.
The snap store's trust model is confusing. Its hard to tell who is making the packages and how they are sandboxed. If I'm going to install a proprietary piece of software I want to know exactly what it can and can't do. Lately I've been using firejail when I need to run things like this.
And now for a minor complaint that also feels most user hostile to me: why do the snap developers think its ok to require a non hidden directory in $HOME? Seriously my home directory is MINE, if you have to store application state there at least have the decency to do it in a hidden directory.
4 years old now.
The actual heritage is when `ls` was written to exclude .. (dot dot) directories from it's listing the code literally just had the logic to exclude any files which had a dot/period as its first character. Later operators exploited that bug/feature to create items with a dot prefix to make those files and folders hidden. Eventually this became convention.
Whereas systems released more recently understood the need to have a hidden file attribute so made it a first class property.
I do love POSIX and often the first to defend some of Linux or BSDs idiosyncrasies but if there was ever anything that was worth someone saying "I know we've always done it this way but it's shit and it's about time we implemented a proper solution", it would be the dot prefix kludge. (I also know it's easier said than done and would take years for all the tooling to catch up)
I have still been using `snap` for the past year, and have mostly been happy with it. It works well for apps like `spotify` and `zotero`, it's a better solution than `ppa` for third-party software, and I like that it tries to introduce a permission model. But not following the dotfile convention is annoying, and not prioritizing a search-and-replace of `~/snap` to e.g. `~/.snap` in the code after four years is strange when this is their most upvoted bug.
Of course you do have system files, which are hidden from all standard folder listings, but aren't usually used by software, presumably because they're too damn difficult to find again (although I really hope google drive realizes at some point that desktop.ini is supposed to be a system file, not merely hidden).
.NET has its own set which is also very old and goes back to .NET 1.0 (as old as Win98) https://docs.microsoft.com/en-us/dotnet/api/system.environme...
(That said, I would still prefer that they not be.)
In fairness, I think that's the point, just like RHEL streams.
> There are times when you might want this, but it should be opt in not mandatory. I thinking specifically of lxd which is only shipped via snaps.
Yeah, decent idea, poor execution. Especially for system/infrastructure software like LXD. I want a stable kernel, a stable glibc, a stable LXD/Docker/k8s/whatever, and then on top, bleeding-edge applications that will not break the world if they autoupdate at random to a less-tested version.
After fighting with node, vlc and ffmpeg snaps not working reliably, I had to add a warning for my PhotoStructure users on Ubuntu to avoid those packages (and how to install them via apt).
I agree with a bunch of people here: snap promises some great features, but in practice the horrible performance, additional resource consumption, and spotty reliability led to me actively avoiding snap packages and looking for an alternative installation.
Applications need a place to save state, and you don't really want it to be hidden, because sometimes I as a user do need to change it manually for any number of obscure reasons. So you make a subfolder that's designated for apps to write to.
There's no good way to put this into the existing Linux model though. All you'd do is add yet another standard a la https://xkcd.com/927/
Especially when a . is used to make the directory hidden, because I can't unhide that specific directory without changing the name apps expect.
I get into the Library folder by doing: cmd-shift-g -> ~/Library -> enter
In Catalina, it's now Cmd-shift-fn-.
$ ln -s .hidden not_hidden
It's that easy. Really.
I'm being picky, I know! But I still think the Library approach is cleaner. (Again, back when it wasn't hidden by default!)
This model is terrible. OS asks up-front: program wants permissions to do A, B, C, X, Y, Z: grant/refuse? You the user decide that the program should not be allowed to do X, so you refuse. Now the program will not run at all.
That's about the worst design possible. A 10 year old can brainstorm a better design within a few minutes.
Investigate prior art:
man 7 apparmor
man 4 capsicum
man 2 pledge
In practice, apps that want access to my contacts usually keep asking for access every time I try to do anything, until I eventually either relent to make the prompts go away or click allow by accident.
And that's me as a computer-enthusiast. I would bet money most normal people just hit allow always. Because it's easier.
Some apps even try to circumvent this system by showing a "help" screen with instructions on how to re-enable the permission manually, but I only saw this twice.
Still, this is not practical enough. A true user-centric strategy would be to offer "mock-permissions" to an app, so that if an app says that it needs to read your home dir, you grant mock permission to the app, and it sees an empty home dir, not yours. From the point of view of the app, it should be impossible to know if it has been granted the real permission or just a mock permission.
People still just click "allow" on everything. They get tired of getting questions asked, and just want the program to work, so they don't even read anything and just tap tap tap until it lets them through.
Access your files? Sure. Access your documents? Whatever. Send data off to our corporate data vacuum? Whatever, I need to see what my face will look like with an AR moustache!
Also, are you running Catan as root or something? How is it able to compromise your whole system?
The latest snap I had to get rid of was Visual Studio Code, because I was trying to work on an open source game with it, and I found out that if I launched the game from inside Visual Studio Code, my game wouldn't play sounds because it couldn't communicate with PulseAudio, and attempting to use ALSA just straight up gave me an error.
On the other hand, I've only had positive experiences with AppImage. Gives you an all-in-one image that you can directly execute if you like, and no sandboxing nonsense.
> Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
Both AppImage and Firejail do one thing and do it well, you can easily combine both and get what you want.
I had run it via X11Forwarding (I had a contusion and used a puny laptop to connect to my desktop) and it was not a smooth ride, so it's not an entirely representative experience, but it shows that it's not all painless, yet.
I realize I have to soon upgrade from Ubuntu 16.04, so a while ago I installed 19.10 to see what to roughly expect from 20.04, as there are quite a few changes. Trying things out, I installed VS Code from the Ubuntu Store; I was quite disappointed to see things going south right on the Welcome page, as the snap version of vscode couldn't even open a web browser (instead, Firefox promptly crashed every time).
Of course, being able to open a web browser from VS Code isn't a necessity, but for some reason for me it just seemed like the install was rather broken by default, and surely almost no one could have used it much not to notice a simple thing like that right away – and the thought that even if the problem was noticed and simply shrugged at didn't really make me want to see what else did not work.
I expect you needed to do something like that for the VS Code snap.
The snap thing is a pain in the ass. I understand the need for something like snap or flatpak. I had software too new or too old that wouldn't work because some dependencies were not updated or were too new. Snaps can solve that by allowing the developers to provide everything you need (or everything you need that is not on your system). But why would I want a snap calculator or a snap system monitor? On 19.04 it would take a couple seconds to open the calculator...thank god they reverted those apps as normal packages.
Now I feel like I felt on Windows when I had to be extra careful installing software in case somethign weird came in the installer. What kind of package is this? Is it a snap? Can I install the normal package? Is the snap provided by someone trustworthy?
I also had to install Unity. Gnome lacks support for multiple monitors. Some stuff like the dash working only on the main monitor breaks completely my workflow. Almost for every action I want to make I have to change my focus to the main monitor.
Yes, applications remember which monitor and even location on the monitor they were last at.
I'll probably give Budgie a go.
On Unity it opens on the monitor you're focusing.
Sometimes it's a bit tricky. Let's say you're focusing on a Window on your main monitor but your mouse cursor is in the secondary monitor. If you hit the meta key, the menu will show on the secondary monitor. Now, if you open an application without using your mouse it'll open on your main monitor, where you had the focused window but if you click on the app it'll open on the secondary monitor because the click changes the focus.
Some stuff is not as polished as it should be but if we take in consideration that Unity has been abandoned for 4 years and before that it wasn't developed at all as all the effort was put into Unity8, I'd say it's a pretty damn good DE.
I hated it when it came out but now I can't live without it.
To be fair, my Thinkpad from work is the first laptop that has issues with when (dis)connecting a screen. When disconnecting I need to turn on the laptop screen before disconnecting; for connecting I can usually log in without screen and use Super+P to switch modes and that fixes it.
But other than this first instance, I never heard of this being an issue and people here talk about it as if it's commonplace. I must have used or seen Linux used on at least 30 laptops with 2 (or more) screens without issue in the last ~10 years, counting the ones at my previous employer as one because they were all the same hardware even if people ran different distributions.
/var/snap is a subvolume. Purging snapd wants to remove the /var/snap directory, but it being mounted subvolume, it will fail. Purging snapd will therefore also fail.
Destroy (-r) the /var/snap subvolume before apt purge snapd.
Similarly, if using flatpak, create a new subvolume for /var/lib/flatpak before installing the first one. You don't need to snapshot your flatpaks together with the /.
This is needed because an every growing number op packages is "dependant" on it.
Here I show how to install Chromium as a DEB package from Debian (on a buntu):
I'm not against stuff changing, but tell us up front, explain what's changed and make sure that you're not breaking existing things or provide a way for people to keep their existing stuff work, a flag that says that following symbolic links is OK ... and put that UI in Chromium itself, not in some other box somewhere
I despise the bug, it causes so much trouble without a way to turn it off. Plus the switch to snap happened exactly during a critical vuln which meant people were running on critically vulnerable chromium for weeks.
A workound is posted at https://bugs.launchpad.net/snapd/+bug/1776873/comments/29 (simple patch & recompile). May be worth making a PPA for the fixed snapd if we can't get the Canonical dev team to fix the core issue.
It's extremely weird to see this kind of thing when it happens too, you usually trust Firefox to work!
I prefer the isolation of snaps so I’m willing to put a little work into it, but understand not everyone cares to do that.
It also causes data loss: https://bugs.launchpad.net/snapd/+bug/1616650
I have been using Xubuntu 20.04 for several weeks and it has worked well. Because that's a high end laptop I have not bothered to uninstall snap yet, although that has been on my mind.
I am surprised that the article writes there are snaps installed by default. Checking in Xubuntu 20.04 that's luckily not the case
$ snap list
No snaps are installed yet. Try 'snap install hello-world'.
$ apt show chromium-browser
Pre-Depends: debconf, snapd
Description: Transitional package - chromium-browser -> chromium snap
This is a transitional dummy package. It can safely be removed.
chromium-browser is now replaced by the chromium snap.
Because hearing things like `sudo apt install chromium` actually aliases to using snap is disconcerting to say the least if true.
But I'd like to throw in a recommendation for Fedora. It includes Flatpak by default (which to me as always been the least objectionable sandboxing system) but nothing comes as a flatpak by default. You have to explicitly choose to use it.
Fedora's hardware support is second to none, and even supports in-OS BIOS updates.
I highly recommend it.
However, if you want to use chromium-browser you are out of luck. It is no longer available as a .deb package.
What is "performant" supposed to mean here?
Is Flatpak faster than Snap? more compact? simpler? more reliable/secure? easier to use? more efficient in terms of cpu/memory/communication/power/etc.? all of the above?
Snap suffers from the overhead of having to decompress a squashfs on program launch: https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-...
My experimetsn on the same laptop showed that..
Launching Skype installed from deb is almost instant.
From snap it takes around 10sec to get anything to show.
This is on quite fast nvme disk.
Yes, Flatpak is just bind mounts and namespaces. It doesn't have the overhead of the squashfs images.
I really hate Snap/Flatpak conceptually. Use the package manager. That's what it's there for. FPM is a way to make package building easier.
Snap/Flat tools feel like they're about the same as Electron cancer; and I bet we'll see more closed source commercial stuff pushed to the Linux world via them as well.
By the way, what is it with Docker that makes it hard or impossible for it to be used for this exact purpose?
It doesn’t “suck,” and many of the ideas are compelling. But, the design and implementations could be better. I was interested in rkt until it was acqui-abandoned.
It's also disingenuous to suggest a browser wrapped in a cryptocurrency promotional wallet thing as a comparable alternative.
Sure, but some people just want to have their problem fixed and they only have a sledgehammer in front of them. If it works, is it really that bad?
> a browser wrapped in a cryptocurrency promotional wallet thing
I think you have it the wrong way around. It's a browser containing an integration with a cryptocurrency wallet, not the other way around. You'd still be able to use it as a normal browser if you ignore the cryptocurrency stuff.
They give the suggestion to remove via
sudo rm -rf /var/cache/snapd/ && sudo apt autoremove --purge snapd && rm -fr ~/snap
sudo bash -c "cat > /etc/apt/preferences.d/no-snapd.pref" << EOL
Pin: origin ""
So shortly after the Mir fiasco, why does Canonical feel it necessary to come up with the next dumb idea?
Other than that, I do not think other packages are affected.
My only con is that the defaults update all snaps like every day, and I really would like to have better control on that, because I'm always on mobile data.
No startup slowness, and you'll still get the vendor-provided updates as they're released.
tl;dr -> HashiCorp's various tools exist as snaps but none are published by HashiCorp. All are out of date. Some have incorrect metadata. Few provide any clue as to who or where the upstream is. There's usually not even a way to contact the snap author to submit patches or ask for an upstream link. eg https://snapcraft.io/nomad
There is a level of care here which I think is great. Some engineer somewhere made sure that the system would still work without snaps. This is a very Debian attitude which Ubuntu inherits from and which I would like to celebrate for a bit :-)
It seems that canonical does best when they embrace the ecosystem and not try to replace it.
Canonical cannot be accused of NIH for Upstart, it was a widely adopted clean init system at the time and made many distro's boot times great again. Service configuration files were also very easy and clean.
Unity was a desktop environment that both was liked by many people and reused many components from Gnome, I don't really see a problem here.
A point could be made for Mir.
So it's wrong to say Canonical is guilty of NIH-syndrome with these two items, when their versions were out first.
Whether the tech is any good is another matter.
According to https://en.wikipedia.org/wiki/Snappy_(package_manager), Snap was publicly revealed on 9 December 2014, whereas the design of xdg-app (FlatPak's old name) was already discussed publicly at GUADEC 2013.
> If you’re a Fedora user and you want to install Spotify, you’re told to go to https://snapcraft.io/spotify. Spotify doesn’t distribute RPM packages, appimage, Flatpak or anything useful to a Fedora user who wants to download it, or to a Fedora maintainer who wants to add it to a repository. Fedora users are told to go to what is essentially a commercial store operated by a RedHat competitor where stats tell them their distribution is only 7th best.
> We’re in luck, we can still download the .deb. If Spotify stops caring, what do we do? We move to snap because we have to? Will the snap store continue to let people download actual .snap files in the future or will that get locked down ? Will the snap store continue to operate without an Ubuntu One account or will we get vendor-locked ?
Only Canonical can run a store. Once you install something, Canonical decides, when packages on your computers will upgrade. Wrt control, it goes way beyond Apple store/Google Play/Microsoft Store.
No thanks. Flatpak can preserve the benefits of decentralized repositories and upgrade under user control, with all the ease of packaging and sandboxing of the new toys.
It seems like they also often end up going back to the community solutions/standards eventually, so what benefit do they see in doing this over and over again?
The sandboxing part was spun off to the bubblewrap project, which has been adopted by the community for other purposes, such as Gnome's Epiphany browser.
SnapCraft on the other hand is a project that requires copyright assignment to Canonical Ltd for contributions, which presumably has the intended effects of keeping non-Canonical contributions close to zero.
AppImage only solves the easy part of the generic-linux-app problem, namely running the packaged appimage; it does nothing to solve the hard parts: how do you build the application so that it will actually run on generic Linux distributions, and sandboxing.
Canonical provides the tools and several companies are providing their software as snap packages.
Another example is JetBrains that provide all their development environments as snap packages.
While I don't like the tech, the real reason Snap pushes me away from Ubuntu is the fear of this future where the app store dream turned out to be a failure again. What happens to the distro then?