Convergence is mostly a software thing. There are two parts to this:

1. flexibility: the software including shell and application GUI adapts to the capabilities of the hardware it runs on.
   This means that the same software, with the same features, works well on a desktop, a phone or a toaster.

2. agility: the software including shell and application GUI adapts to changes to the capabilities of the hardware is running on.
   This means that connecting a display, keyboard, dock etc. will enable user interactions optimized for these.

Most existing software is not designed for either of these goals. The Ubuntu Touch experience of using "desktop" apps in Libertine speaks to this, it is possible to use these applications, but the interaction is poor because these apps do not adapt to the hardware. This can change but, like any change, there will be costs, pain and resistance until suddenly it will be done and everyone wonders why it was ever any different.

But the software is only a part of what is being alluded to here. Real use-cases are not about using a specific piece of software, they are about accomplishing goals: publishing something, learning something, meeting someone. That needs a combination of user data, software and access to hardware.

I've had a long career in software development and seen computing shift from centralized "mainframe" computers that hold the data and programs for multiple users to "personal" computers that hold a users data and programs and back to centralized "clouds" that hold all the data. That change has been driven by economics: changes in the costs of computers and of connecting them.

While there are legitimate privacy and security concerns the economic drivers are currently pushing towards centralization and connections. Many apps are little more than optimized front-ends for data and computational services elsewhere on the internet. I think this trend will continue before a readjustment back towards "personal" computation.

In this context, any "one device" we might carry is more about having the keys (or passwords) we need to accomplish our daily tasks than carrying all the software and data we use. If both my laptop and phone can support all my daily tasks interchangably, browsing the web, emailing, Telegram, IRC, software development, video calling, phone calls, SMS, etc. then I need only take the one best suited to the occasion. Having the same software and keys on both is what would make them interchangable. (And yes, phone calls are best on a phone while software development is best on a laptop, but making both possible gives me control.)

@domubpkm the image you posted shows the dark theme, what do you think is wrong? (Remember, the theme affects the app, not the website you're viewing.)

I'm just curious (I'm content to let updates come when they arrive) but...

Why does sudo system-image-cli -v -p 0 --progress dots have to run via adb? Can't it work from the terminal?

@mic_ said in Observations on battery life - please share your experiences:

After 9 hours in standby (without turning on) the phone dicharged from 100% to 63%. In the same time my BQ E5 discharges from 100% to 98%.
Actually everything else on my Nexus 5 is really working very fine and I love this phone. But it is still loosing so much energy power while I am not using it that this is still a knock-out argument for this beautiful phone / ubuntu system combination! What the hell it is doing all the time while laying around?

I've seen it do that too. But, more often, I've seen it hold charge better and be around 90% after the night. (Still not great I agree, but tolerable.) On these occasions I've not seen anything suspicious running top, but that doesn't really tell what was happening when the screen was off.

I have a long running suspicion that the radio hardware is not always in the state the software believes it to be in. In this case, that "off" shown by the software isn't actually "off". This could explain both battery life problems, and also the flakiness of hotspot. (I'm not sure how to go about proving that idea.)

@sander-klootwijk @arubislander

I too am in The Netherlands, specifically Baarn "close to Amersfoort".

(Long term I'm in the UK, but not for a few more weeks.)

I'm interested in the progress updating to Mir 1.x (no surprise there):

• how well is it working in development?
• Is the phone graphics stack migrating to Wayland in the first iteration?
• Or remaining with the mirclient API for now?
  • If so, when the phone graphics stack migrating to Wayland?
• Will "desktop" apps running on the phone use Wayland? Or Xwayland? (Or Xmir?!)
  • NB GTK+ apps (for example) on Xenial use xdg-shell V5; Mir does not currently support this obsolete Wayland extension, will this cause problems running "desktop" apps running on the phone?

---

[Update]
I now realize that the answer to "Is the phone graphics stack migrating to Wayland in the first iteration?" has to be "no":

• There are still some mirclient APIs that have no equivalent Wayland extensions (two specific cases being "trusted prompt session" and "lifecycle" events).
• It would also be non-trivial mapping the "content hub" behavior to Wayland's data exchange protocols.

( These considerations will also impact the Unity8 Desktop to a lesser extent.)

@doniks said in 2019: Time to make Unity8 great again?:

Wouldn't it then be more logical to have a greeter that is a wayland client? Or maybe the login managers from some other desktop environment could be used.

Curious what you think.

The Canonical design was for unity-system-compositor [USC] to be a system wide Mir server that supported both the greeter and login session based shells. Only USC would interact with the hardware, it would see the greeter and session shells as Mir clients. The session shells would use the mirclient API (a.k.a. "Mir-on-Mir") but that requires "Mir EGL" and is no longer possible.

This architecture has a number of desirable features: only one system-wide task has to negotiate access to the hardware, and that task also controls transitions between user sessions, login screens and lock screens.

Once Mir has a Mir-on-Wayland platform it will be possible to retain that architecture and use Wayland instead of the mirclient API.

Going Wayland is going cross-distro

One of the big changes has been to the Mesa graphics drivers: Ubuntu used to carry a "Mir EGL" distro patch that enabled EGL clients to use the "mirclient API". Because Mesa changed in ways that broke that patch badly it was dropped in Ubuntu 18.04. I'll discuss this further below under "Going Wayland".
...
Unity8 is based on Mir and @mariogrip had done the work needed for Unity8 to run on Ubuntu 18.04 without "Mir EGL" by using Wayland instead of the "mirclient API" (which is supported by recent versions of Mir).

In the OP I neglected to mention one very useful side-effect of these changes: Because Unity8 can now run without the "Mir EGL" distro patch it is no longer restricted to running on Ubuntu.

As recently mentioned on the Mir forum Mir works on the following distros:

• Arch (in the AUR)
• Fedora (in the archive)
• Ubuntu (in the archive)
• Debian (not in the archive - yet)
• Pop!
• Solus
• PostmarketOS (There are a few additional patches to be upstreamed)

On most of these distros developers have also got Unity8 running.

I've noticed a few discussions recently regarding developers getting involved in developing Unity8. I don't know all the answers myself, and don't have the free time to find them, but I think I can start a constructive discussion.

A bit of history

The Unity8 shell comprises a lot of inter-related projects and dependencies. These have to be coordinated and installed together, this worked best in Ubuntu 17.04 at which point it was possible to install a usable Unity8 desktop from the archive with a single command.

When Canonical withdrew from the project they understandably stopped maintaining these projects and dropped them and a number of the dependencies from the archives. There have also been some incompatible changes to some of the dependencies.

One of the big changes has been to the Mesa graphics drivers: Ubuntu used to carry a "Mir EGL" distro patch that enabled EGL clients to use the "mirclient API". Because Mesa changed in ways that broke that patch badly it was dropped in Ubuntu 18.04. I'll discuss this further below under "Going Wayland".

The UBports team has done its best to maintain the projects and dependencies in the UBports repo, but this hasn't been the most urgent thing to work on and they have not dealt with everything that has changed.

Getting started

I've never built the majority of Unity8 components from source, not am I sure which branches are canon in the UBports source repositories. I'm sure developers could figure this out, but it would save everyone time if there were a blogpost.

The bits I do know:

1. The first, best hope is 18.04LTS.
   Other distros and more recent series are possible, but let's make it work in one place before fixing everywhere.
2. The UBports repo at http://repo.ubports.com/ contains the dependencies, and needs to be added to apt sources.
   echo "deb http://repo.ubports.com/ $UBUNTU_CODENAME main" | sudo tee /etc/apt/sources.list.d/ubports.list
wget http://repo.ubports.com/keyring.gpg -O - | sudo apt-key add -
3. This is messy enough accidentally break your system: use test partition, VM, or secondary laptop as appropriate.
4. There are more detailed instructions in the README: https://github.com/ubports/unity8

Going Wayland

This is the bit I understand best (because I work on Mir). It is also, I think the biggest cause of deterioration since 17.04.

Unity8 was originally built using the "mirclient API" which was designed for convergence. But for "mirclient API" to be useful this needs support in client toolkits and even with Canonical pushing it this was never great. Since then, it has been dropped from GTK+ and SDL2.

Unity8 is based on Mir and @mariogrip had done the work needed for Unity8 to run on Ubuntu 18.04 without "Mir EGL" by using Wayland instead of the "mirclient API" (which is supported by recent versions of Mir).

However, Wayland is not a "drop-in" replacement for the "mirclient API" and there are some limitations apparent on Unity8 desktop:

1. GTK+ applications assume CSD and add shadows which Unity8 is "not expecting". That produces weird effects, like a disconnected, second titlebar.
   There is, theoretically, a solution to this upstream: https://github.com/MirServer/mir/issues/664
2. For X11applications the integration provided by Xwayland is even worse than that previously provided by Xmir
   Part of the solution to this is upstream: https://github.com/MirServer/mir/labels/Experimental
   2.1 But this isn't all: https://github.com/ubports/unity8/issues/56

I am biassed by my involvement in Mir, but these are issues that an interested developer could tackle to make a significant improvement to the Unity8 desktop. In addition, they are easier to work on than Unity8 as the Mir project has significantly fewer dependencies (all of which are in the Ubuntu archives).

Another effect of the loss of "Mir EGL" in Mesa and the consequent switch to Wayland ls that the "Mir-on-Mir" support needed to use the Unity greeter is no longer available. Some work has been done on providing a "Mir-on-Wayland" graphics platform in Mir, but that needs significant rework (it is on my list of things I want to get to, but if you fancy taking it on get in touch).

Note: There are additional limitations to using Wayland on the phone that need to be addressed, but I'm keeping this discussion to Unity8 desktop.

Other stuff

Unity8 was not finished in 17.04, and quite a few of the things that were "done" need to be updated. I'm not an expert on this so I'll leave detailing a list to others.

What I do know:

1. The issues list: https://github.com/ubports/unity8/issues

2019: Time to make Unity8 great again?

I hope this provides a bit of impetus to developers interested in contributing to Unity8 to progress further. Even if this post is simply a place for potential developers to declare their interest and meet each other it will have served a purpose.