On Mon, Dec 19, 2011 at 8:46 PM, Richard Stallman <[email protected]> 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.
