[Tinkerphones] ZeroPhone site offline

Paul Boddie paul at boddie.org.uk
Wed Jan 5 01:28:49 CET 2022


On Tuesday, 4 January 2022 19:30:38 CET H. Nikolaus Schaller wrote:
> > Am 04.01.2022 um 18:34 schrieb Paul Boddie <paul at boddie.org.uk>:
> >> It’s extremely sad that after all these years with all our technological
> >> advancements and choice of free software projects, getting the very
> >> basic task – solid and reliable phone calls with tolerable
> >> audio quality and battery life – right, still seems to be unachieved.
> > 
> > Yes, we're back to the featurephone here! Maybe it needs doing after all.
> 
> Well, not really.
> 
> Making good phone calls does not require to reduce a device to feature
> phone level.

I wasn't being totally serious, but with regard to software, delivering a 
robust featurephone experience would be a start, even if it is on something 
which is capable of more.

Actually, a kind of dual personality system might address some of the general 
issues with vanilla Linux on smartphones, and I suspect that Linux alongside 
real-time components is a recognised architectural style for some kinds of 
devices. I did wonder whether supposedly mandated features of cellular network 
communication such as emergency calls or notifications might not actually 
demand some kind of separate component or personality, although I could 
imagine the regulations having been loosened a bit in recent years.

> QtMoko was a nice example. It did work really well on GTA04 incl. phone
> calls. And Replicant 4.2. Both did have good audio quality and everything.
> 
> And the kernel was the best one we ever had: 3.7-neilplusplus.
> 
> It is still archived: https://projects.goldelico.com/p/gta04-kernel/
> And the most feature complete kernel was 3.12 although not as good
> as 3.7.
> 
> But it wasn't possible to merge all good aspects of those kernels into
> a single one back then.
> 
> What also forced us to move to newer kernels was
> a) upstreaming - they did no longer accept code developed for 3.7 or 3.12
> and reworking patches to become upstream compatible takes more work
> than initially developing them and testing that they do what is expected
> 
> b) GTA04A5 - had changed some hardware (WiFi and sensors) and that was
> too difficult to add (backport) to these old kernels

Linux kernel development gymnastics, in other words. In recent times, I have 
been looking back over operating system projects from the last few decades, 
and I am somewhat reminded of what happened with the Mach kernel: various 
companies stuck with an earlier version having released products based on it 
(such as NeXT, Digital) whereas others followed the development path into the 
Mach 3.0 microkernel era (such as IBM). Although the latter path had more 
promise, the former path may have had greater commercial longevity, with 
NeXTSTEP evolving into what passes for Mac OS these days.

As far as I understand it, Mach was originally delivered as a more modular 
form of the BSD Unix kernel, and it was adopted as the OSF/1 kernel for use by 
a number of different companies. Presumably, stability and portability were 
priorities for its use by various interested parties, although Digital was 
perhaps the only company to really give it a go, delivering it for their Alpha 
architecture systems (first as OSF/1, later using the names Digital Unix and 
Tru64).

I wonder if we don't actually see similar dynamics at work today. Various 
enterprise Linux distributions run rather old but maintained kernels and user-
space software. Naturally, this is only a game for the biggest of players, 
though, which is why I wonder about projects that could change this dynamic 
somewhat.

> Unfortunately there was also no breakthrough on reestablishing a working
> build-setup for QtMoko. Several contributors worked hard on it
> but we never reached a level productivity where it was just a git clone+make
> or apt-get source + debuild for anyone who wanted to join efforts.
> 
> Basically the concapt was simple:
> * untangle QtMoko into really separate debian packages
> * add proper debian build scripts (instead of having a single big 2-days
>   Makefile needing to set up a virtual machine)
> * place sources and binaries on some server
> * arrange that kernel and user-space are more in sync

I think that the Qt library dependencies were also rather old, were they not? 
After a while, it becomes a huge burden to try and deliver packages based on 
older libraries and frameworks that the distributions have deprecated and then 
removed.

> But I also have good news. Just these days I finally fixed a deeply
> buried memory leak in QuantumSTEP which made devices unuseable
> because all applications were oom-killed after ca. 1 hour.

Sounds like a job for Valgrind!

> Since QuantumSTEP follows the ideas of separate debian packages
> it is easy to work on this or that. E.g. make the phone dialer work
> again (btw. internally it will be compatible to the CoreTelephony.framework
> from Apple).
> 
> And, not to forget that Andreas has written Simple-gsm-gui which is
> just a debian package waiting to be installed on all LetuxOS devices
> (well, not all have modem or are supported by AT commands).
> 
> So in summary it does not need much to get phone calls working - if
> we have hardware and a kernel that supports modem + audio. Independently
> how many features (just address book or up to messengers, browser,
> navigation, games etc. the remaining software has).

One aspect of GTA04 adoption that was awkward was the need for either 
FreeRunner parts or 3D-printed parts, and I wonder whether things today are 
different enough to change the equations. Various retrocomputing projects 
appear to use 3D printing quite extensively, and it seems that even the more 
"primitive" forms of 3D printing have matured and are offered by a wider range 
of seemingly reliable vendors.

Paul




More information about the Community mailing list