[Tinkerphones] Librem 5

[H. Nikolaus Schaller]

> Am 13.02.2021 um 15:28 schrieb Jonas Smedegaard <jonas at jones.dk>:
> 
> Quoting H. Nikolaus Schaller (2021-02-13 14:53:00)
>> 
>>> Am 13.02.2021 um 11:52 schrieb Jonas Smedegaard <jonas at jones.dk>:
>>> 
>>> Quoting michael spreng (2021-02-13 10:45:18)
>>>> In December I received my librem5 phone and now had some time to try 
>>>> it out. It seems to work reasonably well, can make phone calls and 
>>>> messages. Though there is no support yet for the camera.
>>> 
>>> Seems camera support saw progress for the low-level driver part as 
>>> recent as yesterday: 
>>> https://source.puri.sm/Librem5/linux-next/-/merge_requests/309
>>> 
>>> User-level access to camera seems tracked here: 
>>> https://source.puri.sm/Librem5/Apps_Issues/-/issues/6
>>> 
>>> Using the camera from sripts seems possible since 2 months (but possibly 
>>> specific to certain revision of the phone, or maybe the devkit): 
>>> https://source.puri.sm/Librem5/linux-next/-/merge_requests/255
>>> 
>>> The phone ships with the more stable "amber" release of PureOS.  Geeks 
>>> might wanna explore the in-progress "byzantium" release instead, to get 
>>> and play with bleeding edge changes: 
>>> https://developer.puri.sm/Librem5/Development_Environment/Phone/Troubleshooting/Reflashing_the_Phone.html
>>> 
>>> 
>>>> Though programs not adapted for the phone screen are rather weird, 
>>>> like vlc.
>>> 
>>> A geeky way to locate _some_ adaptive apps is to look for packages 
>>> depending on libhandy-1-0 (or libhandy-0.0-0).  That only covers GTK 
>>> apps, though - I am unaware if any such package-level indicators exist 
>>> for Qt-based apps like VLC.
>>> 
>>> The user-friendly way is to use the appstore, which shows only adaptive 
>>> apps - and yes, there are only very few so far...
>> 
>> I am sure this will change.
> 
> If by "this" you mean availability of adaptive apps,

yes.

> then I agree: Seems 
> to me there is enough momentum - e.g. multiple vendors reusing code from 
> each other, all tied to mainline Linux
> 
> 
>> Our GTA04 history shows that the basics must work and then come apps. 
>> Unfortunately it is a sisyphos work to make the basics work and keep 
>> them running... So manpower to keep pace with upstream kernel releases 
>> is key.
>> 
>> The main reason why we were (are) stuck with QtMoko and Replicant 
>> is that the kernel is still not in a perfect shape like people need
>> so that they can focus on improving their apps. And in the meantime
>> nobody knows any more how to rebuild QtMoko and Replicant from scratch
>> on a recent build system.
> 
> Seems to me the failure is directly tied to getting code pushed 
> upstream.
> 
> Obviously when upstream project is dead (as is the case for QtMoko) 
> there is no way to upstream - apart from taking over as upstream.  And I 
> guess over-the-fence upstreams like Qt and Google can be painful to push 
> changes to (e.g. require copyright assignment), but I am not familiar 
> with the details of those.
> 
> Purism evidently invest in pushing code to mainline Linux and u-boot 
> (and other projects higher up the stack as well).  Time will tell if 
> they push enough, and if there continues to be enough momentum.

Indeed.

For the fate of the GTA04, the team pushing code became smaller and smaller
over time because there is less and less reward from doing. So momentum
was lost.

So if I look back the past 10 years of pushing GTA04 fixes to kernel.org we
always had been between 95 and 98% upstreamed. But never got beyond. Rather
we spent more and more time of fixing upstream regressions in that parts that
upstream maintainers didn't like.

But app developers (like those developing QtMoko) did expect 100% which we
even have not achieved many years after the active development of QtMoko ended.
Still we can demo the old QtMoko and Replican 4.2 stuff un latest upstream
kernels but they are not good enough for daily use.

And pushing something upstream to kernel.org needs more than volunteers can
provide. I think the latest statistics I did see is that less than 20%
of upstream kernel contributors are volunteers. The majority is payed
by big enterprises (cloud and SaaS providers, semiconductor industry).

Let's hope the Purism business model allows to keep this running.

My key learning is that quality of the overall system is key. Not the
hardware or the kernel or the user-space alone. Everything must fit
together to give users a smooth experience. And that is too much for
small initiatives.

> 
> I am optimistic.

+++

BR,
Nikolaus