Hacker News Reader

Comment by csdreamer7 | Hacker News Reader

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.

View on HN

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.

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.

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

Reply on news.ycombinator.com