5 ms·

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 l

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.

Spivak 6y ago
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.
SahAssar 6y ago
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.
- jraph 6y ago
  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.
- berkut 6y ago
  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.
  - the_why_of_y 6y ago
    You might as well say FlatPak existed in another form since 2007, considering https://people.gnome.org/~alexl/glick/ https://people.gnome.org/~alexl/glick/ https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/ https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/ According to https://en.wikipedia.org/wiki/Snappy_(package_manager) 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-applications-for-gnome https://www.superlectures.com/guadec2013/sandboxed-applicati...
simlevesque 6y ago
The VSCode part is real. I had to install it on Ubuntu 17.04 a couple of weeks ago and it took me hours.
- thomaslord 6y ago
  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.
- temac 6y ago
  OTOH VS Code on a semi-old Debian 9 runs perfectly, from a regular .deb package and repository.
  - simlevesque 6y ago
    On ubuntu 17 there was a dependency issue when I installed the .deb.
- darkteflon 6y ago
  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.
- dralley 6y ago
  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.

Spivak 6y ago

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.

SahAssar 6y ago

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.

jraph 6y ago
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.
berkut 6y ago
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.
- the_why_of_y 6y ago
  You might as well say FlatPak existed in another form since 2007, considering https://people.gnome.org/~alexl/glick/ https://people.gnome.org/~alexl/glick/ https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/ https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/ According to https://en.wikipedia.org/wiki/Snappy_(package_manager) 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-applications-for-gnome https://www.superlectures.com/guadec2013/sandboxed-applicati...

simlevesque 6y ago

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

thomaslord 6y ago
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.
temac 6y ago
OTOH VS Code on a semi-old Debian 9 runs perfectly, from a regular .deb package and repository.
- simlevesque 6y ago
  On ubuntu 17 there was a dependency issue when I installed the .deb.
darkteflon 6y ago
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.
dralley 6y ago
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.