Hacker News Reader

Comment by lainga | Hacker News Reader

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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 like the way arch does it. They have AUR and everything is there and they can just say they don’t support it.

I think ubuntu also has similar stuff via PPA repository?

PPA is hell. Arch is love and life.

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

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

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

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

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?

Reply on news.ycombinator.com