Hacker News new | past | comments | ask | show | jobs | submit login
Disabling Snaps in Ubuntu 20.04 (kevin-custer.com)
599 points by temeritatis on April 24, 2020 | hide | past | favorite | 422 comments



Kudos to the OP, I'm glad this got posted on hacker news because Snap is so ridiculously broken.

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 . . .


Hear hear. I imagine for dogfooding, LXD is only packaged in snap, so we can't use apt as the source anymore. After migrating, an upstream push to a 'stable' LXD snap channel introduced a regression that borked our environments, and there was no way to:

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.


Canonical packages LXD as a snap package. Other distributions can package LXD in their favorite packaging format, and some do.

Some developers are trying to package for Debian. The work is in progress at https://wiki.debian.org/LXD


I've been looking forward for this work to come to something working for some time already, but it's been already 3 years I've eyed on it, is it now coming to something working "soon"?


Debian is a bad choice if you want to package go applications (or rust apps, for that matter). Debian requires that all those little static dependencies be individually packaged. Common container software like lxd, podman, and umoci are not found in Debian.

The following distributions package LXD (that I know of):

* Void Linux

* Alpine Linux

* Arch Linux

* Gentoo

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.


Do you happen to know _why_ Debian decided to require that for Go projects? It's so absurdly complicated.

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.


>It's so absurdly complicated.

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.


I would love a deb-packaged Caddy as well :(


You'll be happy to know Caddy will have a deb package in the next release (albeit not part of official debian repos), see https://github.com/caddyserver/caddy/pull/3309


I would add NixOS to that list. Especially if you value rolling back upgrades or pinning package versions.


I was not aware. Too late to edit now, but that is indeed a great option! Rolling release is a bit ambitious for a hyperlink without nixos like features.


Funny. I have been working on a blogpost detailing the silly things I encountered while packaging LXD properly for Arch Linux. Should probably finish it up one of these days.


Ahh Gentoo :) I once build-from-source think it was called stage-1 install on a SBC(Single Board Computer) 486DX. I compiled well over 4 days :D


Podman is in the NEW queue, and debs can be built from the packaging repo in the meantime., FYI.


Thanks for the info! Good to hear.


Yes, the situation with LXD packaging is ridiculous. I always wondered, do the maintainers really use it themselves for anything non-trivial?


Without too much details. But I personally got into LXD while bootstrapping kubeadm clusters with salt. LXD profiles made it very easy to work with compared to alternatives.

It's clearly not production stuff, but it works very well for a quick test bed before production deployments.


I guess users have been sufficiently beaten into submission that many of them will put up with software randomly quitting on them, but the idea that daemons should be snaps is doubly crazy. "Oh, Tomcat just updated itself, that's why we were down."

I really have no idea what people are thinking sometimes.


I always resisted running Ubuntu in production, even when it was much easier to install the necessary software. When you pick a distro, you're picking their packaging and maintainer culture. I've always prefered CentOS for that reason. Even the little things, like installing a new package won't start/enable the services (because you should have a chance to configure it first) always came off as more pragmatic for system administration.


I run Debian on my workstation and laptops but still prefer to use CentOS/RHEL on my servers.

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 [0] to set all services to disabled by default:

  $ cat /etc/systemd/system-preset/00-disable-all-services.preset
  disable *
Alternatively, as a one-time thing, you can "mask" the service before installing the package but this requires you to manually create the symlink (instead of using "systemctl mask") -- and requires you to know the name of the service unit beforehand:

  $ ln -s /dev/null /etc/systemd/system/nginx.service
  $ apt install nginx
  # ... configure nginx as desired ...
  $ systemctl enable nginx
  $ systemctl start nginx
Finally, there's the old, "sloppy" (IMO) method of "hacking" the /usr/sbin/policy-rc.d script to immediately exit with a status code of 101 ("action forbidden") [1].

(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
---

[0]: https://www.freedesktop.org/software/systemd/man/systemd.pre...

[1]: https://people.debian.org/~hmh/invokerc.d-policyrc.d-specifi...


> I guess users have been sufficiently beaten into submission that many of them will put up with software randomly quitting on them

A cultural acceptance of WIP software seems common, in free software communities, in my experience.


> 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?


And the middle one from Win 7?


The rumour is that the old control panel will be removed in the next version of Windows 10, so I'd hope so?


There's a difference between bugs and software developers who cares less about the user than software being up-to-date.

The first is a fact of life. The second is bad judgement.


Ugh, is it still impossible to disable Snap autoupdates?

Even if people should be updating regularly, forcing them feels completely antithetical to the Linux ethos of users having control over their devices.


The Snap team has some experience with this, seeing as how 20.04 has released and you still can't move the fricking ~/snap folder. Creating some generically named top-level folder in the users home directory is a straightforward fuck you to all users.

Since 2017: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053


This. Came here to post the same bug. I've been following the thread for the last 3 years, and it's an absolute mess.

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.


Are they really donating their time, aren't they Canonical employees? Canonical being a company that is paid mostly by companies that use their distro in production?


My response to "it's free" is "Here's a turd. SHUT UP IT'S FREE"

It's not an argument. It's freeness is a completely irrelevant property.


Yeah. That is what winds me up the most about snap. It is so... obnoxious! Why can’t it be .snap?! Or even better, something xdg compliant?


Dang, that really sucks. I was planning on updating my desktop to 20.04 but after reading about Canonical pushing snaps and now this thread basically claiming that moving or renaming the directory is impossible because what is in my opinion a design flaw in the entire system design, I think I'll switch to Manjaro or Arch for my desktop instead.

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.


arch is really a pleasure to use on the desktop, especially if you're already comfortable with a rolling release distro.


I love arch.

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.

  # ps
(see pages of stuff you don't need running)


I agree, I'm using Manjaro on my laptop and it works like a treat. I have read the horror stories of a botched Arch upgrade so I think I'll stick to the slightly-more-stable Manjaro but the ecosystem itself is very nice for the moderately familiar Linux user.


I develop software that tries to target as many distros as possible, and I really don't see how Manjaro is in any way better than Arch. Botched upgrades aside, Manjaro is the only distro that couldn't produce a valid iso to boot on KVM/qemu. It has a very weird kernel config, sometimes users don't seem to have modules that are found on literally any other distro. Which is very sad because Arch just works.


In my experience the Manjaro config tends to work better on some of the hardware I've tried it on, requiring less tweaking to get it to run properly.

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.


Void Linux is also great if you're not a fan of systemd.


pop os would be good alternative too. since pop os will be on flatpak n apt.


Would you expect anything else from the distro that rammed half-baked versions of systemd, pulseaudio, and unity down users throats?


I really wish it had been .snap


Props to Microsoft, for getting their approach to Windows updates adopted as an industry standard! /s


I think automatic updates on all platforms are probably an immense net benefit to the world given the huge degree of security vulnerabilities it avoids.

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'.


The option to have automatic updates (whether it is enabled by default or not) is an entirely different issue than the obligation to have automatic updates. The first one is a blessing, the second one is a nightmare.


Next step, introduce the mandatory restart as a standard.


But wait for the user to have a week-long job running for three days before you do it. That way they have to explain to their boss why there is now a 3 day delay.


It's critical? Don't use hobbyist software for that then. Take Debian or CentOS or something else with a non-cavalier development culture.


Ubuntu is "hobbyist" now? That's certainly not how they bill their entire platform.


I’m not sure how they’re trying to bill it these days, but certainly actions speak louder than words. All of Canonical’s design decisions seem to be aimed at making a consumer OS rather than a workstation or server one.


Ubuntu, no. Snap, seemingly yes.


She was asking for it by wearing that eh?


If it's good enough for Boeing...



I remember updating Ubuntu once. It bricked my installation for some reason. Ever since then I rarely update software.

With Ubuntu I just wait until the next LTS.


An important clarification: You never upgrade across major versions in place, or you never `apt-get upgrade`? I understand not jumping versions, but never applying security updates seems... imprudent.


May as well use Debian and escape the insanity.


I've got an ansible playbook that modifies my ~/.config/lxc/config.yml for certain deployment scenarios.

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 came to the realization that my home server doesn't need Ubuntu, it needs Debian.


Editing a config file for a program should not be more complicated than opening the file in your preferred editor, no matter your distro. Snaps break that.

I can't understand why they would break such fundamental thing and seemingly don't care about it.


I've thought of switching to Debian but I'd rather use a stripped-down Ubuntu so I can use PPAs.


Wait do PPAs not work on Debian?!


All this shit actually drove me to NetBSD for my home server


Why do not use Devuan? No systemd, no snapd(tm) and no same shits (small microsofts) hiding deep in the OS...


Mostly because it's a large bloated whale compared to NetBSD.


Nah, it's just there, ~/snap/lxd/current/.config/lxc/config.yml


LXC (and LXD, by extension) is packaged on Arch Linux as a binary, not a snap. I'm really grateful that the packagers worked with upstream to make this possible, as I heavily utilise LXC in my workspace.


YEP. For various reasons, we want to run Ubuntu on a server. Reboots and autoupdating are hazards and bugs for us. Upgrades & fixes mean patching our containers and starting fresh servers. Instead of rebooting a running server, we delete it. Trying to use Ubuntu environments means having to add custom disable-reboot-upgrade-downtime init scripts that we do not trust across updates: will bumping a minor version break them 5 days later? Super bad for reputation. I rather be updating Ubuntu more frequently, not less!

(Same-but-different for enforcing non-interactive mode on installs.)


It's unfortunate that they don't realize they're alienating the very customers that have money and will be in it with them for the long term.

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)


Same! Unfortunately we have a system is more or less tethered to use of LXD. While other workloads have moved to CentOS or Red Hat systems, LXD is supremely broken on those systems (or any distro that uses SELinux). It's extremely frustrating to be tied to Ubuntu for this one reason. It's even more frustrating when one of the key selling points from Canonical is "cross distribution!" Which appears to only be true for basic cases, or in the sense of, "Sure it's cross distro if someone other than us is willing to put in the work for their distro!"


Have you tried Proxmox? It runs LXD containers along with VMs.


It runs LXC. NOT LXD. And now LXD does the same as proxmox pve. It runs both VMs and containers.


I get the idea behind snaps is that someone recognized that configuration management was a problem but didn't yet appreciate just how deep that problem goes.

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.


Does anyone know if they fixed the bug where snaps don't work if your home directory isn't /home/<user>, or is on NFS?


of course not, the only progress so far has been people coming up with horrifying workarounds: https://bugs.launchpad.net/snappy/+bug/1620771


My god! Being unable to use snaps when you have “non-standard” home directory is ridiculous. What’s even more ridiculous is a response from snap developers - they marked this issue as “Won’t Fix”.

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


People will ditch snap and they'll end up using flatpak or something else just like the rest of the world. It happened with upstart and it then it happened with mir and unity.

I uninstalled it on all my Ubuntu systems and put it on hold. No new Ubuntu installs, switched to Debian.


What the actual fudge? So my Asad AD trust users, whose home directories are /home/example.com/sam-account-name, are going to run into trouble when they upgrade to 20.04?

I think I am going to have to start figuring out a plan to migrate them all over to RHEL...


s/Asad/SSSD/


You had to install snap on a production server?

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.


Is Pulseaudio no longer viable using APT alone? One of the first things I do is excise Snap from the system entirely and install Flatpak. I had been planning to upgrade my daily driver to 20.04 in the very near future (I prefer LTS versions) but audio problems would be a complete deal breaker.


This is honestly probably an unexpectedly good heuristic -- remove anything pulseaudio depends on, and you'll likely get a more stable system.


> By default, Snap applies updates and restarts Systemd services anytime it likes, and there's no way to turn this behavior off!

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'm using LXC from ubuntu packages for that very reason, got burned when a cluster upgraded automatically. I guess I must be very out of date if the debs no longer exist.

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 also are completely broken for NFS mounted home and data directories with automount. Which is the classic corporate Linux deployment. Of course, systemd doesn't even support wildcard automount....


On top of all of this bad behavior... I did try Snap to install Opera browser. Opera is written such that you need to put widevine libs in a certain directory for it to work. After tons of hacking and Googling, there is zero way to inject files into the file system of a Snap. I understand the security precautions, but that feels ridiculous. I left Ubuntu after more than a decade over their obsession with Snap.


I really like the idea of snaps. I really don't like a lot of the execution decisions around them.

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.


>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.

https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1575053


Unrelated to Snap, but on Windows, trying to use the My Documents folder for your actual documents is frustrating, because a huge number of apps and games like to use the folder for all sorts of nonsense, instead of using %appdata% like they're supposed to.


At least on Windows you can mark folders hidden without having to change the name. (i.e. the app that created the folder will still find it)


Create the file ~/.hidden and with the line "snap". It will then be hidden from your file manager.


dot prefixed files is a kludge that is now a standard rather than an actual hidden attribute like on Windows/NTFS.

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)


If it's still visible in ls, it's not a fix.


Make an alias that adds ls --hide the same way you do for ls --color.


The issue is that you have to continue "fixing" lots of individual utilities. In addition to your file manager and `ls`, what about tools like `fd`/`rg`/`ag` (requires adding `snap` to `~/.ignore` or `~/.gitignore`), `fzf` navigation in the terminal (may require updating `FZF_DEFAULT_COMMAND`), "open file" and "save file" dialogs in non-GNOME apps (like Zotero), and so on. The `snap` directory keeps popping up in new places, and discovering all the different ways to hide a non-dot-file is exhausting. In contrast, adding that initial dot to the `snap` directory would avoid the problem entirely.

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.


This would be nice if it was easy to toggle showing hidden files and hidden files wouldn't show up by default in all folder listings.

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).


AFAIK one common reasoning is that it is a writable folder that is easy for the users to find when they need to contact support.


This behavior is such normal for all the apps (especially games) that at one point I thought it was a specification.


I feel like in 2000 or before, My Documents was the "home" folder and you were supposed to put your own subdirectories inside of that. Might be wrong about that though.


The problem in Windows' case is that there never was a clear specification regarding what kinds of files should go where. The directory structure and environment in every version of Windows is a little different, and it's hard to write an app (or an installer) that does the right thing on all of them.


As long as you follow knownfolderid nothing has changed since Vista, or CSIDL constants go even further back.

https://docs.microsoft.com/en-us/archive/blogs/patricka/wher...

https://docs.microsoft.com/en-us/windows/win32/shell/csidl

.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...


I think the combination of complexity and obscurity of those two links reinforces my point more than it refutes it. There's a reason why basically no one gets this stuff 100% right, including some of Microsoft's own first-party applications.


Does anybody know why lxd is shipped via snaps? It's kind of confusing, because it seems like snap should be built on top of lxd. If you're running a container inside of lxd inside of snap, does that mean it's two layers of sandboxing?


My understanding is that the actual features needed to provide containers are part of the Linux kernel. What LXD provides is tooling and a daemon running as root that are used to manage containers. There's no reason why these can't be part of a snap, it doesn't introduce another layer of sandboxing for the actual containers.

(That said, I would still prefer that they not be.)


> Snaps break debain's stable release model. They allow upstream to ship updates outside of the normal 6 month ubuntu releases.

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.


I don’t have any experience with snaps so this is all new to me. Snaps install software at a system level right? Why on earth would there be anything in a user home directory? What if you have multiple users? Does snap get confused?


Snaps run out of a squashfs partition, but the app may save app config in the user's home directory (if they request the HOME interface, I believe).

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.


Snap stores user-specific application data in /home/user/snap/ folder. Like when packaged application wants to write into $HOME, snap gives it some sub-folder inside /home/user/snap.


Ah ok I understand now. Sibling comments reference the MacOS Library and *NIX ~/.local approaches. Both of those seem to make a lot more sense. Is there a config for Snaps to store user data in a different path, like ~/.local/snap/?


No; they use some magic with security policies and mounts so $HOME/snap is hard coded. Some of the early comments in that "4 year old bug" linked here explain it.


Most likely they download some things when you first run the software. This pretty common but usually opaque to the user due to it being in .local or .cache.


I've always liked OS X's concept of the Library folder, particularly back in Snow Leopard when it wasn't hidden by default.

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/


You as a user can still access hidden directories. Most new applications are nice enough to respect the XDG specification.


Oh, for sure, but it's mildly annoying.

Especially when a . is used to make the directory hidden, because I can't unhide that specific directory without changing the name apps expect.


You can press cmd-shift-g to open a "Go to folder" prompt which has some basic tab completion. This also works in file selection dialogs. Hopefully this saves someone as much time as it has saved me over the years.

I get into the Library folder by doing: cmd-shift-g -> ~/Library -> enter


Cmd-shift-. will show hidden files and folders in the Mac Finder before Catalina.

In Catalina, it's now Cmd-shift-fn-.

https://discussions.apple.com/thread/250756110


Whoa, even better tip. Thanks!


What? Of course you can!

$ ln -s .hidden not_hidden

It's that easy. Really.


Well, that's a symlink. It's a good idea, and something I should remember if I ever do start using Linux again—but the downside is that if I do need to temporarily enable hidden files, I'll see the same directory twice.

I'm being picky, I know! But I still think the Library approach is cleaner. (Again, back when it wasn't hidden by default!)


Not exactly the same, but the closest Linux equivalent that's semi-widely used would probably by ~/.local


And the problem is gigantic, programs in general are completely broken - why does my entire system have to be compromised because I decided to play Catan. We need the iOS/Android model for permissions on desktop.


> We need the iOS/Android model for permissions on desktop.

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


At least on recent Android versions the apps only ask for permissions when they actually need them, not on install time, and you can grant/refuse individual permissions.


This is also how iOS has worked since forever. I think it's helpful, but not that helpful.

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.


The missing piece is "refusing" permission should instead give dummy data: an empty address book, a random location, etc. Better would be profiles: Full, Basic, Public, Anonymous, etc


I'm not necessarily against this but there are some pretty major UX implications for non-tech users who don't understand what's going on. "Who is Foo Smith and why does this app think I know them?"


In Android 10 you "only" need to deny a permission 3 times until it is auto-rejected without a prompt.

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.


> At least on recent Android versions the apps only ask for permissions when they actually need them, not on install time, and you can grant/refuse individual permissions.

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.


Do we really?

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?


I agree with you on everything but the last two sentences. An unprivileged user account still has a ton of power in a modern Unix or Windows system, because the security model doesn't really solve this problem: https://xkcd.com/1200/


Thats one thing that snaps are trying to do. I personally prefer firejail for application sandboxing and permissions but then you have to be extra careful how you install the application (dpkg post-install scripts have been known to do sketchy things) and you have to make sure you never accidentally run the application without firejail.


I wanted to like snaps (and flatpaks before then), because trying to ease packaging and deployment of apps on Linux is a noble goal, but in both cases I eventually gave up on non-trivial use of them because they were always broken in some annoying way because of their sandboxing.

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.


AppImages are a disaster waiting to happen. They are like Windows MSI installation files just downloaded from somewhere, running without any confinement.


You can run the AppImages you don't trust with the Firejail sandbox which has native support for AppImage.

https://firejail.wordpress.com/documentation-2/appimage-supp...


This is a nice workaround I guess.


I'd call it following the Unix philosophy instead of a workaround.

> 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.


SELinux does the job better though if someone just configures it. AppImages should be confined automatically IMO.


Sounds like a perfect addition to a -- preferable, but sometimes too heavyweight -- repository-based solution like apt. Basically a more powerful binary tarball.


Gnome-Builder, the official Gnome IDE, builds flatpaks. I'm not sure how good it works, but idea is that one should imagine this brave new world of Linux sandboxed apps similarly how IDEs could work on smartphones. In the end the IDE must be either blessed with special powers or it must build packages for the sandboxing system. Gnome-Builder seems to take the latter direction.

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.


AppImages are definitely the best, I just wish they had an easier way to integrate with the system. I know about appimaged, but I had problems settings it up, and it's just not as easy as integrating Flathub into Discover, or getting your packages from the CLI by accessing your distro's repositories.


I didn't get even that far with VS Code snap.

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.


Snaps certainly have some usability problems. E.g. to use videoconferencing in Chromium I had to give it rights to connect to record audio explicitly.

I expect you needed to do something like that for the VS Code snap.


I did that too, and it works for one minute, every time I start the browser. Firefox it is.


That's weird. I've been doing Zoom through web browser multiple times for hours since then.


I used to use it for daily webex until the snap broke it.


It used to work, with the latest update audio doesn't work anymore in Chromium (although it does see the device), I'll have to report a bug. (snap connections does show audio-record connected)


I've been using Ubuntu 20.04 for several weeks, almost since beta came out.

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.


On 18.04 it takes like a full second, sometimes two, to open the calculator anyway.


They changed those apps to normal packages in 19.04 or 19.10.


Oh, I get it now.


multiple monitor support in Linux is high on my list of reasons I keep switching back to my Windows partition.


I suggest trying Kubuntu. I've been running 3 4K monitors for years, all works fine, including HiDPI support.


If my primary monitor is to the right of my secondary monitor, do applications open on the primary monitor or the 'left' monitor? Also, do applications remember which monitor they were last opened on?


Not the parent, but I've also been using KDE in a multi-monitor setup for years (I have a 1440p primary monitor, and two vertical 1080p monitors to the sides). In my experience, applications open on the primary monitor, or on the monitor that is "active" (i.e. if you run Alt+F2 to bring up a run prompt on your secondary monitor and launch an application from there, the application opens on the secondary monitor where you launched it.).

Yes, applications remember which monitor and even location on the monitor they were last at.


It worked very, very well on Unity. It also works with other DE like Plasma but I personally find it horrendous on other aspects.

I'll probably give Budgie a go.


If my primary monitor is to the right of my secondary monitor, do applications open on the primary monitor or the 'left' monitor? Also, do applications remember which monitor they were last opened on?


That depends on the DE.

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.


Two 4k monitors with Ubuntu Mate, works well.


You're talking about connecting an external screen to a laptop or two monitors on a desktop and using it in only-display/only-laptop/mirror/separate screens mode right?

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.


Is multi monitor support in Linux broken? I've been going strong for ages with proprietary nvidia drivers and i3/dwm.


I wouldn't say it's broken. But Gnome Shell is made for a single monitor so working with more than one makes it a pain in the ass.


Cinnamon is pretty good.


After trying out a bunch of environments about a year ago, I settled on cinnamon because it had the best multi-monitor support.


Same here with open source drivers and Cinnamon/lightdm.


actually dash-to-dock is working just fine for multiple monitors (and given the strange UI paradigm of Gnome basically a must have). The ubuntu-dock is just a none-configurable version of that. AND in 20.04 the full dash-to-dock just vanished...


Yeah, I had to reinstall one from source. https://github.com/home-sweet-gnome/dash-to-panel


One more thing if you installed on ZFS:

/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 /.


To ensure snap will not be installed again see the apt config here:

https://github.com/cies/kubuntu-setup#remove-snap

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):

https://github.com/cies/kubuntu-setup/tree/master/chromium


Chromium is actually the only real use case for snaps. It is so difficult to build/package chromium for a LTS distro that Debian simply stopped trying. See what happens with security updates on Debian jessie (which is under their LTS): https://security-tracker.debian.org/tracker/source-package/c... . Ubuntu made the right choice here: https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-tra...


Except that chromium under snaps is pretty unusable unless your home directory is structured exactly the magic way Canonical expects, if you have symbolic links, stuff on other disks, suddenly you can't upload your customer orders, or your PCB CAD designs to be made, you can't save files into /tmp anymore, even if you've been doing that for 3 decades. And it all fails silently, mysteriously, no error messages explaining why stuff has suddenly stopped working.

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


It's a terrible use-case that causes data loss for users, for FOUR years now: https://bugs.launchpad.net/snapd/+bug/1616650

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.


One of the very annoying consequences of the Chromium move to snap on 20.04 is that it will silently fail to launch most external links (e.g. Slack, Zoom).

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 basically breaks xdg-open. This is crucial for a lot of flows with desktop software and I'm honestly baffled why it isn't fixed. Any URI with a custom scheme is horribly and completely broken with a browser installed as a snap. Even basic stuff like file uris are broken in browsers installed as a snap.

It's extremely weird to see this kind of thing when it happens too, you usually trust Firefox to work!


It is strange this is still broken, but it’s pretty easy to build wrappers for xdg-open and friends yourself.

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's a problem for my users, because it's silently broken.


Oh it also breaks a lot of native extensions: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+...

It also causes data loss: https://bugs.launchpad.net/snapd/+bug/1616650


Most of our family PCs run Xubuntu LTS. Because they are low end / 10+ year old machines I always uninstall unnecessary stuff like snap. Have not seen a single case where I would have regretted this.

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'.
So the only somewhat worrying news is that chromium is gone.

   $ apt show chromium-browser
   Package: chromium-browser
   Version: 80.0.3987.163-0ubuntu1
   ...
   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.
Not that I would use Chromium more than 3 times a year. But occasionally some web site is broken on Firefox. And if it is important like a flight check-in I start chromium. But flying is not a valid use case in Europe at the moment so lets see how long I it takes until I note the lack of chromium again.


I installed keepassxc using a snap, but because it was in a snap browser integration didn't work with my browser because of the snap isolation, rendering it useless. Also it's kind of weird that hey Damon has to run just so that I can install snaps and one Daemon per snap, too. I'm pretty sure I don't like that.


Keepass as a snap because security right /s. This is an actual piece of software that has a history of being modded by attackers to steal credentials. Why would you put that in a snap?


May I ask what history you're speaking of? (also note that KeepassXC is a fork of Keepass)


Any Keepass (or similar) software, it should run as predictable as possible. I know this software was once offered with a trojan loaded on some download website, but just searched around and could not find anything about it. Maybe the maintainers remember.


So I've used ubuntu (Xubuntu, xfce) for quite a while and would rather not deal with this, are there any distros that aim to be ubuntu but without snap?

Because hearing things like `sudo apt install chromium` actually aliases to using snap is disconcerting to say the least if true.


Pop!_Os is basically just Ubuntu but better. They will have flatpak integration with the store app with 20.04, but the official stance is to use the deb packages first, and then fall back to flatpak if there is no deb available.


I think Pop_Os is becoming the next Ubuntu. It's already captured a huge percentage of the gaming community. If you read r/linux_gaming a huge amount seem to be using it.


The closest thing to Ubuntu is Debian.

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.


Debian, ubuntu's upstream.


In Xubuntu 20.04 no snaps are installed by default. So you can simply uninstall snapd or just leave it there.

However, if you want to use chromium-browser you are out of luck. It is no longer available as a .deb package.



MX Linux might be the ticket. It's Xfce as well.


> I lean more toward Flatpak as it is more performant

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?


>Is Flatpak faster than Snap?

Snap suffers from the overhead of having to decompress a squashfs on program launch: https://forum.snapcraft.io/t/squashfs-is-a-terrible-storage-...


Launching app from snap is noticeably slower than from native package.

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.


> Is Flatpak faster than Snap?

Yes, Flatpak is just bind mounts and namespaces. It doesn't have the overhead of the squashfs images.


I always had problems with both of them. I use Docker a lot and Flatpak/Snap are intended to be a type of Docker for desktop apps. I know with Flatpak it has some shims to integrate with your system UI libraries so themes try to match up, but there are issues with that too (and flatpak apps just not starting up half the time).

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.


Flatpak is marketed as a better Snap (it surely has some advantages: no vendor lockdown), but at the end of the day, the system integration is not that good, I tried to use the Flatpak of Wireshark back in the day when I tried Fedora Silverblue, I ended up regretting that experiment.


> a type of Docker for desktop apps

By the way, what is it with Docker that makes it hard or impossible for it to be used for this exact purpose?


Desktop apps are not designed to operate in isolated fs namespace/network/etc from the host. So the user experience won't be seamless unless there are standards that enable desktop apps to be aware of how they are dockerized. Which there aren't afaik


It's not that hard. I remember using it to run Slack at one point, and while it wasn't easy it's definitely possible if you need it bad enough.


Docker is poorly designed as well.


can you elaborate? I can google for "docker sucks" blogposts, but I trust the HN opinion to be a bit more thoughtful. Any specific pain points you can identify?


The most commonly mentioned flaw was/is the root daemon. That can be worked around with other tools. The command line and docker files are a bit clumsy as well. Many images have security flaws. It didn’t clean up after itself for a looong time, etc.

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.


I think what the author wanted to say is that the tradeoffs made by Docker's authors are different than those he would have made.


It's a shame that chromium's apt package uses snap now. Startup time increased from ~0.2 to 5-10 seconds. Using Brave fixes this.


Chromium from Debian, as a DEB package, on Ubuntu:

https://github.com/cies/kubuntu-setup/tree/master/chromium


Switching to another browser to fix a packaging problem with the first browser is using a sledgehammer to crack a nut.

It's also disingenuous to suggest a browser wrapped in a cryptocurrency promotional wallet thing as a comparable alternative.


> Switching to another browser to fix a packaging problem with the first browser is using a sledgehammer to crack a nut.

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.


Using Firefox also fixes this.


Chrome via appimage works great


AppImage itself is great.


It seems like on recent Ubuntu installations some packages are provided by snaps (ie. "apt install XXX" will install a snap). I'd be interested in disabling this behaviour, if anyone knows.


Cies posted a link to https://github.com/cies/kubuntu-setup#remove-snap

They give the suggestion to remove via

   sudo rm -rf /var/cache/snapd/ && sudo apt autoremove --purge snapd && rm -fr ~/snap
And make sure it never installs again:

   sudo bash -c "cat > /etc/apt/preferences.d/no-snapd.pref" << EOL
   Package: snapd
   Pin: origin ""
   Pin-Priority: -1
   EOL


Hmm, but then "apt install" would just fail because of an unresolved dependency right?


That would be really bad. I used Ubuntu for the past 15 years or so, but that would make me switch to a different distro.

So shortly after the Mir fiasco, why does Canonical feel it necessary to come up with the next dumb idea?


Unfortunately, it seems like I remembered correctly, at least for Chromium: https://news.ycombinator.com/item?id=22972856


What is or was the Mir fiasco?



I think that this is just the case with LXD. LXD used to be distributed as a DEB package in Ubuntu 18.04. Therefore, to make it to upgrade from DEB to snap in newer versions of Ubuntu, there is this dummy 'lxd' DEB package in the repositories that in fact installs the snap package of LXD.

Other than that, I do not think other packages are affected.


I installed Snap on Debian 10 stable to install Firefox and Chromium as snaps. It allows me to get the latest security updates for these 2 software without entering into dependency hell with the OS. Beside the slow startups, which is not really an issue with those apps because I keep them open all the time, it worked flawlessly so far for me.

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.


If all you're looking for is the ability to get the upstream updates immediately, you can also just download the tarball version and unpack it somewhere under your home directory. Then dump a .desktop file for each in ~/.local/share/applications/ so it shows up in your app menu.

No startup slowness, and you'll still get the vendor-provided updates as they're released.


I'm curious why this got downvoted -- would it not work?


I have no idea why that reply got downvoted as well. It is essentially how I installed Firefox on my Debian stable laptop , and it has been working great as far.


Performance aside I was very disturbed to learn snap packages have no namespacing and no useful mandatory authorship metadata: https://forum.snapcraft.io/t/lack-of-package-provenance-is-a...

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


Yep, it's a massive smell. When I looked at installing a snap I wanted to audit the build script but I couldn't find that anywhere. That's a big NO from me.


Consider any other operating systems out there for a moment. A new upgrade comes along that contains unwanted features. How often is it possible to revert that by uninstalling a few packages?

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 :-)


Have you ever tried Void? I've used it on my routers for years, had a media PC with it and recently setup my dedicated server with it. It's really nice, but it is certainly more hands on and missing the management layers found in other Linux distros.


In looking at some of the other entries about 20.04 on Mr. Custer’s site I’m wondering if it would’ve been simpler to just start with mini.iso to make an actual barebones installation and then install only what is actually desired. If you truly want a lean install then building your own custom mix is possible in Ubuntu and a relatively blank slate is available.


Does Canonical have any 'push' motive for reducing dependence on apt? Or do they really just like snaps?


Snaps have benefits. Canonical sells 5 year service subscriptions in addition to the 5 years they already offer for free on LTS. Snaps enable a way to get the latest VSCode and other apps on very old versions of Ubuntu. Snaps allowed me to try out Debian and Fedora with minimal issues and easily integrate them into my dotfile manager with Ansible.


It's super super nice to have a real system for dealing with "pet" applications that users want to be updated outside of the distribution release cycle.


The VSCode part is real. I had to install it on Ubuntu 17.04 a couple of weeks ago and it took me hours.


I spent just as long fighting snap when I wanted to use a custom font with ligatures. User-installed fonts don't work with snap, apparently. I would've spent substantially less time figuring out the problem, but I didn't even know I had the snap version - I typed `apt install code` and transparently got a snap package instead of a deb.


OTOH VS Code on a semi-old Debian 9 runs perfectly, from a regular .deb package and repository.


On ubuntu 17 there was a dependency issue when I installed the .deb.


I'm honestly kind of confused because it's really easy to install VS Code on Fedora through the officially provided RPM package, and there is an automatically-installed repository so that it's kept up to date.


Anecdotally, I’ve been using the VS Code snap (with the —classic flag, I believe) on Ubuntu 20.04 for the past couple of weeks without issue.


That works with Flatpak/AppImage too though, right? For me Snap has always had that Canonical smell of not-invented-here, just like Mir, Unity and Upstart. All of those were eventually replaced with what a majority of similar linux distros settled on. I'm not saying it was wasted development or that nothing was learned but ultimately they joined the rest of the ecosystem instead of the ecosystem joining them.

It seems that canonical does best when they embrace the ecosystem and not try to replace it.


Upstart actually preceded systemd and was adopted by Fedora, Red Hat, openSUSE and ChromeOS. ChromeOS still seems to use it, interestingly. It probably paved the way to systemd and probably fulfilled a need that no other init system could. Ubuntu was also fast to switch to systemd when it appeared.

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.


Just like with Upstart (which existed well before systemd did), Snap existed before Flatpak, and in fact existed in another form (Click) for two years before that.

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.


You might as well say FlatPak existed in another form since 2007, considering https://people.gnome.org/~alexl/glick/

https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/

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.

https://www.superlectures.com/guadec2013/sandboxed-applicati...


I think they just realized it gives them a way to package proprietary apps like Skype, Spotify, and Slack a bit more simply than would be required to apt-ify/dpkg-ify them. I really think that's the primary motivation.


If it's to avoid this kind of aberrations https://news.ycombinator.com/item?id=22864985 it's totally understandable, but in practice, it doesn't work that smoothly unfortunately, not to mention the potential vendor lockdown, or as the Mint team phrased it:

> 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 ?

https://blog.linuxmint.com/?p=3766


And it's a pretty good one since the experience with having a large catalog of useful software in Flatpaks has been awesome and largely seamless. I just wish Canonical wasn't off doing their own thing or had started out in the open from the start so it would have a chance of being a useful standard instead of the weird Canonical store.


The number one reason why I don't like snap is: it puts Canonical in control.

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.


I can never figure out Canonical's logic with going off to do their own thing. They don't do it with everything, so clearly it's not a complete rejection of things not made in-house.

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?


Does it force the community solution to improve? If the options are community or Canonical does that competition have benefits to both? Not sure Canonical are thinking that explicitly but maybe it’s just hedging their bets if the community solution doesn’t work out.


But this is a false dichotomy, because Flatpak is a project controlled by Red Hat. Unless by "community" project you mean AppImages.


FlatPak is a project initially hosted on freedesktop.org infrastructure with distributed copyright ownership under a copyleft license. It was initially founded by Red Hat employees but has attracted substantial support and contributions by companies such as Endless and Collabora, not to mention volunteer contributors.

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.

https://github.com/containers/bubblewrap

https://blogs.gnome.org/mcatanzaro/2020/03/11/epiphany-3-36-...

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.

https://github.com/snapcore/snapd/blob/master/CONTRIBUTING.m...


I'm speaking in general, this would also include the Gnome churn a few years ago. Canonical seems to build their own thing then abandon it in favor of what the community was doing before or during the development of the Canonical thing. I'm just spitballing why that may happen.


Considering that Flatpak was essentially a hostile fork of the AppImage project motivated by Red Hat's insatiable hunger for control, I find it ironic when Flatpak supporters complain about Canonical "doing their own thing".


FlatPak has nothing to do with AppImage, is in no way shape or from a fork of it.

https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/

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.


Got a source for any of those claims?


I don't know about Spotify, but both Skype and Slack are distributed with private apt repositories and it works just fine.


Spotify is too. Their deb repo is just outdated compared to their snap (which itself is outdated compared to what's available on macOS and Windows). I think it's fair to say they don't care much.


I like the way arch does it. They have AUR and everything is there and they can just say they don’t support it.


Happy Arch and AUR user chiming in, a custody, or emigrant, from the F snap hell Ubuntu caused, and it's easy to verify and vet AUR content, if you care enough, the scripts are legible, readable, so it's just a matter of caring about your system. I agree, I am so happy about the Arch system since Ubuntu bit, ate wholehartedly, the snap bullshit. Thank fuck for AUR.


Thank fuck for the Arch Wiki, too - even if you’re not on Arch.


Upboated and agreed. ++


I think ubuntu also has similar stuff via PPA repository?


PPA is hell. Arch is love and life.


The AUR is so transparent. If I want to see how the AUR package is getting built, ez, read the PKGBUILD linked right from the packages page. I was immediately turned off to using Snap because I couldn't find how the Snap was built and really who built it. No Thanks, that's not how I install software on my personal computer anymore, it's one of the main reasons I exited windows as soon as I started to learn about infosec and trust.


Not only that but modifying the pkgbuild for yourself is trivial. Very convenient for installing patched kernels.


Yep I upvoted the whole tree. Agree(d). ++


Life, indeed. Reading the (excellent, mind you) documentation and, especially, the wiki is fun, I know, but sometimes I want to focus on something else (like getting things done).


Totally agree, just have to report back that it's no huge'er job in terms of systems management. But am on your page. I guess it's relative, I was Ubuntu, too, because I liked the next-next-next ideology, but, when it comes to it, either system-types can be as maintenance free as any other. Rolling releases has the convenience of not being so difficult to upgrade, as you just roll along, you sometimes end up having to reinstall, on these systems like here, like Ubuntu and co I mean. But yeah work is what's most important. I've been a happy Ubuntu user for ages, glad you're getting your work done. It's all that matters relatively speaking. Thanks


In all your examples, it is their respective company that does the packaging. Skype is packaged by Microsoft, and so on. Here is the Skype snap page, https://snapcraft.io/skype

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.


Snaps (and Flatpak) are the app store pipe dream all over again, about 11.. 12? years too late. If anything treat them as early indicators of the future financials of these distros, if attempting this all over again is central to their future business model. Snap to me is synonymous with desperate.

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?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: