Domain: codon.org.uk
Stories and comments across the archive that link to codon.org.uk.
Comments · 7
-
License
https://fuchsia.googlesource.c...
the consequences that we've seen from google's failure to use a self-protecting license includes:
* companies incorporating GPL'd code into Android (particularly video players) and not releasing the source
* performing DRM or other lock-downs ("Tivoisation") and in the case of qualcomm ending up with 900 million devices that are basically landfill
* causing confusion in the minds of corporations over the fact that the linux KERNEL (and u-boot) is still GPL'ddo i need to continue the list? i don't but i believe a reference to mjg59's list is appropriate:
http://www.codon.org.uk/~mjg59...google seems unable to comprehend the severe detrimental consequences of its actions, and the effects that their decisions have on the rest of the software libre community. i appreciate that they're an advertising company so are required to maximise the effective distribution of devices so that they can thus maximise the number of devices through which they can advertise, but pissing all over the free software community that MADE IT POSSIBLE FOR THEM TO HAVE A BUSINESS AT ALL is completely unethical, not to mention the detrimental consequences and money that users have to throw away when devices turn out to have major security flaws that the designers CAN'T FIX IN THE FIELD. http://arstechnica.com/securit...
-
Working on it
Here's the thread on debian-arm: http://lists.debian.org/debian-arm/2011/12/msg00008.html and the corresponding one on arm-netbook: http://lists.phcomp.co.uk/pipermail/arm-netbook/2011-December/thread.html
The problem that's been made clear time and time again is that if you want low-cost mass-produced hardware, you normally have to go with GPL-violating products (see list here http://www.codon.org.uk/~mjg59/android_tablets/) and that means that you will spend the majority of your time reverse-engineering the product for anything between two weeks and two years, depending on luck and skill, before getting something useful. By the time you're done, the product is usually end-of-lifed: thus if it breaks, you're back to square one.
The reason for the GPL violations is that the low-cost China-based Factories simply have zero software skills: they're provided with binary-only firmware from an ODM who themselves usually had to sign an NDA from the SoC manufacturer, itself in direct violation of the GPL, in order to get access to the source code. Normally there's a chain of at least *five* companies with whom you have to negotiate with for several days or weeks - each - in order to explain the situation to them, against a precarious balance of them basically not giving a stuff because there's no financial incentive for them to give you anything at all: they're already making money, selling product, so why should they care?
thus, we logically concluded that the only way to get non-GPL-violating product out there is to go directly to the factories and be the supplier of their software.
so for the past two years i've been contacting and vetting China-based factories, directly, to find at least one which is prepared to work with us (RH Technology - http://www.rh-technology.com./ the basis of the deal is, "we won't charge you for software expertise if you won't charge us for hardware design costs", and after two years we finally found _one_ factory willing to do a deal, and are looking for more.
we've also found an absolutely great CPU, called the Allwinner A10, which in mass-volume quantities is only about $7: that means that a PCB similar to the raspberrypi with similar features can be made for about $15 (not $25) and, because the Allwinner CPU is an ARM Cortex A8 not an ARM11 it is at least three times quicker than the raspberrypi's CPU.
now we have at least 15 Debian Developers who are willing to support the project by buying beta hardware samples, and we're looking for more people to help support this effort, by committing to buy product (just like with the OpenPandora http://openpandora.org./ we have set up a CIC (http://en.wikipedia.org/wiki/Community_interest_company) because it's a better vehicle than a non-profit, charity or profit-maximising company. the CIC is called Rhombus Tech - http://rhombus-tech.net./
we also have the full support of the Board of Directors of the Allwinner CPU: they released full source code to us in advance. we've made it available and found it to compile successfully.
in-advance GPL-compliant hardware really is very very unusual. even USA-based companies typically release GPL source code on or after the day that a product is announced. Archos for example made a tablet that used the Telechips TCC8900 series of CPUs, and complied with the GPL (in direct violation of the standard NDA available at the time from the SoC manufacturer!).
other than that: about the only existing product on the market that i can really recommend to you is the alwaysinnovating touchbook: http://alwaysinnovating.com/ - it's about $300.
-
Re:EOMA Initiative
-
Re:This fails the "5 seconds of thought" test
please moderate the parent comment down as completely misleading. a quick google search "HTC GPL Violation Android" shows a consistent and willful track record of GPL violations by HTC. the GPL violations rate, even on a simple non-authoritative survey, is well-known to be 90% or above. http://www.codon.org.uk/~mjg59/android_tablets/
-
it's complicated
there is a lot of misinformation about this topic, because many people do not realise that chinese manufacturers simply have absolutely no software skills - at all - and get supplied with GPL-violating binary firmware from a very limited pool of software specialist companies in china, completely by mistake. they then turn to those software specialists when asked for GPL compliance, and you typically get a very distorted and standard answer which indicates a complete lack of knowledge of the GPL.
but on top of that, the android source code that comes out of google simply is not enough, on its own. firstly: android is NOT just apache2-licensed applications: it sits on top of a GPL'd Linux Kernel which has had some very specific modifications made to it (mostly in the form of the android "security model"). secondly: many CPU manufacturers have to add hardware-accelerated video and 3D graphics engines in order to meet "cunsumaah dimarnd". these are backed up by proprietary software libraries that qualify - usually - as "System Libraries" under GPL exemption clauses. thirdly: android simply doesn't have a built-in video player nor a video player "API" so it is up to the vendors to put in applications which *do not* come from the android "stock" that comes out of google, and they usually do this by grabbing the nearest GPL source code they can find. fourthly: many software-builders for the OEMs / ODMs simply throw away portions of android source code and utilise the GPL equivalents (such as the GPL version of busybox, not the version that google implemented from scratch just to be able to "cleanse" the core android OS From All Gee Pee Ell code).
so this is the situation. and, as a result, yes, the vast majority of android devices in the world are GPL violating. let's go through a few coments that have made it past slashdot moderation.
baloroth states that google provides the GPL parts of android and that they are "freely available". well, yeah, but re-read the above and you'll see that that's completely irrelevant. he then states that he assumes that any licensee would just point to that if asked for the code. well, yeah, but re-read the above and you'll see that that's again completely irrelevant - not least because the licensee is required to provide the code that THEY have distributed, and it's usually been heavily modified by somebody else that they got in to do the software. he then states that "most licensees don't modify the GPL portions" which is wrong: it is absolutely essential to create an android-specific linux kernel which will support the android OS, on a per-CPU and even a per-device basis.
jeffmeden then goes on to try to state that we should all think that multi-billion-dollar companies like motorola, samsung and HTC don't bother to check if things are kosher? jeff - even a few seconds of checking on the gpl-violations mailing list or even just searching "HTC GPL Violation" would show you at least three GPL violations by HTC within the past year! samsung you're actually right about, and motorola i haven't kept up with but they are just in the process of being acquired by google, which is something that needs to be kept an eye on. it could be good, or it could be bad.
jeff also states "hmm no actually most manufacturers comply with the redistribution clause in the GPL". this is completely wrong. actually, according to an off-the-cuff survey of android tablets done six months ago by a redhat employee, he found that 95% of the 80+ tablets were GPL violating. he's maintaining the list here:
http://www.codon.org.uk/~mjg59/android_tablets/this list is so long it would overwhelm the Software Freedom Law Centre's resources to tackle them all at once.
so... yeah. it would appear that there is a hell of a lot of ignorance surrounding android. the mistake that google made was to try to combine apache-licensed code with GPL code. apart from anything, this gives people the impression that all
-
Probably leaving hardware on
It's incredibly hard to say because the summary doesn't provide enough detail in and of itself to diagnose the problem (e.g. which graphics card, which chipset, which drivers are being used, which version of Ubuntu and so on). The most likely explanation is that hardware is being left on in Linux that other OSes are powering down when on battery. Examples of this:
- Wired ethernet ports that are often put into some off state under Windows such that they will no longer work until the laptop is plugged into the mains but saving power while not in use while on the battery.
- Similarly if the poster is using a particular graphics drivers (free or closed - depends on the hardware) they may not be powering the hardware down as aggressively as the drivers on another operating system. I've seen Intel graphics cards on Windows that reduce display quality presumably to increase compression (you can visibly see the artifacts) when on battery to decrease power draw.
- Hard disks might not be spun down as often (or at all) under Linux.
- USB sockets may not be auto suspending depending on the version of the distro/hardware.
- The tickless kernel may not be working effectively (or at all depending on kernel version) - there might be a program that is preventing the kernel from idling for a long period of time because it is doing some unnecessary program (this may tie back into graphics drivers again).
- The SATA controller might not be powering down as it does on other OSes.
- The screen might not be as dim as it is on other OSes.
- The sound hardware might not be powering itself off properly/completely.
- The wifi might be be being put into a low power mode/being turned off on other OSes.
- There could be bugs in a driver under Linux.
- Other OSes might have a program monitoring temperature sensors and scaling hardware functions appropriately (e.g. slowing down fans if the machine is cool).
- And so on...
As you can a myriad of reasons and not nearly enough information to whittle down the cause. Further how do you know each OS is using the same defaults? It could be that Windows says you are running out of battery later than Linux does (I'd imagine that this sort of thing could only account for 10 minutes difference to actual empty battery though) or the display is defaulting to a different brightness - it could be that lots of little things are adding up to the major difference.
A few years ago I had access to a Thinkpad T60 and it would draw two watts less power under Windows XP than under Ubuntu Gutsy. That doesn't mean things don't change over time but nor does it mean that people aren't seeing real problems now. If you know how to constructively help, things can get progressively better on your system but it can take some time and you need to know how to track these things down. Tools like powertop help and developers have been putting together good power management practices for Linux guides. However in all honesty posting to Slashdot is unlikely to help you obtain a solution (and indeed there is no guarantee of a solution even over a long period of time).
-
Re:My own perspective
You're certainly not alone in this line of reasoning..
http://www.codon.org.uk/~mjg59/bruce/