Is there any consideration in having a separate build that is not a read-only filesystem, e.g. more of a standard Ubuntu install? If there were something like that, I would think it could stand as the main development branch that would allow faster upgrade to 20.04 / wayland / systemd / etc. Then it could be a testing ground that new releases of the "stable" or "consumer" read-only system would come from.

It would also not frustrate any potential developers who want "standard Linux on a phone" (mobian, manjaro, fedora, etc.).

In summary, I understand a lot of the reasons behind the read-only system for stability, for security, for end users, etc. but I fear it keeps away possible developer interest that would benefit Ubuntu Touch in the long run if it were more "traditional Ubuntu" on a phone?

People could be trying all sorts of things like flatpak / snap / different apps, etc. I know there is Libertine but there is some performance issues and it isn't available everywhere, etc. So take the chains off and see what happens? I suspect a large growth of the community (???)

Can you give any update on Anbox development, which I have heard has some dedicated developer effort behind it?

Also, can you help us understand the specific ubports team efforts to Anbox apart from upstream Anbox development? Maybe mainstream is focused on desktop / amd64 base while ubports team is of course targeting for phone / arm? Is it hoped to eventually submit upstream the ubports work?

Thanks again for all the hard work. Keep it up team!

https://github.com/ubports/anbox

https://github.com/anbox/anbox

@UBportsNews I have understood from previous Q&A sessions that some of the major development goals include:

• moving to systemd
• moving to 20.04 base
• moving to wayland

Any updates on these goals and how they inter-relate? systemd for example we heard briefly from Marius went better than expected when working on Lomiri for Manjaro Arm.

Can you give any update on Anbox development, which I have heard has some dedicated developer effort behind it?

Also, can you help us understand the specific ubports team efforts to Anbox apart from upstream Anbox development? Maybe mainstream is focused on desktop / amd64 base while ubports team is of course targeting for phone / arm? Is it hoped to eventually submit upstream the ubports work?

Thanks again for all the hard work. Keep it up team!

https://github.com/ubports/anbox

https://github.com/anbox/anbox

Thanks so far for the insights. I'll check-in at the issue tracker, but understand what podbird is trying to do a bit better now at startup.

Note that a few other glitches were solved with a recent update: namely that downloaded podcasts were not able to play.

Additionally, in the settings I "refreshed podcast artwork" and deleted orphaned files and links. So overall it seems to function acceptably now.

Again I'll head over to the tracker, it would be nice if there was a way to control it not automatically doing a refresh at start for us poor internet users (Ethiopia is a single carrier country, and it is slow!)

Re: Podbird reignited

@Elleo thanks for the geat app it really is an essential one! I only have some trouble with it freezing for at least a minute each time I start it.

I am on a N5 with a fairly slow internet, so I don't know if the freezing is as it refreshes / updates podcasts or?? Meaning I am not sure if it is my N5 performance or it is my network that is freezing things up. Any pointers on debugging to see what the freezing is from?

I am subscribed to 22 podcasts.

Thanks for any advice.

I am on a N5 and would like to sort how to have audio from a website keep playing after the screen is turned off. Will keep trying things...

@mateo_salta yes but everything wiped out at update. Good discussion from the link @GizmoChicken posted. The way I see it the challenge is a bit of a "chicken and egg" problem. Some devs want "pure linux" so they don't come. Since they aren't here, development team is small and can't expand to a broader scope.

At the same time, very good points have been made about needing to be compatible with android devices. Pinephone is a tinkerers delight, but is less powerful than a N5 from 2013. So I see Ubuntu Touch as a viable "daily driver" in its current form for halium devices / former android phones. But a lot of people want "pure linux phone" which is hard to have as a daily driver yet. It is a different group.

Ok enough for now

Is there any consideration in having a separate build that is not a read-only filesystem, e.g. more of a standard Ubuntu install? If there were something like that, I would think it could stand as the main development branch that would allow faster upgrade to 20.04 / wayland / systemd / etc. Then it could be a testing ground that new releases of the "stable" or "consumer" read-only system would come from.

It would also not frustrate any potential developers who want "standard Linux on a phone" (mobian, manjaro, fedora, etc.).

In summary, I understand a lot of the reasons behind the read-only system for stability, for security, for end users, etc. but I fear it keeps away possible developer interest that would benefit Ubuntu Touch in the long run if it were more "traditional Ubuntu" on a phone?

People could be trying all sorts of things like flatpak / snap / different apps, etc. I know there is Libertine but there is some performance issues and it isn't available everywhere, etc. So take the chains off and see what happens? I suspect a large growth of the community (???)

I know that flatpak has been discussed in the past, with the common feedback being that there are many flatpak apps unsuitable for mobile, so it isn't a priority to consider implementing flatpak.

With recent pinephone developer communities, however, many have started using and recommending flatpak apps that use responsive design. Many of the apps recommended for mobian, for example are installed using flatpak: https://wiki.mobian-project.org/doku.php?id=apps

Some examples are "foliate" (epub reader), "podcasts", "cawbird", etc. All work reasonably well under mobile.

So, I suggest that integrating flatpak to enable flatpak app installation would be a big win for Ubuntu Touch: it would reduce the pressure on custom click apps only to meet the immediate needs of users.

Possibly a move to 20.04 base is needed first before flatpak would run decently, but I think flatpak support for 16.04 is good enough?

@Keneda I think the main challenge is that it is a webapp and only a single version. So it needs to be used online, no hilighting, no notes, no multiple versions, no commentaries, etc. Maybe the request should be more clear: an offline full-featured native bible app.

@mnjrupp @arubislander @Nathan123 I was thinking of a "Better Bible App" also. It would be great if it could use Crosswire / sword modules like AndBible does. Then access to commentaries, etc. would be possible.

So maybe the question is if something like Xiphos / Bibletime for traditional Linux is easier to port over to Ubuntu Touch or if it would need to be a "build from scratch qt quick" app?