You can update as often as you like, but that does not ensure users will get that update, nor does traditional packaging make it safe to install the update (no rollbacks, maintainer scripts run as root and have full access to the filesystem, library mismatches, etc).
I'm all for debs and rpms, but they seem best suited to providing the base system.
Snapcraft (https://snapcraft.io) | Senior Software Engineer | REMOTE | Full time
The Snapcraft team at Canonical (Ubuntu) are trying to make it easy to deliver app updates to all Linux-based cloud, IoT, and desktop systems safely (confinement, rollbacks) and automatically.
We're motivated by making developers' lives easier. We want to see people spend time on what makes their app unique and interesting, not on packaging. We also understand that developers currently face an impossible choice between few updates to lower the risk of breakage and frequent updates to lower the risk of compromise.
The open position is for a Senior Software Engineer. We want someone with years of war stories building developer tools to help re-architect the core of Snapcraft (https://github.com/snapcore/snapcraft). It needs to integrate deep into Python, Node, Ruby, Electron, and others so that releasing your app for tens of millions of Linux users is a natural extension of setup.py or npm run.
Snap is a proprietary format that is canonical-centric, don't tell me that the community make choice to make client opensource but official store both hardcoded (initially) and closed source.
On the other hand,flatpak is a freedesktop project, done using open standards like OCI and ostree.
No. Snap is not a proprietary format at all. It's a squashfs file with a small amount of metadata. You can make a snap by plopping a file in a folder, add a simple snap.yaml which describes the application and then "make" a snap with the common mksquashfs tool.
There is room in the world for flatpak and snap to co-exist. We created snaps as an evolution on from clicks on the Ubuntu phone, and it covers use cases that flatpak wasn't designed for.
Thanks I did not realize it was cross platform. It still disregards too many free desktop standards for me however. Feels like Unity when it comes to Canonical’s NIH syndrome.
Because the same snap can run on releases of Ubuntu all the way back to 14.04. 14.04 has VLC 2.1 in the repo. 16.04 LTS has VLC 2.2. The snap store has 3.0.1 in the stable channel, with 4.0 (dev release) in the edge channel. Versions that will never be in the archive of those older releases.
As LTS releases age, the contents of the repo age with them. PPAs are one solution, but they're undiscoverable and not straightforward for new users to setup. Ubuntu has a ton of users who are 'sticky' on old LTS releases.
This enables the VLC developer to have one package that targets millions of users across lots of releases of Ubuntu - and other distros too.
I work for Canonical, but I also share maintainership of some snaps. From an automatic email I received recently:
“A scan of this snap shows that it was built with packages from the Ubuntu archive that have since received security updates. The following lists new USNs for affected binary packages in each snap revision:
…
Simply rebuilding the snap will pull in the new security updates and resolve this. If your snap also contains vendored code, now might be a good time to review it for any needed updates.“
Yes, you don’t get that library update everywhere all at once, but this gives each vendor a chance to make sure that update actually works with their app.
Canonical’s Snapcraft (https://snapcraft.io) makes it possible to deliver app updates to all of Linux automatically, eliminating the long tail of supported releases and complex install instructions.
With thousands of applications on the platform from over a thousand developers, including well-recognised names like Spotify, Slack, and Microsoft, the Snapcraft team’s mission is to uphold a high bar of quality as well as predictable, intuitive behaviour.
We are looking for an experienced software engineer with background in developer tools to join our globally-distributed, home-based team.
We're growing the Robotics team at Canonical (the company behind Ubuntu):
* Robotics Engineer: https://boards.greenhouse.io/canonical/jobs/1535166
* Robotics Security Engineer: https://boards.greenhouse.io/canonical/jobs/1550997
* Robotics Developer Advocate: https://boards.greenhouse.io/canonical/jobs/1541376