One of the reasons for the move to focal was to be able to use updated upstream software and therefore free up internal resources to be dedicated to other things previously engaged in backporting or developing in-house solutions.
Following the switch to focal, are you able to give us an estimate of how much energy was saved which you can now dedicate to other aspects of the project?

Are there still packages/libraries that you would like to see upgraded to the upstream version? Which ones are they?

thx

not many question here so I hope you wouldn't mind if I monopolize the question time

• In the last Q&A Alfred said that at the moment snaps can't replace libertine because there are things in libertine that UT needs so to stay feature complete. What are these features/things?

• hypothetically speaking: what features has click that actually make them not replaceable by snaps?

• are you collaborating/talking with canonical/snapcrafters about the snap support on UT? i think they would be happy to be the first to have a real universal packaging system usable in all kind of platforms (yeah I know, i'm not considering the smartwatch)

• snapd and snaps already work on a read only system called ubuntu-core, why in UT snapd/s need a writable system? will this be solved?

• hypothetically speaking how much work is needed to have lomiri packaged as a snap and working on an all snap OS ? (ps: there is already an old snapped unity8 DE)
  canonical will soon release a desktop all-snap system with a snaped Gnome version...but we all know and remember that initially the plan was to have an adaptive (the term used was "convergent") DE so to make the "universal OS" really "universal"

:love-you_gesture:

@Lakotaubp Hi
there was already a thread on the subject that cost me energy to make, but it was closed and at the moment I don't have time to open another one. for now I'm interested in the telegram channel (where no one expressed interest in (re)opening a thread on the forum) . based on how it goes maybe I'll decide if it's worth doing the job again or maybe someone else will do it.
thank you.

@UBportsNews
Hi everyone!
I just wanted to ask if you could take few seconds to spread that with the UT transition from xenial to focal, the system has now become usable on RPi4 and ask all owners of an RPi (3 or 4) to help us in test/bugreport/bugfix the system and applications so to help improve the user experience on these fantastic and widespread (developer) boards. there is a telegram group where we can help each other.

Thank you very much for all your effort in the ubports project and UT so and software

with the new 20.04 based version we will see the use of the newer Mir version on UT.
what benefits will this change bring? will there be a performance improvement? do you already know what new features could be introduced with the new mir?

with the new base and the new mir will we finally see solved the problems that block the usability of UT on Rpi4?

we recently saw good progress in terms of feature coverage thank to ie Alfred an Alberto work. but these progress are on 16.04 based version. how much of these progress can be "ported" on 20.04 base?

@unisuperbox Thanks you for all your hard work on Ubports.
I'm very sad thinking I will not heard your brilliant Q&As anymore but it is a choice that I understand perfectly.
I really wish you all the success and happiness you deserve and I hope, in the future, to see you here again, maybe in a less stressful role, but still here.

Good luck in anything you will do.

Do you have ever made considerations about "What If [put a main developer name here] Gets Hit By A Bus?

What will happen if Marius or Daldon o Florian ecc Gets Hit By A Bus (or, more probably, lost interest in the project)?
Would the project go on or will it die?

Now we have a foundation but can the project still be defined as an amateur project carried out by a few or an organization capable of surviving the abandonment of 4-5 main developers?

Ps: I wish the developers every luck and certainly not to be hit by a bus ... I used this case only because it is the subject of study for linus torward

what do you think about Waydroid (aka Anbox-halium). what are the differences with anbox used on UT?
can Waydroid be in future an acceptable solution on UT as well as Anbox?

Waydroid has appeared in many articles in specialist newspapers around the world. Has this sudden increased visibility of this project already led to contributors also not linked to UT?

thanks @Xray2000 for the answer!I had missed that information

@ubportsnews there is increasing interest in the use of Rust programming language, mainly due to its ability to enforcing memory safety statically. is there interest in integrating this language into UT? what do you think would be the components that would benefit most from being written in Rust language?

ALSO: thanks to my collaboration in OpenStreetMap I'm earning some Chrons from the NEO Economy (equivalent to 0.6€ per hour editing in OSM...I can also reach 6h/week)... is there a way to donate them to the ubports foundation?

How is the work on the Ubuntu Touch Flatpak Runtime going on?
What help is needed?
In the description you said some apps already work fine. what are these apps?

Make the UT apps compatible/usable in other distro is a way to make the development of ut app more appealing to the developers (wider userbase).... is this a project that will have priority any time soon?

PS:since unfortunately I missed the 100th Q&A because I was at my grandmother's funeral, I wish you all happy 100th Q&A now!! :party_popper: :party_popper: :party_popper:

you did not answered my question in the last Q&A. so I re-post them hoping this would not be considered spam

Q1: Canonical recently announced that Flutter will be the default choice for future Ubuntu apps.
Could this choice advantage UT?
what obstacles should be addressed before having a working and integrated flutter framework support in UT?

and now I add these personal questions:
Q2: what was your first programming language you programmed with? currently what is your favorite programming language (even among those not supported by UT)?

recently was announced by Canonical that Flutter will be the default choice for future Ubuntu apps.
Could this choice be an advantage for UT?
if possible, what obstacles should be addressed before having a working and integrated flutter framework support in UT?

Pine64 choosed to ship pinephone with Plasma Mobile on Manjaro ARM base from this point on.
Q1 are you surprised?
Q2 What do you think is the motivation behind this decision?
Q3 Is manjaro/plasma seen as a more robust/mature project or as a more enjoyable experience or was only a problem of (missing) comunication about advancement in the development of ut for pinephone ?
I know we are very friend and bound togheder with the manjaro team ( I too LOVE their os) but a friendly competition could also be healthy...so maybe... Q4 are you thinking a B plan/strategy to compensate/answer to this situation?

@kaizen Amazig work! goood job! I really like it

Can I suggest something from a non-technical POV?
At the top of the sketch you have inserted a truly explanatory schematization (we need to add the app layer). I suggest to keep the same order for the component listed in the first "about the project" section.
Also in the second "about the project" you have used new therms and this could be confusing for someone like me:

• where is the lomiri layer?
• what is this new midleware? is it the halium + core layer?

A better way to keep all more intuitive as possible (but i don't know if it is possible) is to make all the information hidden unless we touch on the desired section: if you touch the "lomiri" layer on the top scheme it opens in the bottom the "Lomiri project" of the first "about the project"
If you touch the "halium" layer on the top scheme it opens in the bottom the "halium project" of the first "about the project" with also the explanation you putted in the second "about the project" section
and so on...
also all element in the second "about the project" should be clickable (not the software ) with direct link to the doc or their github/lab page.

my2cents.

Aury

@alan_g
Oh! so I totally misunderstood that command...reading the documentation seemed to me git pull already encompass a git fetch and a git merge. also I tried the git pull after the make command and that confirmed the local branch was up-to-date. ok, i will try again after the fetch. thank you.

@jonius i tried again after the git pull but obtain the same error

during the QtMir build with make -j 6 all test I also had the fatal error described by @jonius :

[ 87%] Building CXX object tests/mirserver/ScreensModel/CMakeFiles/ScreensModelTest.dir/screensmodel_test.cpp.o
In file included from /home/aurelio/qtmir/src/modules/Unity/Application/mirsurface.h:35:0,
                 from /home/aurelio/qtmir/tests/modules/SurfaceManager/surface_manager_test.cpp:22:
/home/aurelio/qtmir/src/modules/Unity/Application/mirbuffersgtexture.h:20:30: fatal error: miroil/mirbuffer.h: Not existing file or directory 
compilation terminated.
tests/modules/SurfaceManager/CMakeFiles/surfacemanager_test.dir/build.make:62:  instruction set  for the target "tests/modules/SurfaceManager/CMakeFiles/surfacemanager_test.dir/surface_manager_test.cpp.o" failed
make[2]: *** [tests/modules/SurfaceManager/CMakeFiles/surfacemanager_test.dir/surface_manager_test.cpp.o] Error 1
CMakeFiles/Makefile2:2146:  instruction set  for the target "tests/modules/SurfaceManager/CMakeFiles/surfacemanager_test.dir/all" failed
make[1]: *** [tests/modules/SurfaceManager/CMakeFiles/surfacemanager_test.dir/all] Error 2
make[1]: *** waiting incomplete process....

and after that

[ 95%] Built target applicationmanager_test
Makefile:138: instruction set  for the target  "all" failed
make: *** [all] Error 2

@flohack thank you! Now it is more clearer.
Now my only doubt is what is the scheme in an "open hardware" device like pinephone or librem5 and what closed source parts still have to be integrated in UT (preventing UT to be fully FSF compliant.)

PS: I don't find that very informative scheme in our doc...I think that could be usefull to understand what UT is and what is/must be touched by halium and the port process. why that is not in our documentation?

@flohack I already know-ish almost all of these things my doubt was about the "position" of this system.img/abstraction layer(I though halium was covering the bottom red and blue areas in a "kernel-land"and UT was over it)
I already know UT needs (as any other SO) these blobs to run on "android device".
Replicant does not seems to use these services/daemons and so their os is always missing something in any device.

@kugiigi I only copy-pasted what they wrote on their website

I don't think they are purer that other distros on pinephone or librem5 and I suspect they also know that but avoid to talk about this.

@fla I already wrote them for another reason (make microkernel an HPP) I was only waiting to understand what is the foundation and community will about all this (so also to gain some time between the two email)

but I fear UT is not listed in the HPP because, as said by Replicant:
" Many mobile operating systems are mostly free software (e.g. Android, Firefox OS, Ubuntu Touch, Tizen), as they use the Linux kernel, a free framework and ship with free base applications. However, the user-space hardware abstraction layers are for the most part proprietary (it varies from one device to another) and they also ship with proprietary loaded firmwares for various integrated circuits. Every piece of proprietary software running on the system is a risk for privacy/security as they can offer remote access back-doors and compromise the rest of the system."
And also
" None of these mostly-free systems have a clear policy to reject proprietary software and not advocate its use, except for Replicant. "

PS: are we using a user-space abstraction layer? I thought the abstraction layer was between the hardware and the kernel, so a kernel-space abstraction layer :man_shrugging_light_skin_tone: