Snap and Flatpak apps
-
@3arn0wl said in Snap and Flatpak apps:
Isn't the kernel being used for the "Linux" UBport to PinePhone and Librem5 much newer...?
The goal is to use the upstream kernel there, yes, but for all the work it would take to make snaps and flatpak work properly on the host, it's a waste of time if it only works on one or two devices, when hopefully UT will be usable on dozens when the current halium blockers get resolved.
-
@dobey unless, of course, the more attractive way forward turns out to be the purer Linux route.
-
@3arn0wl I don't know what you mean by that. At that point, it would no longer be UT though, and we would have failed.
If what you want is a "purer" linux on your phone, there is PostmarketOS for that, or you can build whatever you want and install it on your phone. But it's going to be a very poor experience.
-
@dobey
I meant less dependent on Android...I think the PinePhone / Libem5 projects are really important for us... Devices built for Linux. This a real opportunity for us to showcase the distinctiveness, and the strength of what we've got to offer*.
They might well prove to be quite popular, which would encourage further hardware efforts.
- which takes us back to the topic of Snaps...
-
@3arn0wl But being able to run an upstream kernel, and supporting snaps/flatpaks/whatever are completely separate things.
A couple phones being able to run on upstream kernel does not an ecosystem make, when we have dozens of phones to support that do not. There are a whole massive host of problems with making snaps and flatpaks work reasonable under unity8 to deal with beyond the simple kernel issues.
The only reasonable way I see us being able to support them within any reasonable time frame, would be on devices which run upstream kernel, and only under libertine. And that's after we get new unity8/mir, and port everything over to systemd.
-
@dobey said in Snap and Flatpak apps:
The only reasonable way I see us being able to support them within any reasonable time frame, would be on devices which run upstream kernel, and only under libertine. And that's after we get new unity8/mir, and port everything over to systemd.
That seems to be a decent roadmap, from someone who knows immeasurably more about this than I ever will. -
@3arn0wl The question is if this is a roadmap we should follow, given a lot of other very urgent things to do. But we shall see...
-
Yes, there always seems to be a mountain of stuff to do and, as you say, some of it is very urgent. Respect to all the devs for suiting up to face it.
-
@dobey why under libertine?
-
@Aury88 said in Snap and Flatpak apps:
@dobey why under libertine?
Becuase snap/flatpak are not direct replacements for everything click does, and almost everything packaged in them is not suitable for mobile use; as they are built to run under Xorg. Therefore it would make more sense for them to be treated that way, so that they get all the same integrations as provided for libertine.
-
Hi @dobey, so you have to put a "container" (snap) in another "container"/sandbox (libertine) only because most of the package on it are not suitable for smartphone and its display server?
I thought the libertine purpose was mainly to permit the installation of deb packages because of their confinement incompatible with the rest of the smartphone os (xorg build-ed apps I think can be handle by xmir) . and snaps for a confinement POV seems to me more similar to clicks (and for some aspect more strict) than to deb, but I'm not a developer so probably here I'm wrong.
from your last sentence don't seem to me that putting snapd in libertine is a mandatory step, but mainly as a matter of order (keep separate smartphone apps from desktop apps); isn't possible to have snapd in parallel/external to libertine and with the same "integration" or, put in a provocative way, why is not possible to use snapd as a substitute to libertine to install desk software ( apart for the compatibility problems between snapd and the kernel/init used in UT)?
I was not thinking about snap as a click substitute, but this is surely an interesting and instructive discussion, so I ask you if can you help me understand what are the things that snap can't do/replace and that click does?
thank you! -
Is it the feeling that the Libertine container will run better once Unity8/Mir is developed and things are ported over to systemd? And that Xorg apps will run / run better in it? I realise that although there are a lot of snaps available, there are many more apps which are .deb1.
Purely from a selfish user's point of view, it would be good if they were as easy for us to download as the click apps currently are.
1 I also understand that many of those apps would only be usable with a monitor, keyboard and mouse connected, and that most of them won't be converging.
-
@Aury88 I don't know where you got this idea, but snap is not a container based system.
The purpose of libertine is to provide a container for "legacy" (aka X11) apps, with integration to OSK, copy/paste, etc… and to confine them away from the rest of the system. Snaps and flatpaks are almost all legacy apps (or in the case of snap, headless server apps).
It is not possible to use snapd as a substitute for libertine, because it is not one. However, I did not say that it was not possible to use snapd outside of libertine. I merely stated it is not sensible.
Snapd nor flatpak work anything remotely close to how clicks work, though. Therefore the same methods cannot apply.
Snapd does not use apparmor profiles for confinement as click does, for example. It also uses an "interfaces" system, which is a hard-coded list, and therefore very difficult to make changes to. The store is also controlled by Canonical, and we cannot set up our own store easily; and doing so would degrade the relationship we do have with Canonical and our allowed use of the Ubuntu trademarks.
Also, snappy was designed around the needs of IoT devices, not end users. The support for end user applications is all an afterthought, and many things do not work as well as they do with clicks.
It's a whole lot of work to support something, that basically provides no benefit.
-
@dobey thank you for the interesting explanation!
