Ubuntu's Desktop-Next Switching From .DEBs To Snappy

[mangecoeur]

I still don't fully understand how snappy packages resolve their dependencies. Are they all bundled with the application or are there runtimes that serve as a base platform for the application. That would potentially allow other distros to also allow the installation of these runtimes and applications without the developer having to worry about the app not working (kind of like Steam Runtime). At the same time other distros would not have to worry about these runtimes and apps potentially breaking the rest of the system.

Snappy packages bundle their dependencies if I understood correctly - they require only the Ubuntu core system. However user apps should instead come as Click packages (at least this is how mobile works). The snappy images just provide the base system while click packages take the role of "apps". As a desktop user you shouldn't need to deal with snappy packages.

[Cerberus]

I think the best thing is that this decouples applications from Ubuntu version and puts control back into the hands of upstream developers about updates and distribution of their software. The fact that there are for example probably 5 Tuxracer packages on Ubuntu for the different versions of Ubuntu and all packages are again different versions of Tuxracer is ridiculous.

I still don't fully understand how snappy packages resolve their dependencies. Are they all bundled with the application or are there runtimes that serve as a base platform for the application. That would potentially allow other distros to also allow the installation of these runtimes and applications without the developer having to worry about the app not working (kind of like Steam Runtime). At the same time other distros would not have to worry about these runtimes and apps potentially breaking the rest of the system.

I believe Snappy applications bundle the dependencies they need, but I am not 100% sure. This will also enable users to get constant updates for applications via Ubuntu Store because afaik all kinds of snap packages will be in the Store, no more PPAs as people will repackage their debs into snaps and upload them to the Store, from what I heard repackaging your software into a snap package is easy and doesnt require advanced knowledge. And yes this could work on other distributions if they also have a Snappy-like base.

In Snappy based Ubuntu the OS is separated from the applications, OS will also be easier to update and there will be some form of rollback which is very useful if new kernel doesnt play well with your hardware, you can simply rollback to the older Ubuntu version that works for you, applications will be unaffected afaik. This way Ubuntu will become somewhat of a semi-rolling distribution.

If other distributions eventually accept this way of working with applications it could solve the problem of maintaining and updating applications for so many distributions out there. And it is important to say that .deb based images will likely still be available for a while until the final switch is done in the future, they are planning parallel editions I believe at first, you can have .deb Ubuntu and Snappy Ubuntu. Base system iso even for Snappy versions will still be built with debs, so the deb base is not going away.

[Sundance]

So why would they come up with a new one instead of using Wayland, then it's much easier to use it instead of making a new server from scratch?

That's a GOOD question.

As far as I remember, they had two main issues with Wayland. One is that in Wayland, buffers are client-allocated. But Canonical explicitly wants to target the mobile market, which means contending with both ARM architecture specificities and power management issues, and they claim that server-allocated buffers are necessary on both counts. Ergo, Mir.

The other issue is that Wayland is a protocol and Canonical wanted a server. At the time Weston was a bit of a prototype and a moving target, which Canonical felt wasn't good enough. I kind of feel they could just have made a Wayland server, then, and called it a day, but of course hindsight is always 20/20.

I find the main difficulty when designing new shit is to solve the right problem. I don't know if Canonical is tackling the right problem here with Mir, and honestly I'd rather see less fragmentation, but hey, just so long as Wayland is an apt-get away, more power to them. Hopefully, in the long run, either Wayland will evolve server-allocated buffers or those will turn out to be unneeded after all, and Mir will become a solid Wayland compositor that everyone can use. One can hope. (Compositor fragmentation is one of my main concern with Wayland, honestly. So much duplicated work.)

[Passso]

Post seems to be a bit confused about the relation between Snappy and Click. The goal of Snappy is to create fixed based OS images that provide strong guarantees on what software is included. Click packages then take the role of providing user "Apps". They bundle all dependencies that are not included in the Snappy base image.

In the .deb package model, the base system was a collection of deb packages, and additional software you install was more .deb packages. There isn't a distinction between the "OS" layer and the "End User" layer. One advantage is that packages can share dependencies which can save space. However it means everything has to be packaged together - to get the latest software it has to go via the main software archive. You can use PPAs but then you lose any guarantees from the main archive that everything actually works.

Today, we have a) lots of storage space an b) users who want software updates much much faster than even Ubuntu's 6-month release cycle. The snappy idea started on mobile where you want a completely fixed base OS that is guaranteed to work for a particular device and then allow people to install all the Apps they want without this messing with the base system. So they made a fixed base image plus the Click package system. Then Canonical realised this actually works well for loads of other use cases - first in the hot new "container" space (Docker images and friends), then for Internet of Things devices (c.f. their Snappy image for Raspberry Pi) where again you target specific hardware then add your custom apps on top, and now it looks like they want to do it for desktop too. From what I understand of the security model this is actually a really great idea. At the moment you should never install a random .deb on you machine since you have no idea what it might do to your system. Click applications live in a sandboxed environment and can't alter the Snappy core system, so you can install Clicks with much less risk of breaking everything.

Also AFAIK Click packages share most of the internal plumbing with deb packages, with limitations on running system scripts and other potentially insecure things...

At last someone who understand the advantages of Snappy!

Now to be honest :

- if you ONLY stick to official software it has low benefit and .deb is just perfect (~80% of users)

- BUT whenever you do need proprietary softwares (from Oracle, VmWare and others) the .deb is a mess because if it not created for your distro AND version you will never ever get it working

I went so many times into errors like "requires libffs.1.6 but only libffs1.59 is available". So you download another version, force and then you have a really really hard time... because you broke 296 dependencies and softwares.

Included libraries will make both small devs and big companies happy!

(btw can we please stop Canonical / Steam / shaved-man automatic bashing)

[Cerberus]

At last someone who understand the advantages of Snappy!

Now to be honest :

- if you ONLY stick to official software it has low benefit and .deb is just perfect (~80% of users)

- BUT whenever you do need proprietary softwares (from Oracle, VmWare and others) the .deb is a mess because if it not created for your distro AND version you will never ever get it working

I went so many times into errors like "requires libffs.1.6 but only libffs1.59 is available". So you download another version, force and then you have a really really hard time... because you broke 296 dependencies and softwares.

Included libraries will make both small devs and big companies happy!

(btw can we please stop Canonical / Steam / shaved-man automatic bashing)

If this solves the dependency issues we currently have and keeps applications always up to date, everyone should go for it, some will not but some distributions might see the advantages of snap packages.

[Passso]

If this solves the dependency issues we currently have and keeps applications always up to date, everyone should go for it, some will not but some distributions might see the advantages of snap packages.

I do really think this is the main purpose: enable every "independant" software to run for years and on a large scale of Linux OSes.

If you look the Linux soft list of some companies on their website you will see that a lot of them stopped shipping versions because they need to create 5 flavors every 6 month... (Even for an archived tool/project!)

(Who cares about "speed" for updates, they take hours on Windows for 3 patches on IE and nobody whine )

[GreatEmerald]

Mir is working Wayland as Canonical said still is a work in progress, and Mir is working at Ubuntu phone with android drivers, and nobody knows when Wayland will work on phones. I do not use Ubuntu, but as a business it seems they are doing well.

Wayland has been stable for over three years now. Three. Years. And Sailfish OS is now over two years old. So Wayland on phones has been working for over two years now, flawlessly.

At least Ubuntu is still GNU/Linux and you can port to other distros, if you want, their approach, I do not know why Unity is not well supported at other distros, specially Fedora or SUSE at the business market as well as Gnome is supported at Ubuntu or why the successful arch and derivatives community also do not provide a good Unity experience.

Because Unity is a total hackjob. It's not written in a portable manner. It was hell to get it to run on Arch, and nobody else is willing to go through that hell.

Yes, but I'm sure you remember that Gnome Shell looked entirely different back then. The modern versions of Gnome Shell have simply copied the original Unity design that they initially rejected. That's a good thing, because the original Gnome Shell was really horrible.

Actually, I don't use GNOME Shell, but from the videos I've seen of the early GNOME Shell, it was way closer to Unity than GNOME 2. And either way it doesn't explain why they didn't just maintain Unity as a shell for GNOME.

Now to be honest :

- if you ONLY stick to official software it has low benefit and .deb is just perfect (~80% of users)

- BUT whenever you do need proprietary softwares (from Oracle, VmWare and others) the .deb is a mess because if it not created for your distro AND version you will never ever get it working

I went so many times into errors like "requires libffs.1.6 but only libffs1.59 is available". So you download another version, force and then you have a really really hard time... because you broke 296 dependencies and softwares.

Included libraries will make both small devs and big companies happy!

I agree. However, as you said, 80% of people don't need that. Meaning, why isn't it simply a DEB package by itself? If you need to install something proprietary, then install and use Snappy, otherwise stick to DEBs. Simple.

If this solves the dependency issues we currently have and keeps applications always up to date, everyone should go for it, some will not but some distributions might see the advantages of snap packages.

The problem being that Snappy is not the only option. The systemd developers have already announced their own vision of it, and it doesn't include Snappy. Meaning further fragmentation...

Actually, I can't even find any information on this Snappy/Click. Only Klick, but that is seemingly abandoned. And Snappy is a compression algorithm. What gives?

[Passso]

I agree. However, as you said, 80% of people don't need that. Meaning, why isn't it simply a DEB package by itself? If you need to install something proprietary, then install and use Snappy, otherwise stick to DEBs. Simple.

Managing upgrades with 2 systems... I don't even wanna try!
Now we came at the end of .deb possibilities, so we need a new way to manage softwares.
There will be work, there will be bugs, but I bet Canonical will do it

(Btw if I follow your way of thinking Office 97 should still be the #1 productivity suite :
Office 97 was enough for 99% of users, Office 2000 99%... .... Office 2010 99%, Office 2013 )

[mike4]

The problem being that Snappy is not the only option. The systemd developers have already announced their own vision of it, and it doesn't include Snappy. Meaning further fragmentation...

Actually, I can't even find any information on this Snappy/Click. Only Klick, but that is seemingly abandoned. And Snappy is a compression algorithm. What gives?

https://developer.ubuntu.com/en/snap.../#snappy-local

Haven't tried that yet. But yes Linux future looks fragmented to me.

[Cerberus]

Managing upgrades with 2 systems... I don't even wanna try!
Now we came at the end of .deb possibilities, so we need a new way to manage softwares.
There will be work, there will be bugs, but I bet Canonical will do it

(Btw if I follow your way of thinking Office 97 should still be the #1 productivity suite :
Office 97 was enough for 99% of users, Office 2000 99%... .... Office 2010 99%, Office 2013 )

https://developer.ubuntu.com/en/snappy/

Snappy already works on clouds and Internet of Things, I believe Ubuntu Touch also uses something similar like transactional updates and click packages. They likely saw that the idea behind Snappy works really well and thus plan to implement it on the desktop. I hope to see optional Snappy Ubuntu with the release of 16.04 LTS, if they say debs are easy to convert to snap packages, and with the experience with the cloud, Internet of Things and the phone, the transition should not take a very long time, maybe a few cycles at the most or so I hope.