| |||||||||||||
Welcome to embedded...Welcome to embedded...Posted Apr 2, 2009 20:41 UTC (Thu) by tbird20d (subscriber, #1901)Parent article: Android and Open Source (ABN)
Without wanting to be a troll, the blog entry merely points out factors that are standard operating procedure for the majority of product-driven embedded work. Google cannot realistically share details of their release schedule - which would divulge market-influencing product release schedules.
Also, customization is still such a large part of building an embedded product, that following, rather than leading, other open source developers working on the same project is really not an option. Time-to-market pressures are had everywhere - so I'm not using that as an excuse. But product-specific features, unlikely to be mainline-able in the short term, are required to get the product out the door.
Would the author have been happier if Google had pushed all code upstream first, before releasing their product. We'd still be waiting for the first phone if they had done that. (And in many cases, just where would "upstream" be?)
(Log in to post comments)
Welcome to embedded... Posted Apr 3, 2009 7:56 UTC (Fri) by forthy (guest, #1525) [Link] IMHO, "pushing upstream before the product is released" is the wrong answer to this question. Just develop in the open, i.e. in a public accessible VCS. You can't guess when the release of the product is going to happen, because there will be development all the time - as long as you don't announce "feature freeze" or something like that. You don't have to. When you do feature freeze, you create an internal fork, which is not visible, and you forward-port your remaining bug fixes to the external fork (which can continue to develop at the usual pace). It looks like Google just has to learn how to do that sort of development. Apple had to learn that, too. An awful lot of managers sleep better when all the stuff they do is strictly confidential, no matter if there is any real benefit. There had been rumors that the toilet paper at Intel have "strictly confidential" written all over it ;-). The main criticism I have on Android is rather different:
Welcome to embedded... Posted Apr 3, 2009 11:25 UTC (Fri) by job (guest, #670) [Link]
Ditto. Also the absence of copyleft worries me. Telcos historically take any opportunity to close down "unnecessary" access to their services. This runs the risk of every provider essentially having a private fork, with all associated problems.
Welcome to embedded... Posted Apr 6, 2009 20:19 UTC (Mon) by pphaneuf (guest, #23480) [Link] I think that's on purpose, because if they couldn't close it down, the telcos would never sell products using it, so Android might as well not exist, as far as the general public is concerned.
You can't guess when the release of the product is going to happen => case closed, nothing to do here, move along... Posted Apr 3, 2009 13:10 UTC (Fri) by khim (subscriber, #9252) [Link] You can't guess when the release of the product is going to happen, because there will be development all the time - as long as you don't announce "feature freeze" or something like that. You don't have to. When you do feature freeze, you create an internal fork, which is not visible, and you forward-port your remaining bug fixes to the external fork (which can continue to develop at the usual pace). Who will develop this "enternal fork"? It's kind of catch22 situation: such organization is useless unless there are big, vibrant community not tied to OHA-imposed deadlines and without such organization it's hard to create external developer community. Right now Google enginners are primary driving force behind Android and so there are no people who can continue to develop at the usual pace when feature-freeze is announced. You can't distribute native applications, you can only use their JVM, which limits what you can do. I hope it'll change in the future, but I can see why they choose to go this way. The JVM is interpreted rather than using a JIT. This means applications take more energy to run than necessary. Not in Android case. They use scheme where applications are started for a short period of time, do small amount of work and then killed. JIT will be detrimental for such usage and will actually suck MORE energy than interpreter. It'll be good idea to have JIT for background processes, but AFAICS it's not a high priority right now.
You can't guess when the release of the product is going to happen => case closed, nothing to do here, move along... Posted Apr 3, 2009 15:17 UTC (Fri) by forthy (guest, #1525) [Link] Not in Android case. They use scheme where applications are started for a short period of time, do small amount of work and then killed. JIT will be detrimental for such usage and will actually suck MORE energy than interpreter. Hm, I've written lightweight JITs that take similar time to compile the code as an interpreter takes to execute it. Unless you have a completely loopfree application, the JIT-ed code is faster. People use these techniques today to JIT even JavaScript. It's a matter of tradeoffs, as usual. I've doing this sort of stuff for about 20 years now. Furthermore, as one comp.arch poster tells us in his footer: A lot in computing has to do with caching. Cache the JITed code, and reuse it later. You basically have to compile once per download. Gigabytes are cheap now, even on mobile phones. About this catch22-situation: Android is a distribution of various components, like a Linux kernel, WebKit, a JavaVM, and others. Most of that happens outside Google, anyways; all Google does is to adopt to their needs. This part is what should happen in the open, because merging back big lumps of patches is a PITA. The actual Andriod "distribution" itself can happen with whatever schedule Google likes to have.
|
|||||||||||||