Hacker News Reader

Comment by jrockway | Hacker News Reader

Snap was neat when I first discovered it. I could get some bleeding-edge dependencies automatically delivered to my machine, without building it from source or having to manually update it. Wonderful! But the problem is: it's the slowest thing in the world. I've complained about this on HN before, but it can be hundreds of milliseconds from when you type a command to when the actual application starts running -- the intermediate time is being consumed by Snap doing god knows what. The slowness is a dealbreaker for me. My disk can read 500,000 4k blocks per second. My RAM can do 3400M transactions per second. I have 32 CPU cores. How is loading some bytes into RAM and telling the CPU to start executing instructions something that can take more than a few microseconds!? Easy: run that app with Snap!

I blew up my Ubuntu install and switched back to Debian. I haven't missed Ubuntu at all. I am resigned to the fact that if I care about a particular piece of software because it's the reason I use a computer (go, Emacs, Node, etc.) then I just have to maintain it myself. There simply isn't a good way right now. And you know what? It's fine. Everything is configured exactly the way I like, and it will never change unless I change it.

View on HN

I think the last time the startup issue came up on HN we concluded it was because they are mounting a squashfs filesystem image that was created with the compression turned up to 11, and not using the kind of compression algorithm that is only slow on compression. That and the general terribleness of squashfs.

Now keep in mind we can't blame squashfs here. It was developed for use on <16 MiB large NOR flash chips for embedded devices likely connected over SPI - the underlying flash and interface is so unbelievably slow that no amount of compression or terrible kernel code would ever start showing up in some kind of benchmark. Using it on super fast desktop machines with storage that rivals RAM bandwidth and latency is just the opposite of what it was developed for.

Is there any replacement for squashfs? I don't know of any other format on Linux that captures the state of the file system as fully as squashfs.

See https://ewh.ieee.org/r4/se_michigan/cs/20131019/A%20Comparat...

Squashfs is not a problem. Squashfs can be faster than ext4, sometimes many times faster (lots of small files).

Selected squashfs parameters are the speed issue.

From my experience squashfs can give quite okay perf if you use the right params and compression. I'd expect one of the largest linux distos to tune those params correctly.

Is “quite okay perf” really the goal post though? Using applications is what makes a computer useful. It’s bad enough that applications these days are terribly slow and inefficient to begin with, I don’t want even more unnecessary slow downs on top of that.

I'm not advocating this usecase for squashfs, just saying that the perf I'm seeing in snaps is not necessarily what properly configured squashfs would give.

We are living in a world where Electron is acceptable. I expect nothing.

The linux distros are usually not the ones pushing Electron and this is one step lower from where a Electron app would run.

The thing that irks me about this is that we have carefully optimized file systems, virtual memory, and dynamic linkers over the years to try to make starting a program scale only in the number of touched pages, and somehow it was considered sane to destroy all of that and store the program compressed on disk, when we know from experience with every other package manager we had been using that he software wasn't what was using up all of our disk space :/. Most of the large assets that come with software (such as images) don't even compress well as they are either difficult to extract entropy from (machine code; we do it but it usually uses more specialized algorithms) or files that are already compressed (such as images)! In contrast, iOS extracts packages to disk when you install them, and Android has developers use zip files that are configured to just not compress (to instead "store") anything the developer might have expected to be able to memory map at runtime and then has them run the file through zipalign to add padding that ensures all the stored files begin at memory mappable page offsets in the file, allowing them to not extract the file (keeping it as a single unit as signed by the developer)--though they do still extract the code to prelink and now even precompile it!--while not compromising on startup performance.

> But the problem is: it's the slowest thing in the world.

Exactly. I recently had to replace Chromium with Google Chrome just because the Ubuntu maintainers thought it'd be a good idea to replace the Chromium apt package with an installer that pulls in the snap…

Good thing Firefox is my main browser and I only use Chromium/Chrome for testing (and whenever websites forget that there's more than just one browser to test for), otherwise I would have long ditched Ubuntu, too.

I've been getting bug reports for a browser extension because of Snap. The file system isolation of Snap and Flatpak breaks Native Messaging, so extensions that need to communicate with a local app, such as password managers, are now broken.

https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+...

I had totally forgotten about this! For me it wasn't just the extensions. The font in the "Save Download As…" dialog in the Chromium snap, for instance, has been completely broken for me – all characters get displayed as the infamous glyph-not-found block. To make things worse, the dialog by default suggests some random directory deep inside the snap tree as download destination. Good luck navigating to a folder where you'll find your download again, given that you can't read any of the file or folder names…

I'm not a fan of Snap, but I'm surprised something like this font issue passed QA.

I think you overestimate the amount of QA resources available to the Ubuntu project. Looks like this was an issue that only happened after repeated use and seems somewhat related to individual systems' font configurations?

There's more info here: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+...

I hope they conduct automated testing with screengrabs for high profile apps such as Chromium (that have something to gain from the snap isolation) and that the test cases have this added.

> I think you overestimate the amount of QA resources available to the Ubuntu project.

  s/available to/allocated by/

I don't know that Canonical cares too much about doing QA themselves. It seems like they've decided to delegate that to the userbase.

I've been using Linux for over 14 years exclusively. Build several linux hosting companies. I know Linux rather well. I've built a simple font manager for gnome in the past. I know the weirdness of gnome font thingies.

I've had this glyph issue for over a year. In chromium, Signal, some ebook app, and several other snaps.

I've tried many things. But gave up. Snap is not 'one layer of indirection' too much. It's hundreds of them. There's chroot, some VM, a virtual gnome, containerisation, weird user and permissions. And so on.

This complexity made me conclude that snap is a bad solution (to a real problem). Not the glyph issue, but the fact that I cannot fix it, is, for me, the reason to conclude it has, or will fail.

Wait, since when is Signal a Snap app?

Snap is a distribution format, akin to .msi or .pkg.

No, incorrect. Snap is a distribution format akin to VMDK or anything else which is not intended to be "installed" to a system, but rather run in a virtual machine or sandboxed.

If we are getting into details I think calling it a "virtual machine" is not correct either. Also since snaps have some integration with the host DE through launchers and so on they are not like VMDK's.

To be even more pedantic, there's nothing stopping you from using VMDK (or other disk images like VDI, VHD, raw/dd, etc) files as a container (like tar or zip), other than some extra overhead. They can easily integrate into your desktop environment, possibly even easier since there's probably more support for mounting disk images than there is for mounting archives...

Well, a squashfs file is already a disk image, so that's pretty much what they are doing.

Snap is more like a virtualization tool that you see in VDI and Citrix environments.

It’s sets out to solve a couple of problems in an app-focused way. As with any packager that packages dependencies, it introduces a few dozen more in the process.

Snap is already a standard in the IOT world. It's the desktop section in which it struggles.

This could be related to Why Chrome is using a different font size that the rest my system. Chrome is the only snap program that I have . The rest are plane Debian packages or Flatpack

Right! I ran into this not five minutes into a new 20.04 install and could not for the life of me figure out where the hell my download was, or why I couldn't access /home/julian/Downloads

Why this isn't more of a deal breaker I have no freaking idea.

Snap programs won't let me access /tmp/ which is really annoying ;(

Yeah, and I can find no way to either modify the fs or at least mount out. Opera, I think it is, requires codecs be installed in a specific directory. So, the snap is effectively useless.

I have been using the snap versions of Chromium, Discord, CLion and Spotify for a while now and I haven't noticed any slowness whatsoever. Sure the applications need some seconds (at most 5) to start up on a freshly booted machine but other than that it's pretty snappy (heh). The only issue I have encountered so far is that some applications don't respect the environments cursor theme (looking at you Spotify and Postman) but that's easily fixable by the package maintainers. Other than that I really don't understand the hate-train for snap. Coming from Arch Linux, PPAs seem like a PITA to me and an elegant solution such as the AUR doesn't exist in the Ubuntu ecosystem so snap / flatpak are the next closest thing to it.

The 5 second load time is exactly the slowness people are complaining about. It's a ~100x slowdown.

Most applications on Macs start up instantaneously these days. 5 seconds is 50 times the limit for "instantaneous" feel. [1]

All of the raging discussions in this thread would be totally absent if Canonical had taken the time to make apps installed with snaps fast. Unfortunately, these days, the "make it work, make it right, make it fast" mantra seems to stop at the "make it work". At least the 20.04 release seems to be at that stage.

Congratulations, you just got a bunch of users who are going to avoid updates even more because you are going to make everything slower with your shiny new release.

-------------------

[1] https://www.nngroup.com/articles/response-times-3-important-...

No, most apps are slow the first time they are run on Mac (not as bad as first run of snap though, usually). After that, pretty fast. AppStore apps seem to always be fast.

> Coming from Arch Linux

Genuinely curious, why would you not just keep using Arch?

In my case, too much gardening.

I got sick of it after six years or so and moved to Linux Mint. (This was before Manjaro was widely visible.) Been on Mint ever since: it's a better Ubuntu than Ubuntu, and a better Windows than Windows (for ordinary uses).

Note that Mint 20, although based on Ubuntu 2004, has removed snap from the base install. `apt install chromium-browser' takes you to a web page explaining why.

I'm curious to the kind of gardening you're referring to, that applies to Arch but not Mint?

I will say, Linux Mint is my recommended Debian based distro for desktop use, it really is a better Ubuntu than Ubuntu.

oh my that THAT is why it takes over 5 seconds to start chromium on my Xeon...

That is really disappointing to read. We put a lot of effort into making Chrome start quickly. Back when I was responsible for Linux Chrome, I gave a lighting talk at the Ubuntu Developer Summit about it, and demoed Chrome starting faster than Gnome Calculator.

Not being snarky towards you — Chrome starts really quickly — but was that the snapped calculator from Ubuntu 18.04?

firefox from the ubuntu repository is over 5 times faster to start. on any windows machine, it's almost the opposite. sorry to break the news. for what it's worth I still use it everyday... I usually start my browser once a day so it's not that big of a difference.

Both chrome and Firefox on Ubuntu are basically instant for me. Chrome is installed without the snap rubbish tho.

Hats off, Chrome starts instantly on my Debian machines. Even on a 10 years old, half dead Thinkpad it's just couple of seconds. This must be a Ubuntu/Snap specific issue.

Today, starting faster than Ubuntu's calculator is not that hard. I bet this also became a snap app.

Debian Stable is the last great linux distro. I keep trying to go back to Fedora or Ubuntu but they are so damn buggy.

And as someone living with OCD (the real thing) the whole Snap thing just makes me so anxious. And like you experienced, it is soooo slow. I cannot even go back to windows because for some reason the wifi on my laptop does not work well with it.

I do not care about bleeding edge anymore, but I am a casual user mostly doing genetic research, so Debian Buster with Cinnamon is, to me, the best distro on Linux today.

Debian Sid is also a great option for people who used to be into the bleeding edge Linux distro scene but can settle for Debian's more conservative version of it.

In my dotage, I’ve come to appreciate the Debian Stable cadence: I can just set it and forget it for a year at a time. The mostly-annual upgrades have saved me so much time; everything just works in concert for long stretches of stability.

I've been loving Pop OS! lately. It feels like a "what if" version of Ubuntu had they not spent years pushing Unity, Snap, and their other side projects and just focused on the distro. Super responsive and easy to use, regardless of if you're using free or proprietary software.

> I care about a particular piece of software because it's the reason I use a computer (go, Emacs, Node, etc.) then I just have to maintain it myself. There simply isn't a good way right now.

Don’t do this to yourself! Debian is not going to give you bleeding edge. But there are plenty of distros that can. Despite being a meme, Arch Linux is one of the best distros available, and has been for years. Node, golang, are usually updated within hours of upstream, while the core system remains stable. If you’re looking for something more modern, Solus has been gaining popularity and also has relatively up to date packages. Debian is great for servers.

Manjaro is a really great option too, if you want something Arch flavored that’s a bit more user friendly.

Yeah I've used it for a while with no issues. on my "living on the edge" machine. I still stick with ubuntu for my daily drivers. I don't understand the rant though. I understand why they moved chromium to snap.

Definitely this. Manjaro is out-of-the-box ready, but based on Arch. Manjaro stable is also two more testing steps away from Arch, so the packages are less likely to cause issues. And there are four sources for software: Manjaro repos, the AUR, flatpacks, and snaps. I have never been in a situation where I could not install the latest software via one of those routes. I ran Debian for years and often ran into situations where new software was just not installable due to library incompatibility, etc. Manjaro feels like a Swiss Army knife in comparison.

And with all the options you'll almost never have to rely on snaps.

I couldn’t get Manjaro to install successfully. First operating system I’ve tried to use that just didn’t work. Their easy install thing is a bit too easy, in that it can’t even tell you what went wrong. Also docs were very weak.

I like what they are trying to do but it just did not work for me.

Arch is hard to figure out too with the wiki based docs but at least that’s advertised as unfriendly.

Arch has two major differences from Ubuntu and other non-rolling distributions.

1. You're using latest upstream, after it passed through the archlinux-testing repository. This means you won't have to install software from somewhere else just because the repos are outdated. (nighly builds of software are different)

2. Sometimes you have to sys-upgrade to install/fix something, and you don't have much say in when that happens. Typically you need to preemptively do this about once a week to not potentially get interrupted by manual intervention at a bad time. Yes, you will need to do manual intervention, but you won't spend much time on it. It's far less work than getting up-to-date software running on your debian stable.

my favorite part of arch is using the AUR and customizing PKGBUILDS to suit my needs. I recently was messing around trying to get the emacs native-comp development branch built on my machine. I was running into some issues, then tried in an ubuntu container. Eventually I just fired up my Arch VM, found an AUR package for it, tweaked the PKGBUILD options and dependencies for my needs, and then had it compile on the first try. The build worked great, and once I'd native-compiled everything in my emacs configs, it was super fast to start up even in the VM.

Arch will give you small issues every now and then, but it gives you the tolls to fix them and makes it easy to do things that are much more difficult on other distros.

I can't really agree, to be fair it's been about 5 years since I stopped using Arch so things may very well have improved. But my experience using it as my daily driver on my work ThinkPad was that I kept running into quite a lot of problems every other week from upgrades breaking things, it was of course always fixable but probably spent a few hours every month just on maintenance, this is fine for me on a hobby machine at home but not really something I want in a worn environment. I'm not particular fond of Ubuntu either, it was fine in the 00s but then they lost it, nowadays I primarily use 3 operating systems, FreeBSD, Debian and macOS, they all are somewhat "boring" but also tends to mostly keep working without bothering me to much and most things are easy to look up and well documented.

If you need more control over versions, NixOS is by and far the best choice. You can mix and match versions of software from stable & unstable, depending on your needs.

The point of using Debian or Ubuntu lts is the reverse of getting bleeding edge software. Sure you want your browser and a couple of other software to be up to date but the reset should stay the same and only have critical/minor updates.

Debian absolutely can give you bleeding edge if you just change your repos from their stable release to testing or sid/unstable. Same thing applies to Fedora and pretty much every major Linux distribution.

Sure it technically can. But it’s not how the distro is designed. The testing repos are meant for just that: testing. I’ve run Sid and always had issues with major version upgrades. Rolling release is just a better model IMO.

Fedora is also a solid OS that allows you to easily stay near the bleeding edge.

Honestly, try out Linux Mint. I'm on 19.3 and it's the best OS I've ever used. Convinience of Ubuntu repos and ease of use, no Snap, some fantastic QoL widgets and apps developed for it, a great DE (well, you can choose multiple DEs but I love Cinnamon). If you want a Debian package base you can even get LMDE (Linux Mint Debian addition) which has all the perks of LM, but based on Debian instead.

I want to like Linux Mint but their Cinnamon DE still breaks stuff occasionally that expects either pure GNOME or Unity. Probably the devs' faults for hardcoding it to those two DEs, but still.

At one point Ubuntu had lots of their built-in apps on snap. I distinctly remember firefox starting seconds faster than the simple calculator or system monitor apps.

Indeed. That the calculator takes longer to start than Firefox should have caused the project to be abandoned.

I see the value of file system and dependency isolation, but it shouldn't result in such significantly degraded performance.

Or at least a hard stop on migrations until the performance characteristics were hashed out.

Sadly I noticed a while ago that Windows began to outrun Ubuntu on my older machines; it doesn’t seem like Canonical really cares about performance anymore.

I'm surprised Mark Shuttleworth allowed that. He has a very low tolerance to mistakes.

To me, Ubuntu's glory days were with 10.04. It seemed much more polished than the alternatives at that time.

IIRC Shuttleworth took a more governance and less hands-on role after that, and Ubuntu started to focus on server and enterprise support.

I saw him tearing people down in 2015-ish. And for much less than this.

I've started to use nix (both nixos and nix installed on ubuntu) to manage those critical packages where I want both control and the option for major updates outside the OS's release cadence.

I tried nix on Ubuntu recently so that I could get an up-to-date, non-snap emacs (if you already think emacs is slow to load, you should see it as a snap), and the resulting build was giving me all kinds of issues, even with just the vanilla config. I tried one other package and had issues there as well. I ended up just compiling both from source and they worked perfectly.

Is there anything special about getting nix working well with other package managers? I'll be honest, the main thing keeping me from digging into it further are the docs and the syntax. I can never tell if I'm reading about nix-the-package-manager, nix-the-language, or nix-the-operating-system; and looking at the syntax makes me understand what most programmers feel when they look at lisp.

Yeah the syntax is intimidating. Its definitely one of those things where its easier to start off by copying examples and then slowly learn all the details. After using it for a while it mostly starts to feel like a slightly different JSON syntax (there are a few exceptions to this but you don't end up needing that for most of what you do).

Sorry to hear you had issues on ubuntu. Its hard to say how you might improve your experience without knowing more details. The nix forum is probably a good place to get support for that sort of thing.

I'm sure I could track down the issue, I just didn't have the time. I was just hoping to use it to install a more up-to-date package here and there just to dip my toes in the water and go from there. I really like the idea behind it, and hope it or something similar catches on. I may just have to throw myself into the deep end and try NixOS out in a vm.

Yeah, you kinda have to drink the whole koolaid before it clicks. It’s great when it does though.

It only clicked for me when I started using NixOS (on my primary laptop in my case) rather than just Nix.

How does it compare to using Ubuntu with Ansible? Do you ever miss being on mainline stable Ubuntu/Debian when using NixOS?

On having your system be managed from configuration its sort of similar to Ansible. One major difference is with NixOS you can easily roll back to previous states of the system. That means both rolling back config changes and also rolling back package versions. That's something that Ansible doesn't really give you. NixOS also forces you to configure things the "right way" (e.g. you can't hand edit files in /etc). That is very good for reproducibility, but sometimes its frustrating when you just want to make things work quickly.

I think the biggest challenge using NixOS vs Ubuntu is if you've got some weird obscure piece of software you need to get working there's a better chance that someone has already figured that out on Ubuntu and you might have to do the work to get it running on NixOS.

On the other hand I've found contributing to Nix easier and less intimidating than contributing to Ubuntu. To add a package to Nix you just open a PR in the nixpkgs repo on github. I've found the community to be friendly and helpful.

I use a lot of LXD containers for when I just want play around with something in a non Nix environment.

Oh and I love being able to run `nix-shell -p <package>` to use a package without "installing" it.

NixOS is leauges above Ansible and similar. They are barely even playing the same game.

The TL;DR is that Ansible is given a description for some part of the system, then squints at that part and trys to make it match the description. This means that it doesn't unify anything that you haven't described and if you stop describing something it doesn't go away (unless you explicitly tell Ansible to remove it). This means that your Ansible configs end up unintentionally depending on the state of the system and the state of your system depends on the Ansible configs you have applied in the past.

NixOS is logically much more like building a fresh VM image every time you apply the configuration. Anything not in the configuration is effectively gone (it is still on the filesystem but the name is a cryptographic hash so no one can use it by accident). This makes the configs way more reproducible. It also means that I can apply a config to any system and end up with a functional replica that has no traces of the previous system. (other than mutable state which Nix doesn't really manage.)

Nix has other advantages such as easy rollbacks (which is just a bit more convenient than checking out an old config and applying it manually) and the ability to have many versions of a library/config/package without conflicts or any special work required if you need that.

I wrote a blog post a while ago that tries to go a bit more into detail over what I just described https://kevincox.ca/2015/12/13/nixos-managed-system/

It seems to me that if Nix were a little more beginner-friendly, it could fill a lot of the space Docker occupies.

I was settling up WSL2 the other day and needed Chrome so I could run it headless for some E2E tests I had going. It took a lot of messing about to get a copy of it that didn't use Snap. Partly because apt has always worked great for me and I didn't want to switch with something else, but also because it required systemd to run it as a daemon?

That they clobbered the apt install just to push Snap forward left a bad taste in my mouth.

It's worth noting that you can use Arch and various other distros on wsl[2], not just Ubuntu.

It is not official, like with AUR check sources

http://archlinux.2023198.n4.nabble.com/Windows-Subsystem-Lin...

You can officially use any official image on WSL2 https://docs.microsoft.com/en-us/windows/wsl/build-custom-di...

I don’t understand why it’s so hard. It’s literally visit chrome website and download the deb file and install...

About the slowness - is it just on launch, or does it keep being slow if the app keeps running? A few hundred ms is indeed a deal-breaker for standard Unix-y CLI app that might be chained with 5 other simple apps. It doesn't seem like a big deal though if you're launching something like Chromium that you might normally leave running for weeks.

The problem is that if you use chromium in any automated testing suite, it can get restarted after each test making a test suite take much longer to run.

It's still pretty bad even for GUI apps. Do you really want to add 0.3s to the startup time of Chrome? I would definitely notice that.

Chrome use deb. Also, I do not remember last time I closed chrome. I can remember my whole system breaking because of ppa hell.

have you tried chromium on Ubuntu? It takes several seconds, maybe 10 on my machine whereas firefox loads in under a second.

For me it's just on launch. More precisely, the period before the application actually starts to launch. I guess it has something to do with mounting the various file systems and setting up the connections or whatever it is that it does.

I've had to install Chrome to try a thing or too (so not as a daily driver) and I haven't noticed anything weird during use. I've used Jetbrains' PyCharm daily for a few months and no problem there either (although that is a "classic" snap, not sure if it matters).

Ah I'm glad to finally understand why Emacs 27 starts so slowly: I installed it as a snap (while my Emacs 26 was from a PPA), and I spent a great deal of time trying to find what was the culprit in my init.el config, to no avail.

I switched from Debian to Manjaro after seventeen years this summer. The Arch-isms are odd at first but it is an enormous pleasure to have a system that is up to date, stable, and works with me instead of against me. That and brew for Linux (which is very rarely needed on Manjaro) has vastly improved my user experience. Doesn't address all of what you said, but hope this is useful.

I also abandoned Ubuntu, and after various adventures in distro land I now use Debian Testing with Xfce.

I am currently using Ubuntu 20.04 with the Sabrent Rocket M.2 SSD and AMD Ryzen 3900x and several times my OS continiously locks up some programs for a short time (Chrome, Firefox, etc.) or becomes really slow. This computer I built is relatively new and used for work mostly so I am not sure if it's Ubuntu or I downloaded a stray snap package but man I have noticed Snap packages can be ... slow.

I used Debian and it seems to be gaining detractors from Ubuntu, my only question is... what made you switch and sick with Debian?

I suppose I'm used to apt-based systems, although I don't know if it really makes any difference. So many other distros are based on Debian, but often it seems like a pretty thin layer, perhaps poorly maintained, over Debian itself. Debian seems to have so many more developers, so why not just use it directly.

The rough edges I've found: no automatic updater or security updates in testing, just run apt update/upgrade once a day. An initial problem with the video driver not working because it requires non-free firmware, solution is just to add Debian non-free (it would have been helpful if a warning was given during installation). Firefox/thunderbird still on an old long-term-service release: I've been installing tarballs manually for now.

> I blew up my Ubuntu install and switched back to Debian. I haven't missed Ubuntu at all.

What are the biggest drawbacks? I know you said you don't miss Ubuntu at all, but is there anything which is causing you pain because it works differently or is just missing?

Not sure about Emacs, but node and go can be maintained with `asdf`

I know Snap isolates dependencies... But does it share them if they are common at all? I think this would make the sweet spot...

Reply on news.ycombinator.com