Please address the baseless assertion that "Unity8 for desktip (sic) is officially dead" that was recently posted by a reader in the Phoronix forums.

See the post, and my reply to it, here: https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1038951-ubports-ubuntu-touch-unlikely-to-move-to-ubuntu-18-04-anytime-soon?p=1039276#post1039276

Note that, in response to the post, I tried to explain otherwise. But your explanation would carry more weight (and would probably be more accurate) than my explanation.

"The report of my death has been grossly exaggerated.” - Mark Twain

Whether to develop and polish features on 16.04 for the time being, or to move to 18.04 as soon as possible, is discussed starting at about 33:15 in Ubuntu Touch Q&A 32.

Personally, I hope that the UBports team will move Ubuntu Touch to 18.04 as soon as practical (not as soon as possible).

The UBports team is making progress with Unity8 for the desktop on 18.04, including progress toward full Wayland support, and I'd like to see the same Wayland support on the phone. But the wait-and-see approach taken by the devs seems most prudent. And who knows, maybe the puzzle pieces (with Mir, systemd, etc) will fall into place, allowing them to move to 18.04 more quickly than anticipated. Or at least that's my hope. :)

@unisuperbox said in Linux kernel，Why not upgrade to the latest 4.15?:

Treble does not remedy that situation [of upgrading to newer kernel versions].

Thanks much for the clarification. Thinking more about it, you're probably correct that Project Treble doesn't (at least for now) help with updating from an old kernel version to a newer kernel version.

Here's a snippet from an XDA Developers article that lead me to believe otherwise:

Google is also requiring new devices launched with Android Oreo to be configured to support Project Treble right from the start, which will hopefully make it easier to upgrade Linux kernel versions in the future, and reduce the efforts that will need to be put into backporting security patches.

Emphasis added. I suppose that the author means to refer to "minor" versions.

Even so, as discussed in another XDA Developers article in reference to IoT devices, even if Project Treble won't help get devices "to be consistently updated to new kernel versions in the near future, across all manufacturers, but simplifying the work to “just” applying the latest patch for the kernel version that they are on may be enough to convince some companies to provide that basic level of ongoing security for their devices." And that's a good thing. :)

@lakotaubp and @MK73

I notice that, with regard to installing the Unity8 desktop preview, the blog post links to instructions found on another blog post.

Suggestion: Although the instructions found on linked blog post are currently accurate, I suggest that you consider instead linking to instructions that, if needed, can be more readily updated, namely those instructions found here: https://github.com/ubports/unity8/

Also, linking to the instructions found at the above suggested location promotes filing issue reports for the Unity8 preview in the appropriate place, namely in the Unity8 issue tracker.

@flohack said in Linux kernel，Why not upgrade to the latest 4.15?:

Because every device is stuck on the kernel the vendor made for it. Most drivers are proprietary and we do not have sources, and also with all kernel updates many internal interfaces change.

I may be wrong about this (and I'd welcome correction if I am), but my understanding is that Project Treble (which is currently only supported on some very new phones) aims to help remedy this situation.

Also, I'm seeing more phones being shipped with kernel 4.4, which, although not the latest kernel, will at least be supported until Feb of 2022.

Of course, neither of the above helps with older phones that don't support Project Treble and that shipped with older kernels.

@arubislander said in Saturday Is Q&A Day! Q&A 32 Saturday 14/07 19:00 UTC:

While I understand what you are saying I disagree with your proposal. Moving to 18.04 might be a bigger task than moving to 16.04, because in 16.04 Touch was still being supported and Canonical had already done at least some preliminary work.

My question was intended for the devs, and I didn’t mean to start a debate among us users. But I appreciate your reply. What’s more, your reply demonstrates that I may not have sufficiently articulated my thoughts.

You are, absolutely and without question, correct that moving to 18.04 will be a much bigger task than moving to 16.04. That said, provided a few puzzle pieces fall into place (and it looks like some of them are starting to fall into place), moving to 18.04 may go faster than you expect.

To clarify, I fully support completing 16.04 OTA-4, and I fully support completing 16.04 OTA-5. However, with regard to what would be “good enough” for 16.04 OTA-5, my thinking is that, provided some puzzle pieces fall into place for 18.04, the devs should focus on the “bugs” listed in the milestones for 16.04 OTA-5 and leave the “enhancements” listed there for a hopefully soon-to-be started 18.04 OTA-6 or 18.04 OTA-7. Of course, what’s “good enough” may need to be reevaluated from time to time.

As for skipping 18.04, and waiting for 20.04, in my opinion, that would be a very bad idea. But your question seems intended for the devs, so I’ll let the devs to respond to your question.

I realize that the UBports team is currently focusing on 16.04 OTA-4, and that plans for 16.04 OTA-5 are still evolving. Nonetheless, looking at the milestones page, I can’t help but notice that many “enhancements” are currently being considered for 16.04 OTA-5.

My thinking is that 16.04, although 100% necessary, only needs to be “good enough” to serve as a reliable stopgap, and that development should start focusing on 18.04 as soon as practical.

Question: Provided some puzzle pieces fall into place for 18.04, would you consider restricting 16.04 OTA-5 to bug fixes (with few or none of the "enhancements" currently listed in the 16.04 OTA-5 milestones page), so that you can begin focusing more fully on 18.04 development?

Edit: After considering a reply from @arubislander to my comment, I have italicized the phrase "provided some puzzle pieces fall into place for 18.04" found in my original question, to add emphasis. Also, I have clarified that the term "enhancements" refers to the "enhancements" currently listed in the 16.04 OTA-5 milestones page. Please see my comment found here for additional clarification.

@alan_g said in 18.04 desktop - getting it working again:

I found one problem, which I fixed by hacking the launch script

Just to be sure we're seeing the same problem (which we probably are), I still posted my results in in the PR.

I'm not sure how either problem was avoided before.

Note that, in addition to posting results for Mir 0.32.1 RC4 (installed from ppa:mir-team/rc), I also posted results for Mir 0.32.0 (installed from the UBports repo). Hope that helps.

@alan_g said in 18.04 desktop - getting it working again:

We need to understand what is happening, could you leave a message on the 0.32.1 PR? Preferably with informative log messages?

I posted in this PR for Mir release 0.32.1. I mostly just reiterated what I posted here, but I did add a few minor details regarding my system.

As for posting informative log messages, I’m not sure what to look for, or even where to look. With some guidance, I’d be happy to try. But realistically, the quicker approach would probably be for someone else to confirm what I’m reporting.

Perhaps someone who is also testing Unity8, but who is more technically savvy than me, would be willing to test Unity8 installed as described here along with a Mir 0.32.1 RC installed from ppa:mir-team/rc? Do you know of anyone who fits that description, @pixelr0? :)

After installing Unity8 using the instructions found here, I was able to log into Unity8 from either GDM or LightDM.

I upgraded from Mir 0.32 to Mir 0.32.1 RC4 via ppa:mir-team/rc, and now, I can no longer log into Unity8 from either GDM or LightDM. What’s more, when I merely attempt to log into Unity8 with Mir 0.32.1 RC4 installed, I must reboot my system before I am again able to log into GNOME or Unity7.

@mariogrip and/or @alan_g: Is Unity8 currently installing a modified version of Mir 0.32 rather than upstream Mir 0.32?

If Unity8 is installing a modified version of Mir 0.32, then I would expect Mir 0.32.1 RCs likely not to work, and I’ll stop attempting to test the Mir 0.32.1 RCs for now.

@alan_g: If Unity8 is installing upstream Mir 0.32, shouldn’t the Mir 0.32.1 RCs from ppa:mir-team/rc be expected to work with Unity8? Or am I missing a step?