LWN: Comments on "Shuttleworth: X marks the spot"

Shuttleworth: X marks the spot

flussence — Wed, 28 Oct 2015 16:46:30 +0000

We'll be stuck with X11 *and* /usr/lib32/ in Ubuntu-land for at least one standard enterprise upgrade-cycle now, despite the fact it's nearly impossible to buy new x86-32 hardware, thanks to Valve sinking their teeth into it.

Shuttleworth: X marks the spot

raof — Mon, 26 Oct 2015 05:10:50 +0000

Heh. We'll be shipping X11 for at least the next decade. GTK3 and Qt5 (and SDL2, and...) will work fine on a Mir compositor, but everyone's going to have that one GTK2, Qt4, Xt, wxWindows, or whatever app that they'd like to run.

Shuttleworth: X marks the spot

khim — Sun, 25 Oct 2015 22:43:08 +0000

Thanks for showing me that article. It really shows the problems with Nix and Snappy strengths very well. Yes, you've heard me right: Nix weaknesses and Snappy strengths, not the other way around.

You just need to squint just right while you are reading that piece.

It lists many “Snappy problems” but try to ask yourself every time you read that Snappy couldn't not do this and couldn't do that: why would you want this or that? The answer is always the same: to make life of maintainer easier, to give package maintainer more power, to help maintainers in their work.

Well, guess what: Snappy in not developed to give more options for the Debian and/or Ubuntu maintainers! Quite on the contrary: it's completely separate subsystem which is designed for a completely new world. For the world where maintainers don't exist!

Package does not keep track of versions of libraries it depends on and either stores them in package itself or refers to the [large] framework? Of course! How else could it be work if noone is tracking API changes in all the bazillion libraries involved? All that “reuse-degree” could only exist in the Linux distributions world because there are someone who supports (as in: constantly rebuilds) all the packages—and in Snappy world there are noone who could do that. Developer wouldn't bother and noone else could do that because in 90% of cases they wouldn't have sources!

Frameworks require approvals and could only be referred by the name? Sure! How else could it work in a world where packages are released (in binary form, mind you) just once and used for a decade? Someone must keep framework in good enough (as in: compatible) shape over all these years. Most likely Canonical will sign some agreements with the framework providers… or may be will help them in their work, but in any case: an idea that you would refer to the dependency by it's version does not fly in a world where packages are no regularly rebuilt!

And so on: try to imagine a world where developers distribute packages and users use these packages and where there are no build farms where such packages are regularly rebuilt… and you'll see why Snappy does what it does.

Is it perfect? No, of course not: just from the description I could see some problematic pieces (question of who and when will decide what permissions to give to a particular package comes to mind). But even so: from the description you could easily see that Canonical guys did their homework and consciously removed some [mis]features from Guix/Nix to come up with Snappy!

Time will tell how well Snappy will work, but I like what I see so far. This is clearly step in the right direction.

Shuttleworth: X marks the spot

fredrik — Sun, 25 Oct 2015 18:57:33 +0000

jspaleta wrote:

> [...] the saneness of the application security policy is
> validated when the snaps are uploaded into the store,
> not on install.

You make that sound like a good thing, but to me it sounds like a weakness of Snappy. Why wouldn't the end user want validation and security enforcement on install too?

I haven't read the Snappy spec, so maybe that's covered?

Preferably I'd like validation both when an app is published to the store, so I can use the required privilege list to filter app selection, and again when I install the app on my device.

I can live without validation in the store, but giving unknown packages carte blanc to run unknown scripts with root privileges at install time is really something I'd wish the Linux package management systems would move away from.

Nice to see...

ncm — Fri, 23 Oct 2015 23:46:29 +0000

Nice to see them getting close to the end of the tour. Three more releases, and they can wrap up and move on, maybe retire.

Shuttleworth: X marks the spot

drag — Fri, 23 Oct 2015 16:29:00 +0000

If it can manage xdg-app installs may make a huge win. And/or (especially) if it can get adopted by a group like CoreOS. People interested in newest tech are going to be much more likely to get exposed to the benefits of Nix while exploring methods to manage large numbers of applications in 'the cloud'.

There is a huge number of people in the Linux environment that remain blind to the limitations imposed on users and the problems caused by traditional Linux packaging schemes. So I expect there will be massive resistance towards somebody like Debian incorporating significant architectural improvements to using things like Nix or xdg-app-style application containers. I know that Nix can install on any distribution, so that could be a way for users to by-pass the politics of their preferred distribution.

Shuttleworth: X marks the spot

pbonzini — Thu, 22 Oct 2015 19:56:58 +0000

> all the amazing work going into LXD and KVM for Ubuntu OpenStack

If I had a million dollars for every song I've sung^W^W^W email someone@canonical.com sent me last year... I wouldn't notice the difference.

Shuttleworth: X marks the spot

jspaleta — Thu, 22 Oct 2015 17:10:19 +0000

The blog analysis you posted missed pretty much the most important part of why snappy exists.

Take a real close look at how the application security policy works and the role that uploading into the Canonical controlled store plays in validating the security policy. Once you wrap your head around that, you'll maybe start to understand why Canonical invested time and resources into snappy instead of adapting another package manager.

And honestly, regardless of whether snappy is the technically most superior application deployment/management solution out in the wild right now.. I think snappy as an architecture is probably the better fit for Canonical as a business than other options and will continue to be so.

The application security guarantees being made are contingent on driving applications through Canonical's centralized store. Sure you can install snaps manually from other locations...but the saneness of the application security policy is validated when the snaps are uploaded into the store..not on install. A snap can basically ask for full permissions in its security policy payload. On upload to the store that policy will be checked and flagged for manual review if the requested permissions are too open.

Making their store front central to the security promise makes it possible for them to monetize for-pay app deployments. If users on their consumer device platform and IoT platform are going to be paying cash for application level functionality...Canonical will finally have the leverage to get their share of the revenue for providing and maintaining the secure platform.

I'm not saying its going to work or that it's brilliant...but I do understand why snappy exists.

And of course this also implies no 3rd party repositories in practice. And because the store backend is still being held as proprietary... distributions like Debian won't be able to easily adopt the same sort of scheme without spending the time to re-implement a replacement backend. Doable..but not really worth it considering Debian isn't targeting consumer computing devices.

Shuttleworth: X marks the spot

davexunit — Thu, 22 Oct 2015 16:27:41 +0000

I'm one of many core developers, but I was not involved in making any of the core design decisions. I joined the project later because I liked the design so much. Guix has already appealed to people in the "real world", notably in managing HPC clusters in the bioinformatics industry, so I'm pretty optimistic that the merits of our system will continue to catch on.

Shuttleworth: X marks the spot

gowen — Thu, 22 Oct 2015 14:56:17 +0000

davexunit is a (the?) core developer of of GNU Guix. He's bound to agree with Guix's functional design decisions, since he was involved in maken many of them, These design decisions also align strongly with the FSF's origins in LISP machines and Emacs, and using Guile as an extension language - ideas which despite their merits have never really caught on outside the GNU project, and IMHO, are unlikely to ever do so.

Shuttleworth: X marks the spot

alexl — Thu, 22 Oct 2015 13:21:38 +0000

You can build xdg-app bundles and runtimes however you like, for instance one could use nix to build them (or rpms, debs, tarballs, etc).

xdg-app is mainly a way to distribute and execute the applications, and the way it does this via ostree is, while not the same, quite similar to Nix:

https://wiki.gnome.org/Projects/OSTree/NixOSComparison

That said, there is a fundamental difference in xdg-app in that it has a runtime/app split so that different people can maintain and update the two.

Shuttleworth: X marks the spot

davexunit — Thu, 22 Oct 2015 13:12:29 +0000

xdg-app is another badly designed packaging tool. I highly recommend exploring functional package management instead.

Shuttleworth: X marks the spot

jonnor — Thu, 22 Oct 2015 12:31:25 +0000

A bit sad to see Canonical go their own way, again...
I'm more inclined to put my money on xdg-app.

Shuttleworth: X marks the spot

davexunit — Thu, 22 Oct 2015 12:25:48 +0000

I don't know what Canonical was thinking with Snappy. I really don't think that they did their homework before building it. They've managed to build something that, if you squint, looks sort-of like GNU Guix or Nix, but without nearly all of their features and with a worse architecture.

http://sandervanderburg.blogspot.com/2015/04/an-evaluatio...

Shuttleworth: X marks the spot

Lennie — Thu, 22 Oct 2015 11:38:39 +0000

Just Mesos does very little, it's just a scheduler. Trying to fit as many processes on the machines available.

MAAS is uses to deploy disk-images to hardware (for example IPMI to boot servers and automatically install an image on the machine).

So they are completely different things.

It's usually used as part of something bigger: for example to install OpenStack with JuJu.

Now maybe you've heared something from a company like Mesosphere which I've not heared off. Maybe they have something to install machines as well. I do know Mesosphere has tooling for deploying Mesos. Not sure if they have some deployment method for hardware. Even if that is true, MAAS works with multiple operating systems so you can use it to assign very different tasks to your pool of servers.

Shuttleworth: X marks the spot

eru — Thu, 22 Oct 2015 10:53:13 +0000

Xenial and Xerus. Thanks, I learned two words that I did not know before. So not a totally wasted day.

Shuttleworth: X marks the spot

alison — Thu, 22 Oct 2015 05:23:25 +0000

From the headline, I had thought that perhaps Mir was now going to ship without X11. I guess that change is still pending . . .

Shuttleworth: X marks the spot

b7j0c — Thu, 22 Oct 2015 04:21:34 +0000

LXD and Snappy look neat, nice to see Ubuntu investing in core tech.

MAAS looks a lot like Mesos, are they related? Don't see Ubuntu moving the market much here, its going to be an AWS world for a while.

Strange to see discussion of Ubuntu Phone still...I figured Canonical had given up on it.