LWN: Comments on "Announcing Flatpak"

Flatpak: Community matters

patrick_g — Mon, 04 Jul 2016 19:58:42 +0000

> AppImage works better.

And another interesting test here : https://www.distrowatch.com/weekly.php?issue=20160704#opi...

Announcing Flatpak

JanC_ — Mon, 04 Jul 2016 14:52:19 +0000

If the application has its own "package manager" for plugins that would likely work as usual (providing the application is packaged properly).

Manual installation might also work, although the file locations might be different than usual.

Creating/using a "gimp plugins flatpack" would not work (as far as I know?).

Announcing Flatpak

wtanksleyjr — Fri, 01 Jul 2016 14:45:11 +0000

Right. Besides, "my code is compiling".

Announcing Flatpak

Cyberax — Tue, 28 Jun 2016 03:11:03 +0000

This document is obsolete, you can do whatever you want with delegated groups. Single writer requirement is also gone.

Announcing Flatpak

wahern — Tue, 28 Jun 2016 02:55:28 +0000

Ah, I see. So you specify Delegate=yes in the service file. But according to this, "only child processes within the control group process tree can manage the controllers". Or am I reading it wrong? I guess it wouldn't matter; if you're a process outside a control group you're probably using the systemd interfaces, anyhow. Or would systemd refuse to alter any of those controllers?

Announcing Flatpak

Cyberax — Mon, 27 Jun 2016 23:38:21 +0000

> Have you now changed your mind? Will you no longer be disappointed when systemd becomes the sole arbiter for cgroups?
First, the cgroups changes were mostly dictated by the sanity of implementation. I can understand that multiple controller trees are complex and people don't want to support that. Disappointing, but understandable.

Second, cgroupsv2 actually fixed my main objection - the lack of delegation. It absolute IS possible to carve out a part of the cgroups tree and manage it yourself. And it's done the way I wanted it - by using filesystem permissions. The initial plans to enforce the single writer process for cgroups management were abandoned.

So I'm quite happy overall with cgroups progress.

Announcing Flatpak

wahern — Mon, 27 Jun 2016 23:31:47 +0000

As I mostly code in userspace, most of what I know about the non-technical aspects of kernel development comes from LWN.net. Here's an example from a 2012 article written by the editor, Mr. Corbet:

Control groups are one of those features that kernel developers love to hate. It is not that hard to find developers complaining about control groups and even threatening to rip them out of the kernel some dark night when nobody is paying attention.

You (Cyberax) even commented on that article:

I'm using multiple control groups and I like it. For example, it makes perfect sense to categorize processes based on network policy (i.e. processes that can create connections, that can create listening sockets, etc.) with completely parallel tree maintained by systemd. That's a great feature and I'd be disappointed if it went away.

Have you now changed your mind? Will you no longer be disappointed when systemd becomes the sole arbiter for cgroups?

Announcing Flatpak

Cyberax — Mon, 27 Jun 2016 19:30:50 +0000

> And there are containers after it, due to the turf wars going on over platform dominance where a bunch of competing start-ups are trying to corner the market around _their_ particular ecosystem. The turf wars are providing a ceiling on how much collaboration and standardization is actually happening in these infrastructure layers.
Yet they are converging on one standard - https://www.opencontainers.org/ And yes, it is supported by Docker.

> Heck DEB vs. RPM is the same kind of thing, each has its own ecosystem and neither is going to back down.
That's because DEB or RPM package format doesn't really matter if dependencies are not standardized.

Announcing Flatpak

raven667 — Mon, 27 Jun 2016 17:40:46 +0000

> It's like Docker - there were containers before it

And there are containers after it, due to the turf wars going on over platform dominance where a bunch of competing start-ups are trying to corner the market around _their_ particular ecosystem. The turf wars are providing a ceiling on how much collaboration and standardization is actually happening in these infrastructure layers. Look at Docker vs. CoreOS or all the slightly different OpenStack management frameworks, or Snap vs. Flatpak vs. everything else. Heck DEB vs. RPM is the same kind of thing, each has its own ecosystem and neither is going to back down.

Announcing Flatpak

Cyberax — Sun, 26 Jun 2016 23:46:58 +0000

0install is a PITA to use and is somewhat complicated. Newer systems are designed to be easy to use and provide more isolation.

It's like Docker - there were containers before it, but Docker is easy to use and so it exploded in popularity.

Announcing Flatpak

flussence — Sun, 26 Jun 2016 22:37:03 +0000

But that's part of my point: Android is a landfill of old platform APIs in the same way Windows is, it's why the large standalone app model works on both. Yes, they're a bloated mess and looking too close at the details is liable to cost your sanity, but that mess gets real results.

On Linux the only things that are stable to that degree are the kernel and POSIX, and a tiny handful of things not “owned” by any one distro, like SDL. Everything above that has become one big turf war of corporates trying to become the dominant Linux. All these recent attempts to build superficial clones of the app ecosystem on top of *that* simply won't last, because they don't do anything significantly better than 0install — except having an oversized hype budget, which will eventually run out.

Announcing Flatpak

Cyberax — Sun, 26 Jun 2016 19:31:36 +0000

> the app depends on a specific version of a specific version of the OS (forward-compatible if you're lucky);
Really? I have an app that I developed for the very first public release of Android. It still works.

I have a very non-trivial app with lots of native and Dalvik code written for Android 2.2. It still works.

Announcing Flatpak

flussence — Sun, 26 Jun 2016 19:23:59 +0000

The Android ecosystem is a glimpse into the future Steam/FlatSnapDocker/next-week's-fad are building: third party libs get copied into the app package and never receive security updates; the app depends on a specific version of a specific version of the OS (forward-compatible if you're lucky); and the general reaction to people who want to use Linux independently of Google, RedHat or Canonical has been “go screw yourself, you don't exist”.

The only real difference is, as others have pointed out at length, lowering standards like this won't correlate with a sudden explosion in user or developer count.

Announcing Flatpak

federico3 — Sun, 26 Jun 2016 13:13:15 +0000

> Is Google Play also not a "package manager"?

It doesn't even handle dependencies.

Announcing Flatpak

flussence — Sat, 25 Jun 2016 20:19:46 +0000

That's the “kernel developers wanted to deprecate it” part. We'll be stuck with cgroups1 for a long time, but ironically it might turn out easier to dispose of now that systemd's monopolised control of it…

Announcing Flatpak

flussence — Sat, 25 Jun 2016 20:17:12 +0000

Presumably those would go in ~/.gimp-2.8/plugins etc., like they already do for normal distro-managed installations where the user has no write access to root-owned install dirs.

Announcing Flatpak

zdzichu — Sat, 25 Jun 2016 06:47:10 +0000

Is this still relevant with cgroup2?

Announcing Flatpak

Cyberax — Sat, 25 Jun 2016 03:04:28 +0000

> Though clearly useful for reigning in broken software, systemd's use of cgroups is a hack. The kernel developers wanted to deprecate it, but systemd ran with it.
Really? I don't remember anything about it, and I actually used cgroups even before systemd.

> For sysadmins, systemd is clearly a step up. For software engineers endeavoring to implement correct and useful software, systemd is at best a step side-ways. In that sense systemd is creating a ceiling beyond which Linux process management might never get better.
Why? cgroups operations is a tiny piece of systemd, it will be improved when newer kernel facilities become available (process handles and so on).

Announcing Flatpak

wahern — Fri, 24 Jun 2016 22:56:06 +0000

Though clearly useful for reigning in broken software, systemd's use of cgroups is a hack. The kernel developers wanted to deprecate it, but systemd ran with it. Because cgroups doesn't permit atomic manipulation of groups of processes, systemd's process management via cgroups is almost as inherently buggy as much despised PID files. The way it terminates sets of cgroup processes is not much better than piping the output of ps through xargs.

Here's more info from the last time I pointed it out: https://lwn.net/Articles/677671/

The fundamental problems can't be fixed without improved kernel facilities. cgroups as it current exists is insufficient.

For sysadmins, systemd is clearly a step up. For software engineers endeavoring to implement correct and useful software, systemd is at best a step side-ways. In that sense systemd is creating a ceiling beyond which Linux process management might never get better. In the short-term that ceiling is higher than it is now; in the long-term wedding ourselves to systemd and cgroups will have its costs.

What would be nice to see happen is for people to distill and describe the kernel facilities necessary to permit provably correct userspace management of process lifetime. Short of that, I never understood why systemd didn't just implement a kernel module. It's so incredibly invasive (for better or worse), that depending on a kernel module is a relatively minor dependency.

Announcing Flatpak

luya — Fri, 24 Jun 2016 18:12:57 +0000

A question popping in mind, how to install add-ons for flatpaked applications like Gimp?

Flatpak: Community matters

rahulsundaram — Fri, 24 Jun 2016 14:39:08 +0000

> You enable the access in the application profile.

So you need to limit yourself to what is defined ahead of time in an application profile or do a two step procedure whenever you want to access a different path?

Flatpak: Community matters

patrick_g — Fri, 24 Jun 2016 14:16:40 +0000

>And then how do you open that ~/Private/Documents/scheme.png document?

You enable the access in the application profile.

Flatpak: Community matters

smcv — Thu, 23 Jun 2016 16:13:12 +0000

Flatpak does have support for importing OCI files.

The actual sandboxing is a relatively small proportion of the effort in having useful apps in a sandbox, though: Flatpak basically already has the containment part (it's Bubblewrap). The interesting part is setting up the bridges between the container and the host system, for instance so that you can open a selected file in the contained app by browsing to that file in an apparently ordinary "Open" dialog, without letting it access *all* your files. Flatpak calls those services "portals".

More on portals here: https://github.com/flatpak/flatpak/wiki/Portals and on my blog: http://smcv.pseudorandom.co.uk/2016/gtk-hackfest/

Flatpak: Community matters

ovitters — Thu, 23 Jun 2016 12:33:53 +0000

That's exactly what I meant with promotion: doing the hard work for developers (creating the appimage/snap/flatpak). Then also listening to the concerns plus the various things that do not work (never perfect from the start).

For the runtime, most work is currently on the "GNOME" runtime as well as programs. IMO this makes sense because as you add more programs you see more cases where you need to adapt things. More time is needed with KDE. Once that takes off it'll be way easier for developers. KDE should be capable enough to maintain the runtime.

Relying on a runtime is optional btw.

With flatpak the idea is that you could run something on your machine that you don't fully trust. The sandboxing takes care of things (with 'portals' to break out of it). AppImage gives too much trust to the one who provided the AppImage IMO. E.g. the sandbox is still according to rules which can be provided by the AppImage.

Flatpak: Community matters

DeletedUser102083 — Thu, 23 Jun 2016 02:57:08 +0000

I agree with you. Docker with Wayland will do the same thing. I started working on this myself:

https://www.linkedin.com/pulse/why-you-should-help-me-cre...

Doesn't have to be Docker though. I just want to see something that wraps around the OCI spec instead of reinventing the wheel. Plus with Docker, you can have containers that will sync a users apps across devices. This approach really could be a great solution as an alternative to Google Play since applications can be developed in any language and automatically packaged to run on supported hardware. Plus you get all the GCC compile-time optimizations that Android lacks.

Announcing Flatpak

smcv — Wed, 22 Jun 2016 21:41:21 +0000

I wasn't saying that putting a full-OS init like systemd/sysvinit/upstart in a Docker container is a good idea, only that it's something that contained-app authors have the option of doing. Bubblewrap doesn't provide that choice, because it doesn't intend to be as general as Docker.

I've been led to believe that 'RUN ['my_service', '--foreground']' (without wrapping it in something like dumb-init) isn't great either, because pid 1 in a namespace gets some odd special cases in the kernel; but perhaps I've been misled, and perhaps it's fine in practice (as long as my_service makes sure to reap any child processes that it might start). In any case, Bubblewrap doesn't provide that choice either: pid 1 in the contained namespace is always Bubblewrap itself.

Announcing Flatpak

drag — Wed, 22 Jun 2016 21:21:18 +0000

> The major difference is that Docker is general enough to support running a full OS init like systemd or sysvinit in the container,

You may be able to get away with doing that in Docker, but it's a bad idea. Not in terms of 'it will destroy the world' bad, but it's just a anti-pattern sort of bad.

The reason for this is because it introduces complexity without any real benefit. You have this init that wants to be a init and behave like a init, but really isn't. Then you have it double forking or doing whatever. Then you have it's own processes that it launches to launch your process. If it's a daemon then it double forks itself.

That is a lot of work that can usually just be done by going 'RUN ['my_service', '--foreground']' or whatever.

Now if you had multiple processes to run in a container anyways or you have difficult processes that insist on double forking or doing other weird things.. then that is another thing. Typically supervisord is a good choice.... But this is were you are getting into some of, at least the common approach, with docker's limitations. It should be easy, in a ideal world, to divide most processes up into individual containers and have them talk to one another and then just take advantage of the init system on the host system to start them up and deal with them. That is instead of running a init system internal to the container to manage the processes you divide up the processes into containers and use the host's systemd to manage them in the 'rkt'/'coreos'/etc style of things.

Of course if something works then it works. I am not going to say you shouldn't use a more full-fledged init system in your containers if it works.

Flatpak: Community matters

jrjohansen — Wed, 22 Jun 2016 18:03:29 +0000

I wouldn't call AppArmor an optional non-standard kernel component, any more than any of the major LSMs (smack, selinux, tomoyo). Every LSM is optional, though most are built into the kernel and selectable at boot time on most distros.

Relying on an LSM (take your pick) vs namespaces and cgroups is just a different set of tradeoffs.

Flatpak: Community matters

rahulsundaram — Wed, 22 Jun 2016 17:48:08 +0000

> Why not spend this energy promoting AppImage instead of creating duplicates and competing projects?

Because competing projects do different things.

AppImage is a nice and simple since it is essentially a ISO file but it has no integration with any kind of sandboxing. Using something external like Firejail is not convenient for desktop apps which need to poke holes through the sandbox. Flatpak also does things like deduplication, deltas and so on

Flatpak: Community matters

Cyberax — Wed, 22 Jun 2016 17:34:57 +0000

And then how do you open that ~/Private/Documents/scheme.png document?

Announcing Flatpak

Hansin — Wed, 22 Jun 2016 15:24:02 +0000

My apologies to the commenter whose comment I commented on. It probably was appropriate in this case (the reference that specific xfcd), just was feeling a little snarky last night when I posted. It's a commonly referenced comic in many a comment, if you know what I mean ;)

Announcing Flatpak

halla — Wed, 22 Jun 2016 13:51:11 +0000

It needs fuse: on CentOS 6.5, only root can mount a fuse file system. That's the only problem I've ever encountered.

Announcing Flatpak

andreasn1 — Wed, 22 Jun 2016 13:32:23 +0000

About the third one, AppImage. I heard something about it only working on certain distros due to expecting certain dependencies or a certain filesystem layout. Is this correct? How big of a problem is it?

Announcing Flatpak

alexl — Wed, 22 Jun 2016 13:24:34 +0000

Flatpak doesn't currently use selinux, nor does it really depend on systemd other than as *a* way to create a cgroup. Its the *only* unprivileged way right now, but we don't really care about the systemd part, just the cgroup.

Not sure what you mean by "bus". If its "kdbus", we don't use/depend on that. Instead we have a userspace filtering proxy for dbus.

We support both wayland and X11, because everything uses X11 still. Just be aware that if you're using it the other sandboxing in effect is pretty much nullified by the attacks you can do on other X11 clients.

Flatpak: Community matters

patrick_g — Wed, 22 Jun 2016 13:03:20 +0000

>most sandbox strategies so far are already too annoying

Really?
Is it really difficult to do a 'firejail --appimage Krita-3.0-x86_64.AppImage'

Flatpak: Community matters

javispedro — Wed, 22 Jun 2016 12:47:29 +0000

In fact, I'd argue that there's now a "perfectly fine solution" that also happens to be extremely popular: Docker.

Note that I don't care about Docker or app-xdg or anything else, since a) I build from source and b) most sandbox strategies so far are already too annoying for normal use.

But it seems to me that Docker satisfies both being a packaging format, being prevalent in use, and having a container/sandboxing strategy.

Flatpak: Community matters

halla — Wed, 22 Jun 2016 11:30:12 +0000

Snaps also only work on a few newer distributions, with limitations, so that's not a point against flatpak.

But since nobody has contributed a flatpak generation script -- AppImage and snap were provided by Probono and Michael Hall, respectively, I cannot publish in that format. Sure, I could dig in myself and see what's up, but I am not interested in doing that, I'm too busy already. And I'm pretty sure that Andrew Chadwick didn't make the MyPaint flatpak, or Mitch the Gimp flatpak. That must've been done by someone working on flatpak. If they'd wanted my buy-in, they should have approached me directly.

I suspect it might be because there's no Qt/KDE runtime yet: it's significant all the sample applications in the announcement are GTK applications. If that's true, it would be one reason to think that the idea of runtimes is wrong.

Apart from that, there probably is no technical limitation, at least, not one that I can think of.

Flatpak: Community matters

nye — Wed, 22 Jun 2016 11:02:58 +0000

>For me personally, flatpak doesn't exist yet. At this moment, I cannot publish my software as a flatpak

Because of the need to support older distros as you mentioned upthread, or are there deficiencies that would prevent you from using it anyway?

I'm wondering because if it's the former, then at least that's something that should automatically be sorted out by the march of time, but if it's the latter...

Flatpak: Community matters

darwish — Wed, 22 Jun 2016 10:47:20 +0000

> I don't use the RedHat argument.

Yes, I know :-) It was mark shuttleworth who brought that argument in a latest omgubuntu article https://goo.gl/nMuCAM

Flatpak: Community matters

halla — Wed, 22 Jun 2016 10:30:04 +0000

" AppImage has existed for ages and works on many distributions. It barely is used though.

Instead of saying: then it should be used, I'd rather turn it around: if it existed for that long without too many people using it, then better do not spend time on it."

The question is, why isn't it used more?

There are a lot of possibles: the idea of making it possible to release desktop software to end users in an easy way only got a boost last year when Linus wanted to provide subsurface, it took ages to overcome the status-quo where people who weren't happy with deb and rpm got bullied and driven away, AppImage a real community effort without any corporate push, like both snappy and flatpak have. AppImage also doesn't offer any way to lock out the competition or lock in developers. I cannot be used as a pawn in a dominance game.

And it's much harder to make distributions accept something which makes them obsolete in a way: for flatpak and snap, there needs to be distribution support for things to run. For AppImage, nothing is needed, so there's no reason for the distribution people to work with.

For me personally, flatpak doesn't exist yet. At this moment, I cannot publish my software as a flatpak. Snap works, AppImage works better. And until that changes, end of story.