Welte: Android Mythbusters (Matt Porter) [LWN.net]

Harald Welte has issued a scathing opinion of Android on his blog. He bases it on Matt Porter's presentation at the Embedded Linux Conference Europe, called "Android Mythbusters" [PDF]. Porter outlined what he learned while porting Android to PowerPC and MIPS architectures. Welte characterizes Android as Google having "thrown 5-10 years of Linux userspace evolution into the trashcan and re-implemented it partially for no reason. [...] Executive summary: Android is a screwed, hard-coded, non-portable abomination."

to post comments

Missing the point much?

Posted Nov 4, 2009 17:57 UTC (Wed) by rfunk (subscriber, #4054) [Link] (10 responses)

Er, wasn't all that stuff junked in order to fit in the small memory of phones?
And it was considered safe to junk *because* Dalvik is supposed to be the target for applications.

Missing the point much?

Posted Nov 4, 2009 18:15 UTC (Wed) by foom (subscriber, #14868) [Link] (6 responses)

> Er, wasn't all that stuff junked in order to fit in the small memory of phones?

Maybe that was the reason, but the Palm Pre shows it wasn't actually necessary to do so.

Missing the point much?

Posted Nov 4, 2009 18:22 UTC (Wed) by dw (subscriber, #12017) [Link] (2 responses)

The Pre ships with 32 times more flash (8gb vs 256mb) than the G1 did (excluding the bundled SD card, which can't be used for binaries anyway).

Missing the point much?

Posted Nov 4, 2009 18:57 UTC (Wed) by foom (subscriber, #14868) [Link] (1 responses)

Comparing the amount of flash on the devices is pretty meaningless. On the Pre, it's used for
storing user data. I don't know how big the Pre OS is, but I'm damn sure it's nowhere
*near* 8GB.

pre root

Posted Nov 4, 2009 20:09 UTC (Wed) by joey (guest, #328) [Link]

/dev/mapper/store-root
                      442M  380M   62M  87% /media/pre-root

I have a fair number of third party webos apps installed in the above though.

Lawyers sometimes do Missing the point much?

Posted Nov 4, 2009 19:02 UTC (Wed) by smoogen (subscriber, #97) [Link] (1 responses)

The Palm Pre is a different creation beast than the Google Android. Palm gets to have a degree more control over how much memory, CPU, etc is going to be put in the phone. Google is creating a general purpose system that various vendors will 'buy into' and thus has to take their shopping list of requirements (we need it to work on XMb of ram, oh we aren't going to use this CPU, etc).

More importantly the Palm lawyers can say "we are going to be ok with GPL requirements if all this stuff goes to GPL3 or 4 or something" and it covers there production run. Google has to have all the lawyers of the consortium of manufacturers agree to that... and my guess is that is pretty much impossible (even if Google's lawyers was all for it .. which I am doubtful about.)

So throwing out a ton of stuff and using GPL2only and Apache licensed stuff makes the consortium lawyers happy and they get to reinvent years of lessons the hard way.

Lawyers sometimes do Missing the point much?

Posted Nov 5, 2009 0:28 UTC (Thu) by drag (guest, #31333) [Link]

I think that Google is aiming Android at the low-end phone of the future.

Currently the only phones capable of running a full OS are in the 400-600 dollar range, which is only what the high-end of the market can sustain.

After a quick google'ng Symbians range around 200-800 dollars, WinMo 6.x ranges 300-700 dollars, and iPhones are 500-700 dollars. All retail/unlocked price. Getting locked-down versions tend to knock off 40- 60% of the price.

Android, on the other hand, is aiming for pure ubiquitousness. It seems to be aiming to create a commodity OS for phones that are free with contract or range in price less then 100 dollars. Of course higher end phones will just run more applications faster and be more useful for gaming. I think Android phones should get down to that price within the next two years.

This positions Android to replace the wide range of 'feature phones' software that tend to have one large application that has a number of features that makes it emulates some of the more popular things people do on real smart phones, but don't really have the resources to run a full OS. Traditional Linux desktop-based systems, by their nature, are still going to be to much for those level of systems. (I am looking forward to the day when I can just install Debian on a smart phone and use Gnome-shell desktop usably on it.)

If you look at the hardware used for Android it tends to be lower-end when compared with other smartphones. They tended to use older freescale based platforms, while iPhone and others tend to use the newer TI OMAP3 platform or the competing Qualcomm Snapdragons should be coming out soon. I think. The "Droid" Verizon phone is the first Android to use the newer platforms, which come closer to the level of hardware that you get with a new iPhone or the N900.

Missing the point much?

Posted Nov 6, 2009 16:56 UTC (Fri) by trasz (guest, #45786) [Link]

Given that one of the biggest problems with Pre is its slowness...

Missing the point much?

Posted Nov 4, 2009 18:24 UTC (Wed) by daney (guest, #24551) [Link] (2 responses)

> Er, wasn't all that stuff junked in order to fit in the small memory
> of phones?

Who knows. I thought it was to avoid the GPL.

Missing the point much?

Posted Nov 4, 2009 21:07 UTC (Wed) by lutchann (subscriber, #8872) [Link] (1 responses)

That was my impression--handset makers are scared to death of GPL, especially v3 but v2 as well. Even LGPL makes them uncomfortable, which is why Android is even using their own libc replacement. I don't know why this is a surprise to anyone; we've known Android jettisoned most of GNU/Linux userspace for two years now:

http://arstechnica.com/old/content/2007/11/why-google-cho...

With regard to the poor architectural decisions that were made when designing the Android stack, Harald should be quite aware that typical embedded systems software is much uglier. The fact that the vendor (Google) even makes their code repositories publicly available puts them light-years ahead of 99% of the rest of the embedded industry.

Missing the point much?

Posted Nov 5, 2009 7:30 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

Nokia must be terrified.

Welte: Android Mythbusters (Matt Porter)

Posted Nov 4, 2009 18:27 UTC (Wed) by ssam (guest, #46587) [Link] (3 responses)

back to openmoko then

Welte: Android Mythbusters (Matt Porter)

Posted Nov 4, 2009 19:43 UTC (Wed) by divide_by_zero (guest, #60957) [Link] (2 responses)

If you had hopes with Android, you might like to try Maemo also...

Welte: Android Mythbusters (Matt Porter)

Posted Nov 4, 2009 20:18 UTC (Wed) by macson_g (guest, #12717) [Link] (1 responses)

Actually you might have a point here. Nokia is embracing The Openness (TM) in incredible speed. They seemed to cure themselves from heavy NIH, they are using large amounts of pre-existing Free software in newest Maemo versions, they are opening they development process. They event re-implementing connectivity stack as Free software (oFono)

Who would think few years ago that we will see Nokia and Google competing on Linux-based OSes, Nokia being the one more open?

Welte: Android Mythbusters (Matt Porter)

Posted Nov 5, 2009 13:05 UTC (Thu) by laf0rge (subscriber, #6469) [Link]

I agree. Maemo is much more in line with what typical linux desktop systems use (X11, GTK, in the future Qt, glibc, gstreamer, dbus, ...). This makes Maemo a dozen times more attractive for somebody who's actively looking for a Linux product than Android.

However, it's also far from being perfect. There are still a fair number of proprietary components left that need to be either opened up or proper replacements developed by the community.

In any case, I'm looking forward to the N900.

Android Mythbusters Video?

Posted Nov 4, 2009 18:33 UTC (Wed) by kragil (guest, #34373) [Link] (2 responses)

I read somewhere there is/will be a video of that talk ... but I couldn't find it :(

Android Mythbusters Video?

Posted Nov 4, 2009 19:12 UTC (Wed) by abacus (guest, #49001) [Link]

A few links:

Harald Welte's blog.
The presentation by Matt Porter: Mythbusters: Android.

Android Mythbusters Video?

Posted Nov 6, 2009 13:10 UTC (Fri) by mkaehlcke (guest, #61834) [Link]

Free Electrons videotaped the sessions, check their website from time to time, the videos will be available soon

Welte: Android Mythbusters (Matt Porter)

Posted Nov 4, 2009 18:55 UTC (Wed) by jgg (subscriber, #55211) [Link] (2 responses)

I looked at some android stuff too for a bit, I was interested if their prelink could be used for PPC without a huge problem. Didn't seem like it. Not only was it quite ARM specific but it was tied into how their libc worked.. Ended up using normal prelink and some haxoring for cross compiling..

I've done a lot of embedded stuff too and I don't use udev or HAL or really much of the Linux user space beyond a few core libraries glibc, openssl, etc. So it is hard to fault Android for that.

But chucking glibc and replacing it with something so vastly inferior is not going to work for a lot of people. For instance last I looked there is no IPv6 support at all in their libc.

Basically, it seems a great way to run some kinds of Java apps on a ARM, and some phone specific brickabrack surrounding that but it isn't going to take the embedded Linux world by storm any time soon.

Welte: Android Mythbusters (Matt Porter)

Posted Nov 5, 2009 18:19 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

Er, *every* prelink implementation is tied to a libc (or at least to the
dynamic linker). It has to be, because ld.so has to know 'this has been
prelinked, the prelinking isn't out of date, do not relocate this'. A
prelinker that didn't affect the behaviour of the dynamic linker would be
useless.

Welte: Android Mythbusters (Matt Porter)

Posted Nov 5, 2009 23:43 UTC (Thu) by jgg (subscriber, #55211) [Link]

Sort of - the bulk of prelinking work is entirely fixed - you apply the relocations in advance the way the ELF standard says. Knowing that the relocations are OK is what .gnu.liblist does and I can't see how that isn't entirely sufficient for pretty much any prelinking implementation.

The main thing that could vary is the symbol resolution order, there are pretty good ELF standard conventions for this but glibc has some unique behavior in some corner cases. Overall not a big issue.

The android prelinker is one of a kind, cross-compile prelinking is something almost every embedded dev would be interested in, IMHO.

Welte: Android Mythbusters (Matt Porter)

Posted Nov 4, 2009 20:25 UTC (Wed) by ncm (guest, #165) [Link] (16 responses)

The Linux user space is no great shakes. Glibc is enormously overcomplicated, and often substituted in embedded ports. Posix Threads are several crossbred abominations, and we'd be better off with simple futures (as indeed we will have, along with the posixy threads, in C++0xA). SysV IPC, I can happily live without, likewise SysV startup scripts. It would be no great error to toss X and start over knowing more than we did then.

The great failure of Android is that it is programmed in Java, a language that never had any objectively defensible reason to exist. Sure, you could say the same about BASIC, or indeed most languages, but none of those justify actually using it.

Compiled Java

Posted Nov 5, 2009 0:12 UTC (Thu) by man_ls (guest, #15091) [Link] (6 responses)

I'm no expert but I respectfully disagree; Java is a great language -- it's raison d'être was to have "C++ without the warts", and I think it was accomplished beautifully. For example, pointer arithmetics is automatic, garbage collection is automatic too, and buffer overflows are unheard of. (Actually the official motto was "write once, run everywhere", but this other goal failed miserably.)

The JVM is a different beast; it is bloated and weird. But Google is not using it; actually they have created a better JVM (register-oriented and less memory-hungry) and target that from their Java code. They could have gone the extra mile and compiled Java, as GCC can do, but interpreted runtimes are still fashionable, apparently.

And then there are the runtime libraries, which are sometimes very well done and suck big time others, and are bloated all the time. But most of them can luckily be ignored. Anybody knows if they are using these?

Compiled Java

Posted Nov 5, 2009 12:47 UTC (Thu) by jengelh (subscriber, #33263) [Link] (5 responses)

>it's raison d'être was to have "C++ without the warts",

One's warts are another's trademark. In C and C++ you can take the address (or reference, whatever) of an object and pass it around. In Java instead you have to create an extra Integer() class for the same job. So you have done away with the pointer wart in exchange for an overhead wart.

Compiled Java

Posted Nov 5, 2009 13:44 UTC (Thu) by skitching (guest, #36856) [Link] (1 responses)

Compilers for statically-typed languages can play many tricks; code performance can be very tricky to estimate.

For example, in Java the Integer class is final, ie cannot be subclassed.

Therefore, all method calls made via a reference of type Integer can be inlined.

In addition, if the compiler can determine that the integer's lifetime does not extend beyond the function in which it is created (ie in which "new" is called), then the data can be allocated on the stack.

And if the compiler can determine that an Integer is never cast to a parent type (Number or Object), then no Object instance needs to be created, ie just 4 bytes for the data are needed, like in c.

So it can be possible for a good java compiler to create identical code for java or c++ in many cases.

As always,
* actual profiling is best, and
* the tradeoff between safety, performance and developer time must be kept in mind.

There are many things about the Java syntax that annoy me, but the fact that java code can never overwrite memory it does not own is a very powerful thing.

Compiled Java

Posted Nov 6, 2009 22:48 UTC (Fri) by bcopeland (subscriber, #51750) [Link]

So it can be possible for a good java compiler to create identical code for java or c++ in many cases.

Unfortunately even Sun can't make a good java compiler :)

Compiled Java

Posted Nov 5, 2009 18:21 UTC (Thu) by khc (guest, #45209) [Link]

usually you want to pass primitive types by reference because your function needs to modify it. In Java, Integer is immutable so you can't use Integer to substitute for int in that case anyway.

Compiled Java

Posted Nov 5, 2009 20:59 UTC (Thu) by man_ls (guest, #15091) [Link]

As another commenter already said, creating an Integer() would not work. The reason you cannot pass a reference to an int so that it is modified by the function is that you are not expected to do that. And the solution is not to create a class with just an integer attribute and pass that -- the real solution is to not pass integers, but objects with behaviors. Integers are best kept as attributes of objects and handled within those objects. If you really have to change just an int it's best to have the method return a new int. Keeps your code simpler and reduces side effects -- and performance is just as good.

This kind of policy may force you to make things a different way, but it is a perfectly valid way -- it's idiomatic Java if you wish. Now, there are some idiotic policies in Java (like getters and setters, what a waste of time) but keeping methods from modifying their (primitive) parameters seems like a good design choice to me.

Compiled Java

Posted Nov 6, 2009 1:13 UTC (Fri) by alankila (guest, #47141) [Link]

In fairness, in many cases an inner class, anonymous or not, can be used. The inner class has access to the containing class's scope, and can thus be passed to wherever you want and the methods in that interface will then be able to modify the members of the containing class. This is pretty nice technique as it gets you something that feels like closures.

In a rare occasion someone might use a kludge like pass a new int[1] { value } so that the array's first element can be adjusted by the called code. Tricks like 1-element arrays are also sometimes used in Python, to circumvent Python's way of determining the scope of a variable from a first assignment in a block.

Welte: Android Mythbusters (Matt Porter)

Posted Nov 5, 2009 0:23 UTC (Thu) by dvdeug (subscriber, #10998) [Link]

You can't objectively defend creating BASIC as an alternative to JOSS, LISP, FORTRAN II (not IV, not 77, II) or Algol 60?

Welte: Android Mythbusters (Matt Porter)

Posted Nov 5, 2009 12:42 UTC (Thu) by pboddie (guest, #50784) [Link] (7 responses)

I didn't think that glibc was the only choice for Embedded Linux - indeed, I thought that there was a range of fairly mature options at that level. All this reinvention on Google's part suggests that they either want to own as much of the technology stack as possible, that they indulge various internal developers too much, or that they're needlessly scared of the licensing of code where even the FSF will tell you that there are few if any licensing obligations when linking to such libraries:

http://www.gnu.org/licenses/gpl-faq.html#PortProgramToGL

Welte: Android Mythbusters (Matt Porter)

Posted Nov 5, 2009 23:52 UTC (Thu) by jgg (subscriber, #55211) [Link] (2 responses)

IMHO, android's libc is probably the best next option to glibc. The other choices leave alot to be desired, and are fairly disused these days.

Indulging internal developers is quite an interesting point.. Who ever created some of this stuff is really good. There are not many people in the world who could sit down and write a new ELF dynamic loader, libc and related toolchain goop - let alone start out that way and not be afraid of failing. This is arcane stuff.

I'd be quite interested to know how long it took to make, IMHO, a super expert, done this before, kind of thing, could probably knock it out in a month. You'd probably burn more time than that just fussing with glibc to make it smaller.

Welte: Android Mythbusters (Matt Porter)

Posted Nov 6, 2009 13:35 UTC (Fri) by nix (subscriber, #2304) [Link]

uClibc is 'fairly disused'? Not in my embedded world :)

(oh, and most of this stuff is dull and fiddly but not *hard*. At least
making it work is not hard. Making it fast and robust, that's hard.)

Welte: Android Mythbusters (Matt Porter)

Posted Nov 6, 2009 13:40 UTC (Fri) by pboddie (guest, #50784) [Link]

Can you comment on dietlibc, newlib and uClibc? I wasn't aware that these were particularly deficient, although I'm sure that there are good reasons for not choosing them in certain situations.

Welte: Android Mythbusters (Matt Porter)

Posted Nov 6, 2009 17:04 UTC (Fri) by trasz (guest, #45786) [Link] (3 responses)

For some reason you assume that FSF lawyers know GPL better than Google lawyers. This is obviously wrong (Google simply can pay their lawyers better and get better ones), so your conclusion about Google's assumptions about effects and consequences of GPL is wrong.

Welte: Android Mythbusters (Matt Porter)

Posted Nov 6, 2009 17:28 UTC (Fri) by pboddie (guest, #50784) [Link] (2 responses)

I might have known you'd have something to "add" to this discussion, but my point was that if some project has released code under the GPL (or even the LGPL), then there are several limitations in place, widely accepted even by Google (who have released proprietary software for GNU/Linux), that prevent any effect on the licensing of programs which interact with such code. Even the FSF acknowledge these limitations, which is what the link I provided refers to.

Given that your analysis of my conclusion is based on peripheral matters and not on any reasonable attempt to understand either the licence texts or the clarifications written by the people who wrote the licence texts (and that, in any case, the lawyers of various other corporations are presumably better paid than those working for the FSF, yet those lawyers have had to comply with the GPL when challenged), I'd be more careful liberally pointing the finger and using the word "wrong" if I were you.

Welte: Android Mythbusters (Matt Porter)

Posted Nov 6, 2009 22:10 UTC (Fri) by trasz (guest, #45786) [Link] (1 responses)

I was replying to the claim that Google is _needlessly_ scared about the GPL license. There is no reason to assume their knowledge of the GPL license is in any way worse than the FSFs.

Welte: Android Mythbusters (Matt Porter)

Posted Nov 9, 2009 12:51 UTC (Mon) by pboddie (guest, #50784) [Link]

Well, they can be "needlessly scared" on behalf of their telecoms partners, who tend to be needlessly scared about a bunch of stuff, albeit stuff which is often of their own making.

Google's "LGPL violation fly-by" involving ffmpeg and the redistribution of works under exclusive patent agreements might sit well within Google (and show that their lawyers think they know where the loopholes might be, albeit ones that have been closed in later versions of the licences concerned), but their partners might back off at the prospect of doing similar things with products that have their name on it.

(offtopic) wow... 24 slides, 1 graphic (not even "picture") 12.7 MB PDF

Posted Nov 6, 2009 14:35 UTC (Fri) by sitaram (guest, #5959) [Link] (3 responses)

I am speechless.

(offtopic) wow... 24 slides, 1 graphic (not even "picture") 12.7 MB PDF

Posted Nov 6, 2009 16:02 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

It is quite stunningly inefficient, isn't it? 24 giant bitmaps where one
bitmap and a bunch of text would have sufficed.

I'd like to know what tool was used to create that, so I can avoid it at
all costs.

(offtopic) wow... 24 slides, 1 graphic (not even "picture") 12.7 MB PDF

Posted Nov 8, 2009 13:31 UTC (Sun) by juliank (guest, #45896) [Link] (1 responses)

pdfinfo says:
Creator: Microsoft PowerPoint
Producer: Mac OS X 10.5.8 Quartz PDFContext

(offtopic) wow... 24 slides, 1 graphic (not even "picture") 12.7 MB PDF

Posted Nov 8, 2009 15:04 UTC (Sun) by nix (subscriber, #2304) [Link]

Oh, that's great, I already *do* avoid it at all costs. :)

Welte: Android Mythbusters (Matt Porter)

Posted Nov 8, 2009 15:42 UTC (Sun) by tanner (guest, #715) [Link]

Welte writes:
"I can't wait until somebody rips it apart and replaces the system layer with a standard GNU/Linux
distribution with Dalvik and some Android API simulation layer on top. To me, that seems the only
way to thoroughly fix the problem..."

There's is a project http://mjfrey.blogspot.com/ to port Dalvik to Ubuntu
but it seems to be dead...