Install & restart. Nothing happens. OK lets launch it. Nothing happens. Lets try that again. Nothing happens. Check windows notification area...ah three copies running silently now. Left click on one. Nothing happens. Right click & close two. Spot a open shell thing in the menu. Click on that it starts a powershell window that says "Starting primary" for 5 mins. No idea what that means but I guess it did uhm something. And then closes itself. Staring at empty (windows) desktop again.
Right click on menu again...says "Start primary" is Running. I don't see anything? Let's try the shell again...open a powershell window which instantly closes itself? Back to staring at my wallpaper.
OK let's try stopping this mystery thing that is apparently running. Nothing happens. Try to start it. Nothing. Try the shell again. Now its back to the 5 mins of "Starting primary".
Window disappears. Again.
OK lets try this a different way. Open my own powershell window copy command it. 5 mins of "Starting foo" later.
>launch failed: The following errors occurred: >foo: timed out waiting for response
...and uninstall
"Multipass is a mini-cloud on your workstation using native hypervisors of all the supported plaforms (Windows, macOS and Linux)"
(Which sounds a bit like docker desktop, just using VMs instead of containers)
Issue has been open since March 2020: https://github.com/canonical/multipass/issues/1437
i am pretty sure it works as user on ubuntu, just like their lxc containers (main reason I prefer them to docker)
you may need to set it up as root and join the required group, but after that you should not need root.
Curious to hear from others about your experience with either flatpak or snap.
> Ubuntu VMs on demand for any workstation
What does this get me over VirtualBox?
> Get an instant Ubuntu VM with a single command.
Vagrant? Maybe the "single command" is good? Am I just being too much of a mounting-it-locally-with-curlftpfs guy?
> Multipass can launch and run virtual machines and configure them with cloud-init like a public cloud.
I am already confused. Are these VMs on a public cloud or not? If they are on my local machine, it's not really a test of the cloud (hint: Testing problems with virtual machines is not the difficult part of simulating a cloud on your computer, testing the possible failures with the other 200- hosted message queues and databases is). Again, what is this getting me over Vagrant or Virtualbox?
> Prototype your cloud launches locally for free.
I am still at a loss to understand what exactly is the selling point of this tool. Is it literally just "vagrant, but for Ubuntu"? I really don't get it.
I use flatpak precisely as you describe. It's for graphical desktop applications, "apps", basically stuff like Firefox, Libreoffice etc. Sandboxing is cool but I mostly do this because the flatpaks are always up to date with respect to upstream, instead of locked into a particular version like in the system repos. I also recently ran into a situation where a particular application wasn't feasibly packageable by the distribution because of unorthodox dependecy choices (and their own, rather strict rules related to packaging), yet they made a flatpak available.
I also like the fact that the applications and their files are isolated in their respective directories, which makes purging unused stuff easy, as opposed to traditionally packaged software pooping all over my home directory.
Running stuff from the command line is a pain, thus why, at least in my use, it's limited to graphical desktop stuff that I'd anyway run by clicking on an icon.
Canonical is being very sneaky with their promotion of Snaps, with some packages such as Chromium when installed with `apt install` actually installs both Snap and the Snap version of Chromium.
For these reasons I avoid Snaps completely and I have no issues with Flatpak.
The confusion comes mostly from people running the apt command in the CLI without looking at what the package is. There isn't a good way to transition existing users from the deb to the snap during an upgrade without having a transitional package with the same name as the original deb.
Snap packages are better maintained (more often with direct involvement of the app developer) and generally receive updates a bit earlier than flatpak. In both cases you need to pay attention who the app maintainer is and I'd argue that in case of unknown maintaners deb/rpm packages are safer choice.
Most of the packages still have access to the home directory of the running user, right? The sandboxing almost always seems either configure to be as lax as possible or so strict so that it causes issues. For most desktop linux users if a app has access to their home directory and network access then it already has 99% of interesting things.
Snap is a good solution if there is no alternative in the repositories or the one there is too old.
If a package is in the Fedora repository, I favor getting it from there. If it is not, my first choice is a flatpak from Flathub. I find it much less painful than downloading RPM packages (which aren't always provided and also don't automatically update) or adding a bunch of third party repositories like PPAs (which have a tendency to cause dependency hell if there are too many of them).
The main exception is the RPMFusion third-party repository. If something is in RPMFusion I get it from there instead of trying the flatpak. (Examples include Steam and FFmpeg)
Snaps are also available for servers and IOT devices. AFAIK the popular EFF Certbot is only distributed via snap for example.
However, a bunch of snaps are full of unused libraries because a bunch of packagers use a shotgun approach to including libraries. I've seen a bunch of snaps which contain the entire build environment for the app itself, for example. After cleanup, such snaps are often only 1/3 of the original size.
Because many snaps are created by app devs themselves, they don't all have the same quality as packages from the debian repository.
Snap update package without control and it is not open source…
1: https://ubuntu.com/blog/canonical-transforms-linux-on-mac
> Multipass is a mini-cloud on your workstation using native hypervisors of all the supported plaforms (Windows, macOS and Linux),
Seems their innovation is "Docker, but after 8 years of Docker"
Yes. It doesn't seem very confusing to me?
However, I might be wrong. Maybe I just missed the point of it?
Flatpaks are more an "all-or-nothing" approach. Either the app is in a tight sandbox and uses portals to access things like the camera or it has almost complete access to your os. Since portals are a new API which requires app rewrite, most Flatpaks are not sandboxed.
Next thing you'll be telling me that I should be installing antivirus to make sure the plethora of downloaded files don't contain malware.
And if I don't bookmark all the sites where I'm supposed to get these images, I have to hunt them all down again. And if I don't bother doing that I'm running old versions of everything.
Screw all of that and give me my apt-get install / upgrade.
For the two AppImages I am forced to use, I actually ended up writing a bash script to download them, mount them and build a .deb file that does the desktop integration. Then I push the .deb to my own repo, so apt-get install/upgrade works across all my machines again.
How should it work then?
If they don't want to continue making auditable builds for this package then that's fine, but they should also stop knowingly making these disguised Snap installation packages which just leverage the package's popularity to increase Snap usage.
You're mistaken if you think this is what is going on. The build is as auditable as any deb. Here's the source repository:
https://code.launchpad.net/~chromium-team/chromium-browser/+...
...and here are the build logs:
https://launchpad.net/~chromium-team/+snap/chromium-snap-fro...
I found these following links from the store listing: https://snapcraft.io/chromium
Snaps are also used to ship proprietary software - just as proprietary debs also exist. You may not be able to find sources or build logs for those - for example if they are built externally and the binary snap builds uploaded to the store directly. So an individual snap maintainer has a choice on where to build a snap and whether to publish sources and build logs or not. But typically Free Software snaps are built on the same infrastructure as Ubuntu itself, and for these, the sources and build logs are available in an equivalent way.