compatibility layer between UT and other OSes
-
Hi guys.
This question, which I hope will evolve into a discussion, arose as a result of the latest Q&A. In each of these several users asked if it was possible to run other os linux apps for smartphones on UT and thus avoid fragmentation.
The answer was no on the possibility of avoiding fragmentation, while as regards compatible applications on multiple platforms the main difficulty is not in making an application executable but rather adapting it to the different ways of accessing system resources that each OS has.My doubt, probably stupid, is: if we are able (theoretically) to run android applications on UT, why shouldn't the same trick also be possible to obtain the compatibility with other distro on smartphone (much more similar to UT than android)?
If it were possible the potential for a greater diffusion of all distros on smartphones (not only UT) would be much wider, it would avoid wasting resources in porting the same application on multiple os or, worse, in reinventing the wheel for each smartphone distro.
-
Yet another Libertine or Anbox? I hope not
There are some factors like qt vs GTK (most Phosh apps) use that are not really a problem technically, but just don't make much sense power/memory consumption wise. So I don't see much ways around that.
Other things like different qt versions are definitely solvable and qt Kirigami apps from Plasma Mobile can run on UT relative easily.
The main blocking points I think are:
- Media hub / content hub, where UT does it's own thing and that breaks a lot of functionality of apps.
- Click packaging
For 1. this is something other mobile operating systems will want to implement at some point as well. I am not 100% up to date on the latest developments there, but Ubports should probably look at what is there and adapt that, or gasp port "our" solution to Plasma Mobile for example so that it becomes used there too.
For 2. This has been debated a few times I think, and I would consider it technical debt. Luckily Clickable should be flexible enough to also do packaging for other systems, so again maybe it would make sense to allow making for example flatpacks with Clickable and get other projects to also use this nice tool. Then it would be easy to make Clicks as well and slowly migrate off to a newer upstream system like flatpack in the future.
Last but not least Open-Store could be expanded to other system, as currently there isn't really a Playstore like 3rd party app distribution model on those. At least for Plasma Mobile it should be easy to get the open-store app running.
So instead of making yet another compatibility layer, lets work on compatibility between the projects instead of reinventing the wheel everywhere
Edit: I like that the Ubports installer now also works for other systems like LinageOS. This is exactly where the above also needs to go. For example allow easy installation of Plasma Mobile etc.
Edit2: Really a shame that Lomiri on Manjaro hasn't progressed much lately. That was also one of those super promising initiatives that could lead to more cross system compatibility. Ideally there should be more than one mobile OS using Lomiri as their main UI.
Edit3: Actually a new alpha jut got released: https://forum.manjaro.org/t/manjaro-arm-alpha2-with-lomiri-pinephone/39561 -
P.S.: Here is an example of a Plasma-Mobile app running via flatpack on SailfishOS:
https://youtu.be/N7LFPw9Z2aMSomething like that really isn't too different from doing it on UT, at least in theory
Edit: And Angelfish on UT would also be nice. IMHO as nice as Morph is, joining efforts with Angelfish would be better.
-
I think it's very possible to have normal linux apps on UT with a few caveat. As mentioned, upgrading Qt version would make KDE apps generally work. Completing the transition to wayland/xwyaland would make most linux apps work and rebasing to 20.04 would make the compatibility with latest versions of apps a lot better. However, the way of installing may be challenging. Using libertine would be the simplest way but obviously it has limitations since it's just a container. An ideal way would be to repackage them as click. However, using UT-specific APIs such as media hub and content hub will of course be something that has to intentionally implemented in the apps. There are many unconfined apps in the store anyway so as long as they are tagged as such then I don't see problems with traditional apps being unconfined on UT.
But of course, the best would be to support flatpaks/snaps.
-
Maybe as a start some developers could convert their unused Nexus5 to PostmarketOS with Flatpack and Plasma Mobile?
Both seem to work reasonably well on the Nexus5 and could make a good test ground:
https://wiki.postmarketos.org/wiki/Google_Nexus_5_(lg-hammerhead)
(I think I'll convert my Nexus5 in the coming days, as I can still run UT on one of my other devices). But I am sadly not a OS developer. But if anyone needs some testing of cross compatible apps etc., let me know
-
@poVoq
I don't see what is the problem with another "libertine" or "anbox"...our problem with them is the lack of develop in supporting these systems but, if developed, they could result in lightweight systems able to support apps (integrated with the OS) without have to emulate an entire OS.
For what I understand from the Q&A answers, having the same mediahub/content hub on other OSes is exactly what is nearly impossible until great changes in those distros. The other way around is also near impossible due to access and read/write policy restrictions on UT (and this will not change) and the same mediahub/content hub problem.
As said by the UBPTeam in the Q&A the adoption of an "Universal" packaging system like Snap or Flatpak can solve some of the main problems but you will obtain usually only an executable application unable to work because of the different media/content hubs access policy etc.it is not necessarily to create another compatibility layer on UT, in fact in my opinion it is better a layer on other OSes to allow them to use UT apps; this because the UT apps are already more "confined" (no write access on the system image). Also, at the moment, this option would be the only win-win solution: UT obtains more interest from developers (support a single system to support many others) and the other systems obtain the access to the currently more extended linux app ecosystem for smartphone. MyTwoCents
-
Well, flatpak will just work at some point in the future. Other things may or may not. Heck, you can already theoretically use flatpak or appimages on some devices today. It's just there isn't a trivial and integrated way to do it in the system, because it's not a priority.
-
@kugiigi said in compatibility layer between UT and other OSes:
However, using UT-specific APIs such as media hub and content hub will of course be something that has to intentionally implemented in the apps.
Not necessarily. With media-hub for example, I think anything using QtMultimedia goes through it. With content-hub, we'll likely need to do something with xdg-portals for flatpaks to be able to use it. (We also need to change how some things work anyway, so they will work properly on Wayland, as the don't currently.)
-
@dobey given what was said in the Q&A87 (from 41:06, and precisely at 44:13) the flatpak or snap or appimages adoption will solve many problems but not all of them.
so how can what you say be reconciled with what they said? are you talking about of different (ie) flatpak integrations (so a flatpack "manager" for UT, another adapted to plasmamobile another for postmarket etc) so to "translate" generic flatpak app's content hub and resources calls in order to adhere to the specific OSes policies?
Imho, if possible, this would be an even better solution. -
@poVoq said in compatibility layer between UT and other OSes:
Last but not least Open-Store could be expanded to other system, as currently there isn't really a Playstore like 3rd party app distribution model on those. At least for Plasma Mobile it should be easy to get the open-store app running.
this sounds like an interesting idea. and maybe this wouldn't be too hard. the open-store is basically a service where packaged apps are distributed.
Developers can create an account, upload an app, specify which OS it's for (15.04, 16.04, armhf, arm64), describe it, do changelog and updates and get some installation stats. I think it also has a rating system for users since a little while.
Mobile OS' can inquire the list of apps compatible with itself are in the store and updates for installed apps and download and install stuff.
I don't even think that too much of this infrastructure is UT or click specific. Some pieces are of course, like the app submission to the store does a click review and for apps in the store it shows some apparmor click permissions, etc. Also the graphical design on the open-store website is UT specific. But it feels like this is the sugar on top of the machine that makes open-store.
Maybe it wouldn't be too hard to add another OS like plasma mobile to the list and then someone has to teach plasma to get app packages from there. Whatever format pm uses ... debs? or flatpak? If Open-Store learns flatpak that way, this might also be a nice option for UT at some point in the future.
Then you have One store where mobile linux app developers mingle with their apps. Initially it would be separate camps who only develop their apps for this OS or that OS, but it gives the devs exposure to each other. Some apps have already been ported to multiple OS' .... some navigation app ... the name escapes me. If the devs then are all mingling in the same pond, they might learn tricks about porting from one OS to another.
It would still bring a multiplication of work and complexity to the open-store code/infrastructure/team, so that would weigh against it, but I find it an interesting idea! At least the name Open-Store itself would definitely still work, so no branding problem
-
I think the biggest hassle in the short run is neither packaging nor the store, but the QML framework and System Integration. It is not too hard to have different packaging configurations in your repo and deploy to different stores.
Pure Maps by @rinigus is a great example on how platform independent mobile linux apps can be done. The most interesting part is the platform abstraction in QML, in my opinion. The app assumes some QML files in a folder called platform, which is just an imaginary interface to Elements like a Button, a Dialog, Clipboard or file chooser (aka Content Hub in UT). Adding support to another platform means to create a new platform folder and implement the interface using the specific platform frameworks stuff. The packager then just links the desired platform folder to platform and builds the app.
Now you may wonder whether it is necessary for each and every app developer to implement each platform support over and over again. And of course it is not. That could be done in one place shared by all apps. Someone has already started that meta-framework-project as a spin-off from Pure Maps, which just needs to be explored and picked up by app developers.
Sure, this won't solve all problems like (push) notification and background services. But it should help a majority of all apps to become available on many platforms.
-
@Aury88 Right. We need to get some more features implemented so that things work better on Wayland in general, and so we can bridge things like permissions prompts and content hub to work appropriately when flatpak apps request things. There will likely still be plenty of sticking points though.
