"Nope. With the exception of the libraries, it's pretty much all Java, and actually, it would be insane for them to allow you to code natively. You loose all of the advantages of hardware independence which is exactly why this sort of platform exists in the first place." Hasn't hurt Symbian or Windows Mobile, probably because everything in the mid-to-high-end range is ARM.
"PalmOS primarily ran on low power devices, and you pretty much needed to "hit the metal" if you wanted to get any sort of performance from your apps. It's something I used to do a great deal in the past, but not for many years.
However, we're talking about much more powerful devices here. Even the most basic smart phone packs quite a bit of processing power these days, and much of the core functionality is provided at a hardware level, so the level of abstraction provided by a driver model is absolutely essential. If you go low level, then your application isn't able to take advantage of the additional power offered by some devices but not others. You end up coding to the lowest common feature-set." No we aren't. These devices won't be any more powerful than the current batch of Windows Mobile and PalmOS phones in terms of hardware.
"Making use of the APIs which provide interoperability and a standardised framework is the only way to ensure that your software will run on all Android devices, something which from a business point of view is essential." WM and Symbian do fine here with native code.
"Most mobile application developers are already doing their work in Java, except for the unlucky ones that are stuck with the mess that is Brew."
Windows Mobile? Symbian? In the market Google is targeting (higher-end smartphones - note that their reference platform and a number of initial handsets are made by HTC, they do *NOT* do low-end cripplephones.), no one develops in Java. If they try to target the Windows Mobile/Symbian market segment without making native code easy, they're toast.
"1) Most mobile developers already use Java, as it is the most prevalent mobile language (Java ME). I have dozens of games and apps on my cell phone, and they are all written in Java." Depends on what the mobile target is. No one targeting high-end smartphones uses Java. I have dozens of apps on my phone, and ONE (Gmail Mobile) is written in Java, and will be replaced with a native app (WebIS FlexMail) quite soon. Two of the ones I use the most (TomTom Navigator 6 and TCPMP) could not possibly ever be written in Java and retain acceptable performance.
"Using Java doesn't cause lock you into a single language. The JVM could be targeted by any number of languages all you need is a compiler that will output the correct bytecode." Could be, but please name a robust well-supported compiler/library environment that works well.
"Going with a JVM is the only logical way to go with this kind of system. You don't want the end user to have to compile the application for their phone and yow don't want to have recompile a for each new cell phone that hits the market." For smartphones, the CPU choices are typically Qualcomm MSM, TI OMAP, or Marvell PXA.
Oh wait, they're all ARM devices! Windows Mobile does just fine using native code. I was hoping that this would have the native code performance advantages of Windows Mobile, but with an improved UI, open architecture, and speed improvements.
Instead, it will either be limited to low-end cripplephones, will turn good hardware into a low-end cripplephone, and no matter what has zero chance of outperforming Windows Mobile in terms of UI responsiveness and such. (Which is sad because that should be easy to do, it's just not possible with the bloated horse-designed-by-committed nightmare known as Java.)
Phones are low-power, low-speed, low-memory devices, even high end smartphones. To make full use of such devices, developers need access down to the hardware level. If you're stuck in a JVM sandbox, many of the tweaks and hacks and nifty tricks available to developers of native code (see, for example, CellID-based profile switchers for Windows Mobile) won't be accessible.
The documentation isn't quite clear, but it looks like I was wrong and unfortunately Android apps are indeed intended to be written in Java. (as opposed to, say, something like a C/C++ toolkit with bindings for other languages, such as TrollTech's mobile Qt variant.)
I just lost a lot of interest in Android, if it pigeonholes developers into a single language and makes compiling native code with an efficient language difficult. Java utterly failed in the "Write once, run everywhere" arena, and it's an ugly horse-designed-by-committe language that universally leads to bloat. (See, for example, the memory usage and UI responsiveness of uTorrent when compared with Azureus.) There's a big focus on mobile devices towards multimedia applications (video, audio), and smooth video playback on a phone takes even natively compiled code to its limits.
I'm assuming (need to confirm) that Android is primarily developed using native ARM code, it just happens to include a Java VM for all those legacy MIDlets running around out there.
It would be suicide (see Palm as an example) for Google to make developing using native code difficult. (For those not in the know, even though PalmOS has run on ARM CPUs for years, normal apps are still emulated m68k code, with the option of "ARMlets" to allow snippets of native code on PalmOS 5. Writing an ARMlet is an UNHOLY NIGHTMARE. I attempted to speed up a program by replacing some code with native ARM code and gave up.)
"a custom Java Bytecode interpreter that is highly specialized for the CPU" - Kind of hard to do that in an emulator on a PC. What CPU is this optimized for? (Guessing ARM... Still, to evaluate performance you need real hardware.)
RTFWP - Those "web apps" are merely webpages customized for the iPhone, NOT third-party applications.
They are not installed on the device, and cease functioning if the phone is in an area without any network coverage. Compare to, for example, a REAL third-party application such as TomTom for Windows Mobile, which retains 95%+ of its functionality when no network connection is present. (The only thing that really depends on a network connection is TomTom Traffic.)
That's one of the reasons I'm an AT&T customer now. The Treo 650 was delayed for months due to "network certification", when in reality VZW was crippling many of the 650's capabilities such as Bluetooth DUN.
When I heard VZW was doing the same with the XV6800 (delayed 9 months or so for "network certification", Sprint has had it for months.), it was time to leave.
I love my AT&T Tilt. It's far more open than any phone I've used before.
To the other guy that replied to me - I'm fairly certain that even jailbreaking voids the iPhone warranty.
I have an AT&T Tilt, and I agree with you, except:
While Android won't give you cool new features you can't already get in Windows Mobile, you will get those features with far more polish in the Google version.
See, for example, Gmail vs. pre-Gmail-Hotmail. No real new major "features", just an unbelievable amount of user interface polish.
That is what Google has done (and succeeded wildly with) in a number of areas.
Search? - Already done, Google did it better. (Although they were closer to the frontier on this one) Web-based email? - Done for years (including entries by Microsoft), then Google took the concept and tweaked it and refined it, now it's the leader in the market. Web-based mapping? - Mapquest used to dominate, there were a few other entries into the market, now Google Maps dominates.
Admittedly in both the web-based email and web-based mapping markets, MS has shaped up their act a LOT, partly because Google has forced them to do so. As far as mobile local search, I actually prefer Windows Live Search Mobile to Google Maps Mobile on my AT&T Tilt. WLS Mobile *rocks*.
I suspect the same will happen with Android. They'll take the already reasonably well established concept of the smartphone (Symbian, Palm, Windows Mobile), and do what they've done in every market - simply *do it better*.
"It wants to do this because it is obvious to the folks at Google that people need to do Web searches from their phone, so they can, uh, get directions to the restaurant? Of course, they can simply use the phone itself to call the restaurant and ask! I've actually used various phones with Web capability." 1) How can you call the restaurant if you don't know their number? (hint: get the number from the Web, or a specialized local search such as Google Maps Mobile or Windows Live Search Mobile.) 2) What if you miss a turn? TomTom and Garmin mapping devices are selling like hotcakes for a reason... It's a lot easier to hit a few buttons on your GPS (or click "directions" in GMM or WLSM) than it is to write down and follow the restaurant's directions. 3) How do you determine the restaurant's existence in the first place? You've just flown into town on a business trip, you feel like pizza. Where's the nearest pizza place??? GMM or WLSM will tell you that, and I bet whatever localized search capability Google puts into Android will do it even better. 4) Dvorak needs to define "phones with Web capability" more precisely. Was he using a $20 Motorola C168i (it has a web browser, albeit an utterly awful and nearly useless one), a Windows Mobile device (Pocket IE is OK, Opera is much better), or an iPhone? Expect the Android experience to fall closer to the iPhone end of the spectrum.
"That was the problem with the Danger and its successor, the Hiptop handset. They were clunky." Clunky or not, they're apparently selling well and a big attraction to T-Mobile. They definately haven't flopped, T-Mo just released not one but *two* new Sidekick variants.
"People have had eons to program for the Windows smartphones and nothing has come of it." There seem to be plenty of applications for WM that I can download and/or buy. Yeah a lot of them are crap, but many are gems. See my above comments about GMM and WLSM - both kick ass. Now if only I could have WLSM's search capability combined with TomTom's user interface (TT's POI database and POI search capability sucks, but most other aspects of TT are amazing.)
The sound quality of my AT&T Tilt (same manufacturer as the Shadow - HTC) is just fine. I'd say it was great, in fact.
What is the signal strength when you get this "awful sound quality" - T-Mobile has the smallest network (read: least coverage) of the four U.S. carriers. That's why they're so dirt cheap - you get what you pay for.
This article is just a pile of FUD. I laugh at the morons who buy antivirus software for Windows Mobile phones, when there is little to no risk of contracting a virus unless you are utterly and completely idiotic.
Bad for MS. While LG isn't a very large Windows Mobile manufacturer and their membership in OHA doesn't imply a direct risk of loss for Microsoft, LG is a *very* large handset manufacturer, and their membership in OHA implies that while Microsoft may not lose them, Microsoft is at high risk of simply not gaining them in the first place in any of their ventures into high-end smartphones.
That reminds me, I'm still pissed at Microsoft for mangling the term "smartphone" to mean a crippled non-touchscreen device (when it used to mean a PDA phone.)
"All that said - Windows Mobile 6 is actually not THAT BAD." - I agree, I'm using an AT&T Tilt (HTC Kaiser) and LOVE it.
Admittedly, part of that is due to the HTC customizations you mention. HTC Home rocks, and HTC Task Manager/HTC X Button (I think they're one and the same now?) basically flies in the face of Microsoft design guidelines. There's a Windows Mobile Team blog entry somewhere saying that Microsoft has always thought that users should never be concerned with memory management, and for a while would withold official certification from any app that had a quit button or function that would actually cause the app to fully close. (Have you noticed that NONE of Microsoft's applications have functionality to close themselves?). That's a good ideal to aspire to (a smart device that manages memory well enough that the user doesn't), but so far basically no one has actually succeeded in achieving such an ideal. The inclusion of HTC Task Manager in any HTC ROM might be one of those reasons for that lack of a "Certified for Windows Mobile" mark you mention.
I disagree that the only way to survive WM6 is to get a nice cooked ROM, but that's because the first thing I did was replace my Tilt ROM with the HTC TyTn II ROM. While not cooked, most people consider the HTC shipped ROMs to be much cleaner than any carrier-branded ROM.
That's one of the reasons I say that Steve is running scared (to the guy who said "get over yourself" - if Steve weren't running scared, why would he have to issue a press release to FUD Android?). There are pretty clear signs that one of Microsoft's most prolific handset manufacturers hates them and is ready to jump ship to a more viable alternative. (I would not say that HTC is prominent as that involves brand recognition, but HTC is pretty happy to let carriers rebrand their phones as carrier-branded units. In fact, ALL recent AT&T-branded handsets are manufactured by HTC. That said, HTC is prolific in that they've got a pretty significant share of the Windows Mobile market, just not under *their* brand.)
Say what you want about Windows Mobile, but there are some GREAT hardware platforms running it.
"many hardware devices" means "lots of hardware for our handset manufacturers to port Android to" - Note that two of the largest manufacturers of Windows Mobile based hardware (Motorola and HTC) are part of the OHA, and in fact HTC appears to be the company that will be doing the initial "reference hardware platform"
For example, AT&T Wireless' Windows Mobile lineup consists of handsets from: Motorola (part of OHA), HTC (part of OHA), Samsung (Role unknown - but they haven't spoken out against OHA and I wouldn't be surprised if they'll join in.), Pantech (new player in town, just released their first WM handset this month, bet you a small player like that is interested in Android.), and Palm (the only member of this list to speak out against Android, and generally considered to be a has-been in the market nowadays.)
T-Mobile's Windows Mobile lineup: HTC - Nothing else. None of Moto or Samsung's WM entries.
Verizon's WM lineup: HTC (less prominent than in AT&T's lineup, just because they are taking an eternity to release the XV6800 which Sprint has had for nearly nine months), Motorola, Samsung, Palm - basically same as AT&T, although with older phones from all manufacturers involved. PN-820's origin is unknown to me, may or may not be an HTC device. Carrier branded WM devices usually are HTC though...
Sprint: HTC, Moto, Samsung, Palm. HTC and Moto figure much more prominently in the lineup than AT&T and VZW it seems.
Microsoft has a pretty good presence in the mobile market, but it is most definately not "Microsoft's World".
Steve is running scared. I'd say that over 75% of the Windows Mobile market consists of handsets manufactured by HTC and Motorola, with a good chunk of the rest being Samsung. Guess what - those two companies are part of Google's OHA. (I can't remember, is Samsung involved? Microsoft is really screwed if they are.)
Steve should shut up and stop attacking Android and figure out how to compete before Microsoft loses one of their largest handset manufacturers.
Same thing that happened to people who bought into Microsoft's "Plays for Sure" system and then bought a Zune?
Ooops... I found it hilarious that the first company to break compatibility with a system called "Plays for Sure" was the company that created the system... (Note that I said break it, companies which never implemented it in the first place don't count.)
I think part of the problem (as listed in the summary) is that while a ship in international waters usually has a clearly defined nationality, the ISS has a bunch of parts originating from different countries, so the question is what is the nationality of the "ship". It sounds like the issue is not difficult when dealing with spacecraft of a single nationality (for example, the Space Shuttle.)
This is somewhat off topic but makes me think of one of the quirks of Canada.
While a lot of countries have strict laws limiting possession of guns, I recall reading that Canada *requires* light plane pilots flying over certain areas (or possibly anywhere in their airspace) to have a shotgun on board in case they crash in the wilderness. Not sure if this is actually true, but it makes sense that Soyuz would have firearms on board for the same reasons.
See the article you link to, which states that perfect collimation can never be achieved in reality. Thus, like any other source, laser light follows the inverse square law in the far field.
Note that in general, I believe the inverse square law only applies to a point source, or a source which is effectively a point source at the distances involved. For dealing with cases where the source can't be approximated as a point (either because it's really large, or the radiation intensity is being measured very close to the source), RF engineers use the term "near field gain reduction" for the behavior of RF field intensities in close proximity to an antenna, which probably has an equivalent term for optics. As a result, for an optical source with a large aperture in relatively close physical proximity to the aperture, the inverse square law will appear not to apply, but once the "near field" for that source is exited, the inverse square law holds.
Double distance, you double spot diameter, which results in quadruple the spot area (pi*r^2) (hence dividing intensity by the square of the distance ratio, so inverse square law is holding).
Looks to me like he got it right and you got it wrong.
I was just about to post along these lines, but you beat me to it.
Anyone can write apps for Windows Mobile. In fact, with the exception of OpenMoko, until Android was announced it was actually the most open of the phone platforms. Motorola's Linux implementations are horribly locked down (I wonder if they will figure out a way to do the same for Android?), and I've heard Symbian is really anal about application signing. Windows Mobile will warn you the first time you try to run an unsigned app, but will remember your response for that application afterwards (until the app's checksum changes, then it will prompt again.)
This makes me wonder, will Google take any sort of a stand against Tivoization? Most Windows Mobile devices default to being locked down such that they will only allow signed OS images to be loaded and booted (until the device is cracked, fortunately it seems to be pretty easy to crack the bootloaders, HTC devices seem to never last more than a week or so after release before HardSPL is ported to the new unit.), will things be the same for Android? Open source is pretty pointless if the hardware will only flash/load/boot a signed OS image.
Slashdot Mirror
"Nope. With the exception of the libraries, it's pretty much all Java, and actually, it would be insane for them to allow you to code natively. You loose all of the advantages of hardware independence which is exactly why this sort of platform exists in the first place."
Hasn't hurt Symbian or Windows Mobile, probably because everything in the mid-to-high-end range is ARM.
"PalmOS primarily ran on low power devices, and you pretty much needed to "hit the metal" if you wanted to get any sort of performance from your apps. It's something I used to do a great deal in the past, but not for many years.
However, we're talking about much more powerful devices here. Even the most basic smart phone packs quite a bit of processing power these days, and much of the core functionality is provided at a hardware level, so the level of abstraction provided by a driver model is absolutely essential. If you go low level, then your application isn't able to take advantage of the additional power offered by some devices but not others. You end up coding to the lowest common feature-set."
No we aren't. These devices won't be any more powerful than the current batch of Windows Mobile and PalmOS phones in terms of hardware.
"Making use of the APIs which provide interoperability and a standardised framework is the only way to ensure that your software will run on all Android devices, something which from a business point of view is essential."
WM and Symbian do fine here with native code.
"Most mobile application developers are already doing their work in Java, except for the unlucky ones that are stuck with the mess that is Brew."
Windows Mobile? Symbian? In the market Google is targeting (higher-end smartphones - note that their reference platform and a number of initial handsets are made by HTC, they do *NOT* do low-end cripplephones.), no one develops in Java. If they try to target the Windows Mobile/Symbian market segment without making native code easy, they're toast.
"1) Most mobile developers already use Java, as it is the most prevalent mobile language (Java ME). I have dozens of games and apps on my cell phone, and they are all written in Java."
Depends on what the mobile target is. No one targeting high-end smartphones uses Java. I have dozens of apps on my phone, and ONE (Gmail Mobile) is written in Java, and will be replaced with a native app (WebIS FlexMail) quite soon. Two of the ones I use the most (TomTom Navigator 6 and TCPMP) could not possibly ever be written in Java and retain acceptable performance.
"Using Java doesn't cause lock you into a single language. The JVM could be targeted by any number of languages all you need is a compiler that will output the correct bytecode."
Could be, but please name a robust well-supported compiler/library environment that works well.
"Going with a JVM is the only logical way to go with this kind of system. You don't want the end user to have to compile the application for their phone and yow don't want to have recompile a for each new cell phone that hits the market."
For smartphones, the CPU choices are typically Qualcomm MSM, TI OMAP, or Marvell PXA.
Oh wait, they're all ARM devices! Windows Mobile does just fine using native code. I was hoping that this would have the native code performance advantages of Windows Mobile, but with an improved UI, open architecture, and speed improvements.
Instead, it will either be limited to low-end cripplephones, will turn good hardware into a low-end cripplephone, and no matter what has zero chance of outperforming Windows Mobile in terms of UI responsiveness and such. (Which is sad because that should be easy to do, it's just not possible with the bloated horse-designed-by-committed nightmare known as Java.)
Phones are low-power, low-speed, low-memory devices, even high end smartphones. To make full use of such devices, developers need access down to the hardware level. If you're stuck in a JVM sandbox, many of the tweaks and hacks and nifty tricks available to developers of native code (see, for example, CellID-based profile switchers for Windows Mobile) won't be accessible.
The documentation isn't quite clear, but it looks like I was wrong and unfortunately Android apps are indeed intended to be written in Java. (as opposed to, say, something like a C/C++ toolkit with bindings for other languages, such as TrollTech's mobile Qt variant.)
I just lost a lot of interest in Android, if it pigeonholes developers into a single language and makes compiling native code with an efficient language difficult. Java utterly failed in the "Write once, run everywhere" arena, and it's an ugly horse-designed-by-committe language that universally leads to bloat. (See, for example, the memory usage and UI responsiveness of uTorrent when compared with Azureus.) There's a big focus on mobile devices towards multimedia applications (video, audio), and smooth video playback on a phone takes even natively compiled code to its limits.
I'm assuming (need to confirm) that Android is primarily developed using native ARM code, it just happens to include a Java VM for all those legacy MIDlets running around out there.
It would be suicide (see Palm as an example) for Google to make developing using native code difficult. (For those not in the know, even though PalmOS has run on ARM CPUs for years, normal apps are still emulated m68k code, with the option of "ARMlets" to allow snippets of native code on PalmOS 5. Writing an ARMlet is an UNHOLY NIGHTMARE. I attempted to speed up a program by replacing some code with native ARM code and gave up.)
What I would love to see is for HTC to port Android to some of their older devices in order to get a developer's platform out there quickly.
Android for Kaiser = drool. Even Android for Hermes would rock.
What hardware platform does it run on?
"a custom Java Bytecode interpreter that is highly specialized for the CPU" - Kind of hard to do that in an emulator on a PC. What CPU is this optimized for? (Guessing ARM... Still, to evaluate performance you need real hardware.)
RTFWP - Those "web apps" are merely webpages customized for the iPhone, NOT third-party applications.
They are not installed on the device, and cease functioning if the phone is in an area without any network coverage. Compare to, for example, a REAL third-party application such as TomTom for Windows Mobile, which retains 95%+ of its functionality when no network connection is present. (The only thing that really depends on a network connection is TomTom Traffic.)
That's one of the reasons I'm an AT&T customer now. The Treo 650 was delayed for months due to "network certification", when in reality VZW was crippling many of the 650's capabilities such as Bluetooth DUN.
When I heard VZW was doing the same with the XV6800 (delayed 9 months or so for "network certification", Sprint has had it for months.), it was time to leave.
I love my AT&T Tilt. It's far more open than any phone I've used before.
To the other guy that replied to me - I'm fairly certain that even jailbreaking voids the iPhone warranty.
I have an AT&T Tilt, and I agree with you, except:
While Android won't give you cool new features you can't already get in Windows Mobile, you will get those features with far more polish in the Google version.
See, for example, Gmail vs. pre-Gmail-Hotmail. No real new major "features", just an unbelievable amount of user interface polish.
It doesn't count if the only way to install third party apps is by voiding the phone's warranty.
Probably 80-90% of iPhone users have not jailbroken their phones and don't even realize they have the option.
That is what Google has done (and succeeded wildly with) in a number of areas.
Search? - Already done, Google did it better. (Although they were closer to the frontier on this one)
Web-based email? - Done for years (including entries by Microsoft), then Google took the concept and tweaked it and refined it, now it's the leader in the market.
Web-based mapping? - Mapquest used to dominate, there were a few other entries into the market, now Google Maps dominates.
Admittedly in both the web-based email and web-based mapping markets, MS has shaped up their act a LOT, partly because Google has forced them to do so. As far as mobile local search, I actually prefer Windows Live Search Mobile to Google Maps Mobile on my AT&T Tilt. WLS Mobile *rocks*.
I suspect the same will happen with Android. They'll take the already reasonably well established concept of the smartphone (Symbian, Palm, Windows Mobile), and do what they've done in every market - simply *do it better*.
"It wants to do this because it is obvious to the folks at Google that people need to do Web searches from their phone, so they can, uh, get directions to the restaurant? Of course, they can simply use the phone itself to call the restaurant and ask! I've actually used various phones with Web capability."
1) How can you call the restaurant if you don't know their number? (hint: get the number from the Web, or a specialized local search such as Google Maps Mobile or Windows Live Search Mobile.)
2) What if you miss a turn? TomTom and Garmin mapping devices are selling like hotcakes for a reason... It's a lot easier to hit a few buttons on your GPS (or click "directions" in GMM or WLSM) than it is to write down and follow the restaurant's directions.
3) How do you determine the restaurant's existence in the first place? You've just flown into town on a business trip, you feel like pizza. Where's the nearest pizza place??? GMM or WLSM will tell you that, and I bet whatever localized search capability Google puts into Android will do it even better.
4) Dvorak needs to define "phones with Web capability" more precisely. Was he using a $20 Motorola C168i (it has a web browser, albeit an utterly awful and nearly useless one), a Windows Mobile device (Pocket IE is OK, Opera is much better), or an iPhone? Expect the Android experience to fall closer to the iPhone end of the spectrum.
"That was the problem with the Danger and its successor, the Hiptop handset. They were clunky."
Clunky or not, they're apparently selling well and a big attraction to T-Mobile. They definately haven't flopped, T-Mo just released not one but *two* new Sidekick variants.
"People have had eons to program for the Windows smartphones and nothing has come of it."
There seem to be plenty of applications for WM that I can download and/or buy. Yeah a lot of them are crap, but many are gems. See my above comments about GMM and WLSM - both kick ass. Now if only I could have WLSM's search capability combined with TomTom's user interface (TT's POI database and POI search capability sucks, but most other aspects of TT are amazing.)
The sound quality of my AT&T Tilt (same manufacturer as the Shadow - HTC) is just fine. I'd say it was great, in fact.
What is the signal strength when you get this "awful sound quality" - T-Mobile has the smallest network (read: least coverage) of the four U.S. carriers. That's why they're so dirt cheap - you get what you pay for.
This article is just a pile of FUD. I laugh at the morons who buy antivirus software for Windows Mobile phones, when there is little to no risk of contracting a virus unless you are utterly and completely idiotic.
Bad for MS. While LG isn't a very large Windows Mobile manufacturer and their membership in OHA doesn't imply a direct risk of loss for Microsoft, LG is a *very* large handset manufacturer, and their membership in OHA implies that while Microsoft may not lose them, Microsoft is at high risk of simply not gaining them in the first place in any of their ventures into high-end smartphones.
That reminds me, I'm still pissed at Microsoft for mangling the term "smartphone" to mean a crippled non-touchscreen device (when it used to mean a PDA phone.)
"All that said - Windows Mobile 6 is actually not THAT BAD." - I agree, I'm using an AT&T Tilt (HTC Kaiser) and LOVE it.
Admittedly, part of that is due to the HTC customizations you mention. HTC Home rocks, and HTC Task Manager/HTC X Button (I think they're one and the same now?) basically flies in the face of Microsoft design guidelines. There's a Windows Mobile Team blog entry somewhere saying that Microsoft has always thought that users should never be concerned with memory management, and for a while would withold official certification from any app that had a quit button or function that would actually cause the app to fully close. (Have you noticed that NONE of Microsoft's applications have functionality to close themselves?). That's a good ideal to aspire to (a smart device that manages memory well enough that the user doesn't), but so far basically no one has actually succeeded in achieving such an ideal. The inclusion of HTC Task Manager in any HTC ROM might be one of those reasons for that lack of a "Certified for Windows Mobile" mark you mention.
I disagree that the only way to survive WM6 is to get a nice cooked ROM, but that's because the first thing I did was replace my Tilt ROM with the HTC TyTn II ROM. While not cooked, most people consider the HTC shipped ROMs to be much cleaner than any carrier-branded ROM.
That's one of the reasons I say that Steve is running scared (to the guy who said "get over yourself" - if Steve weren't running scared, why would he have to issue a press release to FUD Android?). There are pretty clear signs that one of Microsoft's most prolific handset manufacturers hates them and is ready to jump ship to a more viable alternative. (I would not say that HTC is prominent as that involves brand recognition, but HTC is pretty happy to let carriers rebrand their phones as carrier-branded units. In fact, ALL recent AT&T-branded handsets are manufactured by HTC. That said, HTC is prolific in that they've got a pretty significant share of the Windows Mobile market, just not under *their* brand.)
Say what you want about Windows Mobile, but there are some GREAT hardware platforms running it.
"many hardware devices" means "lots of hardware for our handset manufacturers to port Android to" - Note that two of the largest manufacturers of Windows Mobile based hardware (Motorola and HTC) are part of the OHA, and in fact HTC appears to be the company that will be doing the initial "reference hardware platform"
For example, AT&T Wireless' Windows Mobile lineup consists of handsets from:
Motorola (part of OHA), HTC (part of OHA), Samsung (Role unknown - but they haven't spoken out against OHA and I wouldn't be surprised if they'll join in.), Pantech (new player in town, just released their first WM handset this month, bet you a small player like that is interested in Android.), and Palm (the only member of this list to speak out against Android, and generally considered to be a has-been in the market nowadays.)
T-Mobile's Windows Mobile lineup:
HTC - Nothing else. None of Moto or Samsung's WM entries.
Verizon's WM lineup:
HTC (less prominent than in AT&T's lineup, just because they are taking an eternity to release the XV6800 which Sprint has had for nearly nine months), Motorola, Samsung, Palm - basically same as AT&T, although with older phones from all manufacturers involved. PN-820's origin is unknown to me, may or may not be an HTC device. Carrier branded WM devices usually are HTC though...
Sprint:
HTC, Moto, Samsung, Palm. HTC and Moto figure much more prominently in the lineup than AT&T and VZW it seems.
Microsoft has a pretty good presence in the mobile market, but it is most definately not "Microsoft's World".
Steve is running scared. I'd say that over 75% of the Windows Mobile market consists of handsets manufactured by HTC and Motorola, with a good chunk of the rest being Samsung. Guess what - those two companies are part of Google's OHA. (I can't remember, is Samsung involved? Microsoft is really screwed if they are.)
Steve should shut up and stop attacking Android and figure out how to compete before Microsoft loses one of their largest handset manufacturers.
Same thing that happened to people who bought into Microsoft's "Plays for Sure" system and then bought a Zune?
Ooops... I found it hilarious that the first company to break compatibility with a system called "Plays for Sure" was the company that created the system... (Note that I said break it, companies which never implemented it in the first place don't count.)
I think part of the problem (as listed in the summary) is that while a ship in international waters usually has a clearly defined nationality, the ISS has a bunch of parts originating from different countries, so the question is what is the nationality of the "ship". It sounds like the issue is not difficult when dealing with spacecraft of a single nationality (for example, the Space Shuttle.)
This is somewhat off topic but makes me think of one of the quirks of Canada.
While a lot of countries have strict laws limiting possession of guns, I recall reading that Canada *requires* light plane pilots flying over certain areas (or possibly anywhere in their airspace) to have a shotgun on board in case they crash in the wilderness. Not sure if this is actually true, but it makes sense that Soyuz would have firearms on board for the same reasons.
Wrong, they do follow the inverse square law.
See the article you link to, which states that perfect collimation can never be achieved in reality. Thus, like any other source, laser light follows the inverse square law in the far field.
Note that in general, I believe the inverse square law only applies to a point source, or a source which is effectively a point source at the distances involved. For dealing with cases where the source can't be approximated as a point (either because it's really large, or the radiation intensity is being measured very close to the source), RF engineers use the term "near field gain reduction" for the behavior of RF field intensities in close proximity to an antenna, which probably has an equivalent term for optics. As a result, for an optical source with a large aperture in relatively close physical proximity to the aperture, the inverse square law will appear not to apply, but once the "near field" for that source is exited, the inverse square law holds.
Double distance, you double spot diameter, which results in quadruple the spot area (pi*r^2) (hence dividing intensity by the square of the distance ratio, so inverse square law is holding).
Looks to me like he got it right and you got it wrong.
Two words:
Gameboy Color. Nintendo has done this sort of thing before, with quite a bit of success.
I was just about to post along these lines, but you beat me to it.
Anyone can write apps for Windows Mobile. In fact, with the exception of OpenMoko, until Android was announced it was actually the most open of the phone platforms. Motorola's Linux implementations are horribly locked down (I wonder if they will figure out a way to do the same for Android?), and I've heard Symbian is really anal about application signing. Windows Mobile will warn you the first time you try to run an unsigned app, but will remember your response for that application afterwards (until the app's checksum changes, then it will prompt again.)
This makes me wonder, will Google take any sort of a stand against Tivoization? Most Windows Mobile devices default to being locked down such that they will only allow signed OS images to be loaded and booted (until the device is cracked, fortunately it seems to be pretty easy to crack the bootloaders, HTC devices seem to never last more than a week or so after release before HardSPL is ported to the new unit.), will things be the same for Android? Open source is pretty pointless if the hardware will only flash/load/boot a signed OS image.