I was wondering where the initial inspiration for Snap packages came from?
Looking at Click packages, it seems as if they are significantly different from Snap packages. Click packages are basically just .deb packages with a few more constraints, no? The main “snap-like” features I see in click are the sandbox and the hooks.
I guess the second part of this question is; “where did the inspiration for Click come from”?
I would tend to say that snaps and clicks are more similar than clicks and debs.
.click packages share the structure of an ar archive containing a marker file plus metadata and data tarballs, there are some pretty big differences:
- Deb packages contain scripts that are run during install time that can do anything. Click packages have declarative metadata describing how they should be exposed to the system.
data tarball of a deb is intended to be unpacked into the root of the file system. A click’s
data.tar.gz is intended to be unpacked into it’s own subdirectory, not mingled with data from other packages.
- Most of the click metadata, such as AppArmor confinement settings, is part of the data tarball, rather than the control tarball.
So despite the different container formats (ar archive vs. squashfs file system), clicks are quite similar to snaps, and are the obvious inspiration.
As for what the inspiration for click packages were, they came out of the Ubuntu Phone project. We wanted a read only system image that could be upgraded as a single unit to the next tested release. It follows from this that user-installed applications cannot be mixed into the base system. The confinement was intended to prevent these applications from interfering with the base system or other applications.
This is very similar to the model used by other smartphone operating systems like Android and iOS.
To expand on what james said already, at some point while the phone project was still alive, I remember @sabdfl explaining the idea behind using a “headless phone system” (image based updates, confined and partially readonly a/b filesystem setup etc) for IoT (you know it as Ubuntu Core today).
clicks were pretty tied to the graphical stack (similar to what flatpaks became today) but for IoT/embedded/robotics/industrial we needed a fully fledged confined packaging system to run system daemons, cli apps and lower level system parts as well so snaps were the next iteration … while the “snappy” project started in 2014 (with a first release of “Snappy Ubuntu Core” around 15.04), we only started to support graphical snaps around the time of 16.04 when it was already well tested as a generic package format for the above use-cases.
I recently cleaned up the Wikipedia page for Snap, but one thing that is unclear is what the “sequence” of support was. Some popular publications about snap mention it was “initially designed for phones” but many other sources imply it’s the other way around. I eventually settled on this sequence:
- Servers (initial Ubuntu Core announcement)
- IoT (quickly after the initial announcement)
- Regular Linux distros and desktop (2016)
Support for UT was being worked on but the phone effort stopped before it came there.
Is this correct?
Snap was started/designed as the click successor while the phone project was still active and running …
Ubuntu Core and the phone OS lived in parallel for a while.
There were the dell 3000/5000 gateways you could buy with a 15.04 based Ubuntu Core version that still used the rootfs setup from the phone (tarballs on readonly partitions, snapd (back then called “snappy-daemon”) was written in python etc).
The design you see today, using the core snap as root filesystem on Ubuntu Core, snaps switching to use squashfs etc came to life between 15.04 and 16.04 with UbuntuCore16 …
The phone was then officially ended in 2017.