ghm-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Ghm-discuss] GNU Phones and Tablets (was: [gnu-prog-discuss] Planning t


From: lkcl luke
Subject: [Ghm-discuss] GNU Phones and Tablets (was: [gnu-prog-discuss] Planning the next GNU Hackers Meeting)
Date: Thu, 22 Dec 2011 22:06:54 +0000

On Mon, Dec 19, 2011 at 8:46 PM, Richard Stallman <address@hidden> wrote:
> Most users are moving from PCs to phones and tablets.  GNU needs to
> make this move, too, somehow.  The issue is to find a feasible path.

 yes.  *deep breath*.  i've done reverse-engineering of wince mobiles.
 in an attempt to at least get *one* device working, i had to buy NINE
(yes, NINE) mobile phones.  so i know exactly how f****g hard it is to
get a gnu/linux distro onto a phone.

 one device - the HTC Universal - took four of us three years of
part-time work to finally understand all of the hardware.  the best i
ever managed on one device was 8 weeks (!) - the Compaq ipaq hw6915 -
and i had to stop because the last 3 of those 8 weeks were spent _not_
managing to get the device to come out of suspend.


> It is a hard problem because of several difficulties.
>
> * The new hardware is a lot more secret than PC hardware.

 phone (and tablet) hardware is not only a lot more secret it is
_vastly_ more complex.

take the HTC Universal as an example.  it used the Intel PXA273
processor, which has an on-board LCD.  so, i said to people on various
lists, "i have a device with a PXA 273, it is using an ATI accelerated
2D graphics IC, has anyone heard of this graphics IC?" and i got
replies back saying "hang on, what are you talking about - the PXA273
has its own LCD driver, surely you must be lying that the device has a
GPU?" and i had to send them photos of the PCB.  i won't go into too
much detail but basically all 110 GPIO pins, plus 64 more on a 2nd
peripheral IC, *and* an additional 16 pins on the GSM Radio ROM were
required, in order for this smartphone to be fully-functional.  yes,
really: to switch on the backlight you had to power up the GSM module
and send a special AT command over its RS-232 port.   the audio chip
had EIGHT outputs and FIVE inputs: stereo speakers for playing music,
flippable mic and speaker (because the clamshell screen could turn
over so there were 2 mics and 2 ear speakers), stereo headset,
carphone mode (yet another speaker and mic) _and_ bluetooth mode _and_
you could do "record" of the conversations.  actually that's probably
about 10 outputs and 5 inputs... dang.

 much of the hardware complexity was because a phone call could be
received, the hardware set up to take the call, and then the main CPU
could go into "sleep" mode in order to save power.

 did i say i would not go into too much detail?  i promise you that,
even with that paragraph above it is a _short_ description.


> * Much of the hardware is tivoized.

 yes.  they claim it's to protect users.

  ok, after about 8 years of dealing with this stuff and getting
nowhere, i've made a decision.  i've been working on this from a
different angle.  the logic goes as follows:

 * the hardware is complex
 * the average person does not care about software freedom
 * the chain of chasing GPL source code is way WAY too long
 * by the time you have source code, it's too late: the device is out
the door.  it's obsolete already, anyway.

 therefore, the logic goes, if you want people to receive devices that
are based around the principles of software freedom, then not only do
they have to be GPL compliant *in advance* of sale, but also they
actually have to be *desirable* as well as cost-competitive products.

 unfortunately... i'm sorry to have to point this out, richard, but
those goals are mutually exclusionary.  "the masses" want to be able
to play MPEG video.  they want adobe flash 10.1 (less and less, thank
god).  manufacturers compete for customers money based on cost and
features, not on principles.

 it so happens that, ironically, the licensing costs of the
proprietary alternatives are actually causing the proprietary
alternatives to self-destruct.  the margins are so small on
mass-volume hardware that even for example having to pay a small
license fee for MPEG is too much.  (why do you think google is doing
VP8, and why do you think the MPEG group is trying to get large
corporations to create patents on the VP8 algorithm? :)

 so what i am doing is working on an initiative that will allow,
thanks to a modular architecture, *replacement* of parts of a
mass-produced device with alternatives that would make the resultant
product FSF-Hardware-Endorseable.

 the idea also is to have Software (Libre) developers involved in the
process of the development of the software, such that the
end-products, when mass-produced, are GPL compliant *before* they hit
the shelves.

 i've done an analysis of various CPUs that have been found, here:
http://rhombus-tech.net/evaluated_cpus/

 you can see from the list: not *one* single one of the CPUs which
could potentially be FSF Hardware-Endorseable is acceptable as a
mass-volume "end-user" CPU because they simply cannot do what the
average end-user expects of a modern smartphone or tablet.

 so, that problem is solved by splitting out the CPU card into a module:
 http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA

thus, it becomes possible for people to purchase an FSF-Endorseable
EOMA-PCMCIA-compliant CPU card, and to purchase a tablet, laptop,
smartphone etc. etc. rip out its non-free CPU card and put in the
FSF-Endorseable one instead.  end result: the whole device now becomes
FSF Hardware-Endorseable.



> * We need work on software for phone calls.

 that's actually quite simple to do.  it's slightly more complex when
you want to send SMS messages as well.  it's _made_ complex by people
arseing about with things like message-passing, creating APIs, using
d-bus and crap like that.  but if you _just_ want "phone calls and
maybe SMS messages" you're looking at about 1 week's work in a
programming language like python and maybe 3 or so in c.

 ok, i'm understating things :)  on a per-device basis there is often
non-compliance to the AT command-set.  however, libraries such as
libgnokii have "collected" much of this expert knowledge on a
per-modem basis, for well over a decade.


> * The GUIs may need to be very different.

 yes they do.  take xgnokii which would otherwise be perfect for
running on a smartphone: it does everything you need to make phone
calls, do SMS, address book and more... but its "skin" which is an X11
bitmap image only fits on an 800x800 screen - useless on a screen of
size 8in or less.

 the enlightenment window manager team got funded by samsung to adopt
and adapt EWM so as to be more suitable for small-screen devices.
they also dropped webkit, the web browser engine, into EWM, as part of
the sponsorship.

 picking the right software framework is... how can i say... vital to
ensure that the available resources can actually result in a
successful completion of the goal.

 of course, if the intent is to do it entirely from scratch in order
to have it as a GNU project, that's entirely different :)  then it
would be essential to choose a smalllll set of acceptable
functionality, with room for expansion.


 anyway, that's all quite long.  let me summarise as follows:

 * end-users do not care about software freedom, they care about their
wallet and what they can get for their cash
 * the sheer number of devices coming out is increasing beyond belief.
 thousands.  literally.
 * reverse-engineering even of a single device just takes too long,
and it's too late anyway.
 * it makes sense therefore to conclude "if you can't beat 'em, join
'em" and to produce devices that people will _want_ to buy
 * it makes sense to sneak in "software freedom" under their noses,
even if that's done step by step.

but - i have to warn you - apologies to richard, but this is just
facts: the economics of hardware design are against us, here.  the
margins are too small (like... under 2% even on sales of 100 million
units) such that doing things like putting in an extra IC or a ROM in
order to store non-free firmware for FSF Hardware-compliance purposes
_will_ jeapordise the financial viability of the end product in the
marketplace.

 even in the EOMA-PCMCIA initiative, i'm taking a risk by including a
PCMCIA connector and header, but the cost of those components is
partly offset by the reduced cost of the (much larger) motherboard,
which would previously have had to have been a 6-8 layer board
(because of the complex paths between CPU and RAM), but could now be a
2-layer or 4-layer board.

 so - to _really_ summarise: it depends on what you want to achieve.

 * if you want to have - for yourself - an entirely "free" device,
that's fine: it's perfectly possible - you just go ahead and spend
between 8 weeks and 3 years of your life doing that.  i bought 9
devices, and ended up with 1 that worked.

 * if you want other software (Libre) developers to have entirely
"free" devices, then be prepared to again get some reverse-engineering
in, or, alternatively, start a kickstarter project and get a device
manufactured.  it'll be expensive, no matter which way you play it.

 * if you want the *average person* to have entirely "free" devices,
then economics are entirely against you for "full" freedom compliance,
hence the EOMA initiative which will allow people to convert their
devices to "free" *without* having to throw away the entire device,
just replace the CPU card *not* the entire product.

 the alternative approach to getting software (libre) into peoples'
hands is to accept - unwillingly and also having an "upgrade" plan in
place - that for economic reasons full "free" compliance simply isn't
possible *right now*, thus to grudgingly accept non-free firmware in
the *specific* instances where an exhaustive alternative
financially-viable product *literally* cannot be found, and to
constantly monitor that situation.

i would only recommend this approach for mass-volume products.  in the
"small-to-mid volume" price range for parts, the percentage cost
difference between a free and a non-free compliant part simply is not
worth it: a whole $5 extra per unit on an order of 1,000 units, to
respect software freedom, who _cares_!   whereas in mass-volume, even
$0.20 extra for a single chip times 100 million could mean the
difference between the company going out of business and it making a
profit.

ok enough.

l.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]