[Tinkerphones] ZeroPhone site offline

H. Nikolaus Schaller hns at goldelico.com
Mon Jan 3 20:12:32 CET 2022


Hi Paul,

> Am 03.01.2022 um 18:43 schrieb Paul Boddie <paul at boddie.org.uk>:
> 
> On Sunday, 2 January 2022 22:01:51 CET H. Nikolaus Schaller wrote:
>> 
>> you have probably pinpointed the most important aspect of all discussions.
>> 
>> We have no high-quality power management in any of the devices...
>> We spend (spent) a lot of time to make it work, get hardware out just
>> to get the same feedback as you have cited above.
>> 
>> We (as the OpenMoko and GTA04 community) have faced it. I think also
>> the Librem 5 has. And the Pinephone you have cited.
>> 
>> What should be different?
>> - well it needs a team dedicated at making hardware reliable and improve
>>  power efficiency
>> - this needs a lot of insights into hardware and good doscumentation
>> - and - maybe - a stable basis to work on
>> - there should also not be fragmentation between several groups
>>  having multiple desktops to choose from is good, but having multiple
>>  power managements?
> 
> To what extent do you think Linux itself is part of the problem here? We both 
> know that it can be frustrating to adapt Linux to the realities of various 
> devices, and then there is the matter of getting modifications adopted in the 
> mainline. None of this is a particularly efficient process, and so doing 
> things "the right way" doesn't really fit in with getting a product to work 
> well, unless you have lots of resources, of course.
> 
> It seems to me that, as you say, you need people with experience who have 
> access to decent documentation, working at the lowest level of the software 
> stack, making sure that the hardware is functioning properly. All of that is 
> hard enough without a bunch of other people telling you that they just decided 
> to rework the APIs and that you have to change your code to follow suit, or 
> without weird regressions or deprecations that have been introduced elsewhere.
> 
> I've presumably mentioned the use of L4Re to test the Letux 400 and other 
> MIPS-based hardware on this list. One significant reason for doing so is to 
> just eliminate all the noise from "Linux" when familiarising myself with the 
> hardware and exploring how it works. And once one does that, one wonders why 
> there can't just be a layer dealing with the hardware in a proper component-
> based architecture with things like documented interfaces and all the things 
> that people have learned from object-oriented programming over the last few 
> decades.

That is a very good question. On one hand Linux makes it possible to get
90% of things where there are no resources to get them coded, debugged,
security checked, stabilized etc. For example the whole networking stack.
Or MMC/SDIO. Or CPU startup and so on. And keep it in sync with user-space
distributions.

It would be impossible to start a new kernel project without being even slower
than with Linux. If I look at the deltas LetuxOS has not upstreamed it is less
than 0,5% of the total Linux code which we have touched at all.

L4Re is a nice project - but if it does not support all sorts of peripherals
and user-spaces and that for a multitude of hardware components it may
need more work to get a high quality system out of it which users would like
to see.

But there would be a different strategy which I have rejected for more than 10
years: just pick a Linux kernel, stick with it and just fix things. And accept
that it is ageing and becoming incompatible. I have rejected this because
if the kernel becomes really too old it takes months or years to pick another
kernel and get it to the same level because forward-porting private changes
is usually not easy.

Maybe the Linux community has recognised that as well and there are LTS
kernels. I just learned that v4.4 is even a Super-LTS i.e. will be there for
more than 10 years.

And, interesting fixes are backported. If possible even to 4.4. So that it
receives security fixes etc.

But if we would invest a lot of work on e.g. better power management for
a device. Would you work on 4.4. or linux-rc with this general process
in mind?

So I always come back to better work on linux-rc to fix and improve things,
and backport (which is usually easier than forward-porting). Although I then
have to fight against maintainers and internal API changes. But Ican also get
support. It happened several times that I just had to ask on the mailing
lists and in a half day there was a patch with a fix that I just had to test.

> 
>> This raises an interesting question: can a loosely organised open source
>> community ever fulfill these user's expectaions? Or does it need a
>> commercial effort following a plan, an agenda, doing scrum etc. having
>> enough resources and not waiting for volunteers? This does not exclude to
>> make the results open source (like Google does with Android), but it needs
>> big funds...
> 
> Although I think you and Michael have been lucky having various people show up 
> and handle certain troublesome aspects of the Pyra software and hardware, 
> getting people with the right expertise to help out with projects probably has 
> to go beyond the "volunteers welcome" mindset. We saw this with Neo900, which 
> admittedly suffered from other difficulties, where it was practically 
> impossible to get people involved with the right skills, even when payment was 
> offered.

Volunteers are welcome - as unpaid slaves :) They should not have their own
ideas...

> 
> Also, there is a phenomenon where the people who might have the ability to 
> accelerate a project tend to get given devices, sometimes on an almost 
> speculative basis. Nokia sent out devices to developers - I think the N950 
> might have been a notable case of that - and I think the MIPS Creator CI20 was 
> sent out to people who were perceived as being potentially helpful. How many 
> of these devices quickly end up in the desk drawer in the office along with 
> all the other things that those people get sent? Meanwhile, other people wait 
> for wider availability of the product to have a chance at getting involved, if 
> that ever even occurs.

Yes, it was common. But if I ask myself if I would do something if someone
would send me a device my answer would be a no. 10 to 15 years back
a device without polished software was a good compensation for investing
some small amount of time to get the software a little more polished. And a
handful of companion volunteers could bring a project to good shape.

But nowadays the task is too big for a too small group of potential volunteers
to handle the complexity of modern software stacks. BTW: the NIH syndrome
of open source communities adds to fragmentation and therefore reduces
the potential of a specific project.

And, back then it was not possible to buy the same sort of devices at quarter
of price with already polished software (aka Andoid).

It happened several times during development of the GTA04 that people
said: nice but look you can buy this or that. Instead of helping getting GTA04
better and making it a success.

> 
> The more I think back ten years or so, the more I see that opportunities were 
> lost. The Ben NanoNote was an interesting device, but the reaction from 
> certain commentators was predictably consumerist. I only regret not getting 
> interested in that sooner, just to try and sustain the momentum it had so that 
> it might have led to other things. How much messing around ends up being done 
> with single-board computers now to reproduce similar kinds of products to one 
> that people were too cheap and sniffy to pay 99 EUR for?
> 
> Similarly, with Openmoko there was a chance to iterate in the hardware design 
> and to build a long term initiative, but a combination of factors brought this 
> to an end prematurely. Despite the tendency of some people to deliberately 
> portray that effort in a negative way in order to assert that they would not 
> make the same mistakes, one significant repetition of history that such people 
> have failed to escape is precisely the mismanagement of customer expectations 
> that occurred with Openmoko. That may have been inadvertent with Openmoko, 
> however, and people today have no such excuse.
> 
> Ultimately, the conclusion must be that long term initiatives are a good 
> thing: we cannot have things starting and then ending and then other people 
> coming along and starting again from scratch.

Indeed. This needs focus on some goal or to use more marketing speech: a vision.

> This makes the failure of 
> crowdfunding campaigns particularly painful, since if they are not going to 
> deliver a product, maybe the work that went into the product might be 
> delivered so that people can genuinely believe the claims that seem to be made 
> that supporters are somehow investing in Free Software and open hardware.
> 
> And one might think that enduring Free Software organisations might seek to be 
> custodians of these long term initiatives, too. But as previously noted, their 
> cultural instincts render them passive: it is far better to badmouth Apple, 
> apparently, than to actually invest in infrastructure and solutions that might 
> keep the very basis of those organisations' existence viable for the 
> population at large. If no-one can buy hardware that can conveniently run Free 
> Software any more, it will be futile to exhort consumers to buy anything at 
> all.
> 
> Well, still nothing particularly constructive here: that will have to wait for 
> another message!

No problem. One has to discuss and identify the issues of the current situation
to start to understand the gaps and chances for doing something differently.

BR,
Nikolaus



More information about the Community mailing list