Use Snap for Certbot or 'apt'?

(Why did Ubuntu invent Snap? What is wrong with 'apt'?)

To lock you into Ubuntu… although snapd is open source & available on other distros, Ubuntu is the only one that uses it widely.

This means that most snaps only work on Ubuntu.

To lock you into Ubuntu

It looks like most of the snaps are for desktop versions of Ubuntu.

https://snapcraft.io/store

And I fail to see how a snap package locks you into anything? Does Ubuntu make any software that is proprietary to their system… similar to Apple and its message system or Microsoft and its Flight Simulator program?

If Ubuntu wanted to lock you in they would not put the snap system into open source.

My guess is that snap is going to eventually replace the "apt" system.

If Ubuntu wanted to lock you in they would not put the snap system into open source.

There are other ways to accomplish lock-in besides with software licenses… Besides, the GNU Public License, which governs snapd and all its derivatives, requires it to be open source.

Let's suppose you have significant intellectual investment in snapd -- tribal knowledge, training, adjunct shell scripts, etc. How likely is it going to be for you to, all of a sudden, switch from Ubuntu to, say, Fedora? On Fedora, you can still have snapd, but you have to build/manage/test it yourself (from the source code)…and none of the snap-ins on which you rely function.

I would say you would be mighty reluctant to use Fedora. That's lock-in…

My guess is that snap is going to eventually replace the "apt" system.

You would be guessing wrong. apt comes from Debian. Debian is Ubuntu's upstream parent. As long as that relationship remains, apt (and it's backend dpkg) are always going to be there.

See here: https://ubuntu.com/blog/whats-in-a-snap
and then see here: https://devconnected.com/apt-package-manager-on-linux-explained/

You can see that snap-ins and apt packages are very different.

Let's examine your certbot example… To install certbot, you would need certbot and all it's dependencies -- a python3 interpreter and a zillion support libraries. Let's suppose you also install borg backup -- which also requires python3, some of those same support libraries as certbot, and some other stuff.

With apt, you get one python3 interpreter, one copy of all the common support libraries, and one copy of the unique dependencies for each of certbot and borg.

Snap-ins are self-contained. So, if you install the snap-ins for both certbot and borg, you get two python3 interpreters, two copies of all the common support libraries, and one copy of the unique dependencies for each of certbot and borg. Oh…and as an extra added attractions…the python3 interpreters and the common support libraries for each could be of differing versions.

Suppose you write a python3 script that integrates certbot and borg logs (for whatever reason)… Which python3 interpreter and common support libraries do you use? What if you pick one but one of the support libraries has a bug in it and (GASP!) you run into it? What if the bug is fixed in the other version of the library? What do you do?

Canonical thinks that snap-ins are easy. They may be…for Canonical…they don't have to do the dependency-checking/-testing required for apt packages. For the life of me, I can't think this would be easy for anyone else. That's lock-in…

Canonical claims that snapd is distro-independent and not controlled by them at all but, guess what? All the seats on the snapd foundation steering committee and all the development positions are filled by Canonical people. From that perspective, it hardly matters that you can get snapd source from github to run it on Fedora. Everything about the direction/development/documentation of snapd and it's derivatives is controlled by Canonical. That's lock-in… This is why virtually none of the other distros use or promote it.

Because of all this, when I was an Ubuntu user, I avoided snap-ins like the plague.

-- sw

SW: Thanks for the info. Many of us could not use Linode without YOU!!

Linode (Akamai) should pay you. If you go to D.O or some other cloud server vendor, I'll be right behind you!!!!

-ANC

[editorial]
One thing about D.O. is that their docs are more up-to-date (for Ubuntu 22.04) than Linode.
[/editorial]

[editorial]
One thing about D.O. is that their docs are more up-to-date (for Ubuntu 22.04) than Linode.
[/editorial]

But, they have virtually no docs at all about FreeBSD (my platform of choice)…even though they "support" FreeBSD.

Also, DO claims to have rules about doing bad things to others using their platform, but, AFAIK there is no enforcement. So, the proliferation of spambots and brute-force attackers on DO is rampant…and tacitly tolerated (IMHO).

At one time, I had a rule in my firewall that blocked every network in DO's ASN. Now I have a better firewall…

I'd never go to DO. I'm too old to be dealing with that kind of s***…

-- sw

Snap-ins are self-contained.

So it is like a Docker file? I kind of like the idea of self-contained apps… you escape dependency-hell (although the apt system does a good job mitigating that long-time Linux irritant (as I remember from my Slackware days.) So you have several copies of Python. Storage is cheap.

FreeBSD (my platform of choice)

I ran FreeBSD on a managed platform, pair.com, for 15 years. FreeBSD was their only choice… until about 4 years ago they offered Ubuntu as an option… and then about a year ago they just dropped FreeBSD and moved their thousands of servers in their server-farm to Ubuntu.

From what I read, FreeBSD is being abandoned by all but the very largest of customers. (And as you know, it never was adopted as a desktop system by more than a few diehards who came from Slackware days! :-) )

I'd like to see a renaissance of FreeBSD but I don't expect it is going to happen. It is now a Linux world, like it or not.

I'd like to see a renaissance of FreeBSD but I don't expect it is going to happen. It is now a Linux world, like it or not.

For you, maybe. I'm quite happy!

See: https://www.fossmint.com/what-is-freebsd-why-should-you-choose-it-over-linux/

NO systemd!

For example, I did an OS version upgrade (13.1-RELEASE-p2 -> 13.1-RELEASE-p3) on 3 systems in place in about 1.5 hours (my Linode and my 2 systems at home). That included building a new (custom) kernel for each.

How long does it take you to spin-up/outfit a new Ubuntu system? ;-)

(And as you know, it never was adopted as a desktop system by more than a few diehards who came from Slackware days! :-) )

FreeBSD was never designed to be a desktop system. You can run desktops on it (quite well, IMHO) but it's a server system. Linux, on the other hand, was never designed to be a server system. IMHO, you'd have to be some kind of glutton for punishment to run mission-critical servers with Linux. Google does it…but they have a server-replacement program that is nonpareil (that must cost them a lot of money to support).

I'll stop this rant here.

-- sw

So it is like a Docker file? I kind of like the idea of self-contained apps… you escape dependency-hell (although the apt system does a good job mitigating that long-time Linux irritant (as I remember from my Slackware days.)

I don't know. I don't have any experience with Docker (or any of the other container systems currently en vogue).

So you have several copies of Python. Storage is cheap.

For me, the issue of "Which python do I use for development?" is the key one here. You, as a developer, are in for major pain if you use one and there's a 3-way compatibility issue you run into during the course of development.

Maybe I'm too old school…less tolerant of crap like this than younger folks… This seems like a pitfall that can be easily avoided.

Storage is cheap…but not free… Why would you tolerate Canonical telling you how you have to spend your money?

-- sw

What is wrong with 'apt'?

I think that, specifically within this context of “installing certbot”, there’s a couple points to be made.

apt and snap have different philosophies, as other people have noted here. Specifically apt is very conservative in its updates. For Debian especially, which is where I was coming from, the package updates to apt go through a long testing process, with the result being that many packages are behind the latest release, sometimes by years.

Snap, on the other hand, can cycles releases quickly, because of its self-contained nature. Since nothing inside the package will potentially conflict with anything else on your system, it can send out updates whenever it wants.

I believe Let’s Encrypt suggests snap as an install mechanism in their documentation because they’re dealing with security, and they believe that quick updates are important for any security-related package. If some security issue were discovered in certbot, they could send out an update immediately without having to wait for the whole Debian release process.

When I first installed certbot on my Debian 10 server, I used snap, because the version of the package in Debian 10 was so old I don’t think the Linode plug-in even worked with it. But I was never really comfortable with snap. It has a lot of overhead, especially since I was only using it for that one package. I also didn’t like how it cluttered up my home directory with its own required subdirectory paths.

When I upgraded to Debian 11, the version of certbot there was sufficiently modern that I felt comfortable using it, so I deleted snap and switched to apt.