You may have seen this toot announcing OpenStreetMap's migration to Debian on their infrastructure. 🚀 After 18 years on Ubuntu, we've upgraded the @openstreetmap servers to Debian 12 (Bookworm). 🌍 openstreetmap.org is now faster using Ruby...
No, those haven’t been an issue for me. I actually like that the snaps include apparmor profiles which I used to have to write myself to constrain what in my homedir an app could access.
Performance, however, is changing over time in ways I’ve never seen before, besides strange hardware hiccups that don’t seem to be logged anywhere. Why does my wifi keep asking for a password at random? What’s up with the weird display behavior when resuming on one vs two monitors? Etc. I figure it’s about time to see what else is out there after almost a decade on Ubuntu.
I moved two servers from Ubuntu to Debian after Bookworm released, and the graphs on my management server were interesting. Suddenly running 30% fewer background daemons and much less memory usage with the same workload.
If snapd was pulling from an open-source backend it wouldn’t be as concerning for me on a desktop. I still might prefer flatpak, but as you say, there are conveniences. My laptops and desktops are on openSUSE and Fedora to have more up to date software in the repos than Debian.
But for a server I see no need for snaps at all. And yes, it’s not difficult to remove snapd, but why bother when I can just run Debian. If I wanted a support contract from Canonical then it might be worth messing with it. But I’m just selfhosting at home.
It’s easy. Just trick your package manager into prioritizing a nonexistent version of snapd so every time a package tries to install the snap version of that thing, the dependencies fail over and over.
Don’t forget to snap remove each individual snap first, and don’t forget the special argument to force it to actually clean everything up, because otherwise it leaves broken trash all over the place, constantly spams your journal, and makes your system state present as Degraded with all the failed unit files and zfs cache pointers that point to nothing.
Oh and one more thing (at least), you have to rip out the /etc/apt/preferences.d file that Ubuntu places and will probably try to automatically repair that redirects apt install calls to snap install whenever possible.
Being force-fed snaps? 🤣
No, those haven’t been an issue for me. I actually like that the snaps include apparmor profiles which I used to have to write myself to constrain what in my homedir an app could access.
Performance, however, is changing over time in ways I’ve never seen before, besides strange hardware hiccups that don’t seem to be logged anywhere. Why does my wifi keep asking for a password at random? What’s up with the weird display behavior when resuming on one vs two monitors? Etc. I figure it’s about time to see what else is out there after almost a decade on Ubuntu.
I moved two servers from Ubuntu to Debian after Bookworm released, and the graphs on my management server were interesting. Suddenly running 30% fewer background daemons and much less memory usage with the same workload.
If snapd was pulling from an open-source backend it wouldn’t be as concerning for me on a desktop. I still might prefer flatpak, but as you say, there are conveniences. My laptops and desktops are on openSUSE and Fedora to have more up to date software in the repos than Debian.
But for a server I see no need for snaps at all. And yes, it’s not difficult to remove snapd, but why bother when I can just run Debian. If I wanted a support contract from Canonical then it might be worth messing with it. But I’m just selfhosting at home.
it’s very easy to disable and use alternative sources
Is it? Easy? How does one do that?
apt purge snapdIf you use firefox there’s an official mozilla PPA you can add to get normal packages back, not sure about other browsers.
There’s also another apt command to “hold” and/or pin the snapd package so it won’t accidentally get reinstalled later.
It’s easy. Just trick your package manager into prioritizing a nonexistent version of snapd so every time a package tries to install the snap version of that thing, the dependencies fail over and over.
Don’t forget to
snap removeeach individual snap first, and don’t forget the special argument to force it to actually clean everything up, because otherwise it leaves broken trash all over the place, constantly spams your journal, and makes your system state present as Degraded with all the failed unit files and zfs cache pointers that point to nothing.Oh and one more thing (at least), you have to rip out the /etc/apt/preferences.d file that Ubuntu places and will probably try to automatically repair that redirects apt install calls to snap install whenever possible.
Child’s play.