I’m afraid for the future of Ubuntu.
Ubuntu is an open source software platform that runs everywhere from IoT devices, the smartphone, the tablet and the PC…www.ubuntu.com
Ubuntu prides itself on being the most used cloud operating system. http://www.zdnet.com/article/ubuntu-linux-continues-to-rule-the-cloud/
One of the great strengths that ubuntu in the cloud is its foundation of core linux packages which just work. When you want to use haproxy, you apt-get install it and it works. When you want to use apache httpd, you apt-get install it and it works. When you want to use mysql, or postgresql, or mongodb, you might use the built in, or you might add a 3rd party repository to run a version newer than the ubuntu LTS release you are using on the cloud. When you want to diagnose a running system you can trust that dstat, iotop, sysstat, monit, atop, will all be there to help you.
Another strength with ubuntu is that it is reasonably small. The root tarball, which is what you would need to build a container image for docker, is only 226MB gzipped or 146MB compressed with LZMA (xz). Whenever I spin up a new image I always imagine that tight little image decompressing and processes starting, even though in practice it is already decompressed.
For almost all PCs. This includes most machines with Intel/AMD/etc type processors and almost all computers that run…cloud-images.ubuntu.com
From that tiny image, cloud-init lets me change the starting point of my new system image, no matter where I am running. The same cloud-config is used in Azure, AWS, Google Cloud, OpenStack or LXC/LXD.
Unfortunately, AFAICT, some folks at Canonical don’t value these great things. Instead, there is some initiative to replace great, tiny, fast packages with bloat in the form of Snappy.
Introducing snaps on Ubuntu, the new way to install, update and find apps.www.ubuntu.com
Now, do not get me wrong. Snaps have their place. Snaps solve a couple of very important problems. The problem is, they aren’t problems that I’ve ever had. The first thing that snaps do better than debs is install and upgrade transactionally. If there is a problem, the whole thing rolls back and you can continue using the current version. The second thing that snaps do better than debs is that they do not follow the debian packaging guidlines of one and only one version of a library. This actually has nothing to do with snaps. Debs can be build with their own versions of libraries. In fact, if you look at the chrome package and I think even the chromium package which ships with ubuntu, you will find duplicates of packages included in ubuntu.
A great deal of this move to snappy is fueled by their ubuntu touch background. A phone is not a server or a desktop. A cloud server is not a server. A cloud server is not a phone. It seems as if no one stopped and thought about how to best utilize this technology and instead applied it, because they could.
One of the things which makes ubuntu fast in cloud is those tiny images. Things start fast. Security updates are small and apply fast because the default installed package list is small and so there are very few updates to apply. Snappy bloats this by requiring snappy core, another 200+MB ubuntu image to be installed upon which all the other snaps depend. So you’ve just spun up a new cloud image and its size just nearly doubled. So much for fast.
But wait, it gets worse.
Ubuntu was founded and initially driven by bug 1, https://bugs.launchpad.net/ubuntu/+bug/1 which states software should be free and accessible to all. The free implied here is free as in freedom, not beer. The bug goes on to link to the gnu.org free software definition and the Debian Free Software Guidelines (DFSG). Snappy seems to throw away the traditions of how ubuntu is developed using these guidelines.
Snaps are built using a tool called snapcraft and distributed via a walled garden called snap stores. https://snapcraft.io/docs/core/ The stores do not include any sourcecode. One of the reasons and benefits of debian packages including source debs is that you, as the end user can validate and verify the binary packages by building them yourself. You are free to change them and rebuild them and install them. There are no walled gardens. In the case of the ubuntu snapstore, you may not even know with which source code the snap has been built. You may not even be able to rebuild those snaps.
But wait, it gets even worse, still, again,
Take a look at https://www.ubuntu.com/desktop/snappy and focus on the “always fresh” phrase. This isn’t hamburgers or produce at Whole Foods. Software going stale may be the design you wanted for your cloud application. I’ve worked with cloud applications in which the system instances are never upgraded. They are rebuilt and replaced. This is a common and good cloud design principle. It removes complexity and it reminds you to treat your instances as herd animals, not pet animals. I like to go further and say as crop plants. Grandpa used to name a few cows in his herd. Mom names house plants. I don’t know of anyone who names the corn stalk or soybean plan in the field. Anyway, snappy does not let you control when things are upgraded. The snappy system automatically upgrades your applications from the snap store. You cannot disable this. Someone could update a snap application with code which says, “send all of your secret keys somewhere”. You have no way to control when updates are applied? Think I’m overreacting?
I’ve done the job of analyzing each and every diverging patch and update in new releases of system images. It is real. People do it. People concerned about security and uptime and performance and all those devops things we say we care about actually do these things because we do care about them.
Packaging software is hard. Don’t believe me? Docker successful largely because its a punt on packaging software. Instead of making an application installable, the software developers decide it is easier to simply ship an entire OS image which is capable of running the software. Packaging software is that difficult.
Snappy throws away the history of well known tools, reproducibility, and control that has made Linux the defacto standard for cloud and server operations over the past 10 and 20 years respectively. It pushes the reset button. You get to learn all new tools while sacrificing control.
When you click on community and support and go to https://snapcraft.io/community/ the first link says to ask a question on Stack Overflow. If you follow that link you quickly learn that it is an abandoned support channel. There are questions from half a year to a year ago with no answers.
Making a snap for trivial software which already is trivially packagable is easy. Snapping up complex software becomes a nightmare of complexity and unlike the 20yrs of debian history which may help you, there are no tools. You are on your own.
There are also a couple of projects surrounding Canonical’s Juju system which are distributed only using snaps: Conjure-up and Charm-tools.
https://jujucharms.com/docs/stable/tools-charm-tools
Both are really slick pieces of software, however, every time I use one, I ask myself, “why isn’t this a deb” Why did I have to install this as a snap? I sure hope screws up the next release and includes a backdoor. Just who is pushing this snap to this snap store?