News and Updates
OTA-10
OTA-10 is out on the 14th of August. From that point on we will welcome some post-release feedback from general users.
There are some camera fixes for Nexus 5 and the FP2. Placements and rotations have been sorted out now. Location finding on all devices will be much slower with the first capture but will be more reliable after that. We don’t have a replacement yet for the wifi analysis stage but removal was still the best option. Once you have an initial fix, it can take a minute every time you use that feature again but then it works and it retains where it was last time. We will provide a new accelerated fix backend as soon as we can. The current solution is temporary but it does help considerably overall.
Alfred has fixed audio support in 7.1 devices. Anyone porting to one of those devices can use his tweaks now.
SurfaceFlinger is used to make the camera in some 7.1 devices work. That module is now integrated in OTA-10 which will also aid porting projects.
Q&A Changes
A new technology was used to manage this Q&A. There were some teething problems with connectivity but the new interface is nice.
Ports
Alfred reported that the Sony Xperia X port now has some sound issues caused by new components in Halium - for example, miniaudioflinger. Calling is also still an issue. Several devices have met very similar obstacles. Ofono is what we use at the moment for calling functions and we need to fix a number of bugs with that. Some other progress with Xperia X has been exported to other 7.1 devices, so a number of them are advancing together.
Unity8/Dash
New Unity8 and Mir are really working quite well, as the growing number of people using Edge channel as their daily driver can confirm. We are now very close to moving Edge into Devel. We need to increase the amount of QA feedback and shifting the channel will expand the user base. Of course we need to get the release of OTA-10 out of the way first.
We particularly want to see what people think about the new Dash. The changes beneath the surface are very extensive but they will not be directly visible to users. The Dash will be noticed though. Features such as multibranch and workspace have been made possible by the architecture improvements and those will be introduced later on.
Various alternatives to the Dash setup have been suggested but it is generally sensible to reduce complexity. It means that there is less to maintain and less to go wrong. The code for the Dash had already been mostly done by Canonical, so why waste their efforts? There is a search for apps in the Dash, just like desktop. There are already some launcher app alternatives in the OpenStore, so you can customise if you wish.
A question was asked about whether the empty space left by the Dash could be used for something more useful than just wallpaper? The answer given was that yes of course it can but doing so is not a priority for core developers at the moment. If a group of new developers come along with an idea, they could potentially make use of that screen space.
TELEports
There is a new TELEports update currently undergoing final QA. There will be two incremental releases shortly. The ‘last unread message’ feature will at last be implemented. Voice message and video note support will also come soon. Receiving them will come first, with the ability to send them coming later.
A poll about the most wanted feature in TELEports had 61 participants. The results were pretty even, backing sticker sending and the integration of TELEports into ContentHub (so you could send a photo via TELEports, by selecting directly within the Gallery app). The third feature on the wish list was the ability to share contacts.
Florian thanked our sponsors and the individuals who have sent donations.
Questions
Will some elements from Launcher modular app be integrated into the system, as standard features or options?
As it says above, it would be great to be able to implement every wish but we have to go cautiously. Developing is a learning process. The feedback from Devel use will give us better data to work with. One consideration is that we need a good way to integrate any chosen launcher into a desktop environment. That needs to be part of the design thinking.
Stability is always our number one priority. Getting all the advances safely into stable is our first aim.
The more changes we implement, the more bugs we will have to deal with. Regression bugs are absolutely the worst type. Breaking existing stuff is far worse to the reputation than struggling with something that users have not yet come to rely on. A further point is that we want to maintain the momentum of OTA updates.
As those in the OpenStore already show, a launchers can be in app form. There is no reason why more cannot be developed, as plugins to the system.
Will the next update make the OS faster or slicker?
Quite honestly, OTA-10 will not do that but when we come to OTA-11 there will be less input lag and you will start to notice various performance improvements . Qt are bringing in very big speed improvements with new builds. Since we benefit from their upstream, we will see substantial improvements, as we integrate their new versions.
If we switch to a new Ubuntu version, will Qt6 just magically work?
The answer is very definitely not. Having said that, we are already working to upgrade NewtworkManager, Bluez etc. within the existing setup, by backporting selectively. We will certainly not move to a version of Qt which does not align with LTS version of Ubuntu. If Qt6 ends up very different from Qt5 it would involve a huge amount of work. App developers would be impacted too. It is probably at least a year before we can even start to think about using it. Don’t forget though that Qt 5.12 has some major improvements, so we are by no means at the end of the road for Qt enhancements within 16.04.
Should great priority be given to fixing bugs affecting supported devices, rather than on taking the whole OS forward?
As always, this is a matter of resources but the recent work on the FP2 shows that these snags are not being neglected. The fact that the bugs still exist show that they are very stubborn though and sometimes intermittent. They are the kind of bugs that by definition need a lot of effort to solve. We cannot hold back on benefits for all devices by dwelling on issues which affect only some devices. One important consideration is that we need to maintain our connection with external projects. We owe it to them and at the same time, they will move on without us if we fail to keep up. A good example is the Pinephone project. Whatever priority we do set, there will always be someone who is upset by our decision.
When we will switch to 18.04?
As explained before, systemd is the key issue. Older devices will struggle because that needs kernel changes, in order to work. At some point, we will probably have to go back to the idea of ‘legacy’ devices and some older devices will be stuck on 16.04 forever. Anyway, we are not at that stage yet. We need to continue updating 16.04 first. 20.04 will almost certainly be our next step, not 18.04.
Our kernels are getting ancient now. Canonical may still have some archived development work that we can utilise but devices like the MX4 would be a major problem. Almost inevitably, some devices will be left behind, given the scale of the task. At some point we will have to ask how old and outdated a device can be and still expect support? We have to move forward to newer devices, so we would expect there to be a gradual transition. We need to discuss this. Probably old devices will stay on 16.04 when we move on. We don’t want to drop support for any user but as 2021 marks the end of LTS for 16.04 we don't have to make any decisions for a couple of years yet.
Has any progress has been made on adding a Tor button?
Unfortunately it is not just a matter of a button. We are upgrading NetworkManager and any implementation of Tor would necessitate adaptations to the NetworkManager build. Canonical made a lot of patches, when adapting NetworkManager to phones, so each patch is a potential obstacle to be overcome if we do decide to build in Tor compatibility. In short, it would be a very big task.
Could vendor kernels be patched to Mainline standard?
Well, patching on that scale would be an immense task but that is not even the biggest problem. Proprietary drivers are a massive hurdle. We would either have to write our own somehow or create new compatibility layers to connect between old and new drivers. In practical terms, that is an impossible task. As it is, we backport to kernel on a very selective basis. Phone manufacturers typically do not provide kernels with Linux support; they only build for Android. So, it is still very difficult, but at least it is possible for Pinephone and Librem5 to smash through that barrier because they are not stuck with the ancient Android kernel.