[HN Gopher] Canonical Multipass - Ubuntu VMs on demand for any w...
___________________________________________________________________
Canonical Multipass - Ubuntu VMs on demand for any workstation
Author : 3ds
Score : 61 points
Date : 2021-11-11 16:39 UTC (6 hours ago)
(HTM) web link (multipass.run)
(TXT) w3m dump (multipass.run)
| Havoc wrote:
| Hoping for canonical's sake I've just got a broken install, cause
| the UX is somewhere between nonexistent and useless.
|
| 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
| rcarmo wrote:
| I liked the idea of it until I realized I could not run it as a
| non-admin user on the Mac because they had not designed the app
| in a way that allowed for it - the control socket was
| inaccessible to my "regular" user.
|
| Issue has been open since March 2020:
| https://github.com/canonical/multipass/issues/1437
| tyingq wrote:
| It's in their docs, but not on this page. If you're confused
| about what this is:
|
| _" 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)
|
| https://multipass.run/docs
| lenn0x wrote:
| I've been running multipass for awhile now to host Docker on
| macOS, especially on M1. I ended up writing a guide/docs on how
| to easily get it setup with cloud-init to replace Docker
| Desktop. Hope this helps anyone.
|
| https://github.com/chrisgoffinet/docker-multipass
| watermelon0 wrote:
| Did you notice any performance differences compared to Docker
| Desktop?
| eatonphil wrote:
| Off topic but prompted because Fedora and Ubuntu sites keep
| pushing in this direction... Do you use snap or flatpak?
| Preferring not to learn a new technology in this space, I've
| stuck with apt-get and dnf. I guess the dichotomy is that
| snap/flatpak are for (desktop) applications whereas the system
| package managers are more for system packages? Neither flatpak or
| snap seem very common outside of desktop environments (i.e.
| server deploys or Docker environments).
|
| Curious to hear from others about your experience with either
| flatpak or snap.
| raffraffraff wrote:
| Also AppImage. I hate them all. It's just lazy developers who
| won't package their software for each distro. In fairness I get
| it - that's a lot of CD pipelines. But it really is a second
| rate experience for the user, compared to a properly packaged
| app in a repo, which you can install or update with a single
| command, and which properly integrates with the desktop and
| doesn't create a bazillion weird mounts.
| ajvs wrote:
| You can only connect to one Snap repo at a time (which is by
| default the proprietary Snap Store), unlike Flatpak which
| supports multiple backends simultaneously.
|
| 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.
| galgalesh wrote:
| Note that the chromium apt package is a transitional package
| only meant to be used during an upgrade, to migrate existing
| users. The package is marked as such and the description
| explains this clearly. Because the package is marked as
| transitional, it isn't shown in GUIs, it's only installable
| via the CLI.
|
| 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.
| ajvs wrote:
| Users shouldn't be "transitioned" to a closed-source app
| store full stop, no matter how nice it would be for
| Canonical metrics. Only specifically typing `snap install`
| should work.
|
| 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.
| rlpb wrote:
| > If they don't want to continue making auditable builds
| for this package then that's fine...
|
| 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.
| simion314 wrote:
| Yes, I used snap on server, I think the package was pdftk ,
| worked great the only issue it might be is that is configured
| to only have access to the home folder.
|
| Snap is a good solution if there is no alternative in the
| repositories or the one there is too old.
| aj3 wrote:
| From the security perspective both snaps and flatpaks are
| preferable to dep/rpm for browsers, email clients, office
| suite, document viewers and other stuff that is used to parse
| untrusted data often (due to [wip] sandboxing and auto update).
|
| 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.
| SahAssar wrote:
| > From the security perspective both snaps and flatpaks are
| preferable to dep/rpm
|
| 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.
| galgalesh wrote:
| Snaps have only limited access to your home directory and
| you can turn it off as a user. They don't have access to
| hidden folders in your home directory, for example, so they
| can't access your ssh keys, config and keychain.
|
| 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.
| selivanovp wrote:
| I use both. Flatpaks usually slightly faster for desktop apps,
| and snaps can do what flatpaks can't- entire stack of
| technologies inside a single snap (nextcloud server for
| example). The main benefit of both for consumers is general
| availability of fresh software no mater what distro you're
| using and additional security for the price of slightly less
| performance and additional storage space.
| throwawaymanbot wrote:
| Snaps were a half baked technology when released. And they
| are still not prime time!
| daitangio wrote:
| No sorry, and for good reason:
| https://gioorgi.com/2021/ubuntu-20-failed-me/
|
| Snap update package without control and it is not open
| source...
| mathfailure wrote:
| AppImage. And I aggressively cut snap away.
| rjzzleep wrote:
| I use neither, I tried to use both, but my main driver is a
| latop and even though I have a 1TB SSD I consider this to be
| eating a significant portion of my disk space. electron apps
| already are disk hungry enough on their own.
| galgalesh wrote:
| Note that, because snaps are stored compressed on disk, many
| snaps are smaller on disk than their regular package
| counterpart. Take the chromium package as an 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.
| padraic7a wrote:
| I use Ubuntu on the desktop, have a few snaps installed and a
| couple if flatpaks. Both seem fine in my limited usage.
|
| Snaps are also available for servers and IOT devices. AFAIK the
| popular EFF Certbot is only distributed via snap for example.
| anuragsoni wrote:
| Snap can install non-desktop applications just fine. I've only
| ever seen Flatpak for desktop apps, but I use snap for
| installing things like docker, lxd etc.
| capableweb wrote:
| Isn't the entire point of snaps (and flatpaks?) technology
| that it's isolated? So the application won't be able to do
| whatever to your computer. But docker, lxd and similar
| usually requires root permissions to run, and access to bunch
| of sockets and what not.
| selivanovp wrote:
| Isolation is optional and you can tune it to your needs.
| ufo wrote:
| This is what I do for the desktop apps for my home desktop:
|
| 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)
| kiryin wrote:
| First off, do yourself a favor and avoid snap like plague. It's
| vendor lock-in and horrible.
|
| 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.
| pacifika wrote:
| Seeing how often virtualbox breaks things and the swiftness with
| which this spins up a throwaway vm, it has some potential for a
| faster dev project host.
| quadrifoliate wrote:
| I'm quoting their copy here to make sure my criticism is
| accurate:
|
| > 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.
| zokier wrote:
| > Is it literally just "vagrant, but for Ubuntu"?
|
| Yes. It doesn't seem very confusing to me?
| capableweb wrote:
| The docs seems to explain things the best, as usual:
|
| https://multipass.run/docs
|
| > 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"
| vizzah wrote:
| What about Canonical's LXD/LXC?
| [deleted]
| blacksmith_tb wrote:
| It may be popping up in the news again because Canonical just
| announced M1 support for multipass on macOS[1]. I haven't tried
| it, but I do appreciate the reference to The Fifth Element.
|
| 1: https://ubuntu.com/blog/canonical-transforms-linux-on-mac
| 3ds wrote:
| That's why and how I found it.
| maccard wrote:
| I'm with you - this seems like docker for ubuntu.
| lenn0x wrote:
| that's how ive been running it on macOS. I put up a guide
| https://github.com/chrisgoffinet/docker-multipass
| hluska wrote:
| I might be wrong about this - I have a history of sometimes not
| always understanding technology before I discard it. However, I
| briefly used Multipass but switched back to Vagrant. To me, it
| was a new tech that did the same as the old tech only with the
| usual new tech adoption muck ups.
|
| However, I might be wrong. Maybe I just missed the point of it?
| Tajnymag wrote:
| Cloud-Init is a local tool for setting up a new fresh system
| instance. It isn't tied to any real cloud.
| easton wrote:
| It seems faster than Vagrant to me, and doesn't rely on
| VirtualBox (it uses Hyper-V on Windows, KVM on Linux, and
| Apple's Hypervisor API on macOS). Granted, Vagrant doesn't
| either, but very few of the boxes have support for the native
| hypervisors.
| lenn0x wrote:
| Yes it's been way faster for me over Virtualbox. It's how I
| run docker now from macOS. I've been testing out the M1
| support for few months now.
| xriddle wrote:
| previous discussion:
| https://news.ycombinator.com/item?id=21836528
___________________________________________________________________
(page generated 2021-11-11 23:02 UTC)