Comment Apple's Pricing Blunder (Score 1) 804
All this means that Apple has committed a pricing blunder by under estimating competitor's pricing. They are unlikely to repeat this next time. Don't expect any pricing reductions any time soon.
All this means that Apple has committed a pricing blunder by under estimating competitor's pricing. They are unlikely to repeat this next time. Don't expect any pricing reductions any time soon.
Expose and block cheating by randomly delaying the announcements by milliseconds. Good news is they'll find the perps by threatening RICO.
Bad at explaining the issue? Are you sure you really know the issue yourself? Your explanation shows you do not.
He believed there was no issue in assigning an int to an unsigned in C. Not a quibble, right?
When I was interviewed for an elite job at an elite company, I was dumbfounded to discover that their "elite" engineers didn't understand fundamental flaws in their solutions. When their top programmer tried to optimize my solution, I told him he just added a syntax error, not an optimization. The conversation got out of hand and was finally settled by referencing the ISO standard. Apparently, this guy had been giving a thumbs up to people who couldn't spot syntax error. My advice, take time to know the algorithm and the language really, really well.
... but you get USB 2.0.
In Mauritainia, where I did Peace Corps duty 10 years ago, people self identified themselves as slaves even though slavery was abolished twenty years before. Why? Because it was their culture and job. Being a slave gave them steady meals. The alternative was worse.
Looking forward to seeing the gun camera videos filmed during the Mirage's strike on the convoy.
How come you never hear about successful traders getting arrested?
This software unblocks my use of Kinect. Microsoft has not released a gesture library. Looks like this will enable it's creation.
Here's my educated guess as to what's happening. I have absolutely no inside information. I've just taken publicly available tidbits and assembled them into a big picture. It may or may not be accurate. In short, Wpf and Silverlight will be present and supported for years. However, they are zombies having been smitten by changes in technologies.
There are two new relevant core technological changes that I'm expecting to hear at Build 2011 (née PDC 2011). First, Microsoft will promote a new UI called MoSH (MOdern SHell but more conceptually MObile SHell) based on IE's Trident render engine that will form the basis for a new initiative. Moving forward, it behooves everyone to build MoSH applications, definitely not Silverlight (web) and possibly not WPF (desktop). MoSH is implemented using HTML5 and thus constrained by HTML5 capabilities. WPF and Silverlight are still completely supported but they're future is cut off at the legs by their successor (MoSH). MoSH can be used with XAML but, significantly, will only support a subset of WPF's and Silverlight's XAML. Again, the constraining factor is HTML5 capabilities and Microsoft's abstractions of them. Thus the key question for Silverlight shops is “How much of Silverlight ISN'T abstracted from HTML5?” I expect both MoSH and WPF/Silverlight to support new device interfaces such as location, multi-touch, gyroscopes, Kinect, etc. I'm not sure if the support will come in the form of
The second technological change is what Microsoft might be calling Native Code. Native Code is a set of technologies that enable software (applications and gadgets) and hardware (graphics) to perform at near native speed inside a container (browser). Most notably, Microsoft will supply tooling to build browser applications, principally with MoSH, without today's performance penalties. Currently browser based applications are limited by API availability (DOM), programming speed (Javascript), and often software rendering. This will all change. Internet Explorer 11(?) will expose a much richer API, possibly
Some issues I'm unclear on:
* Will Microsoft port MoSH and Native Code to iOS and Android? I'm guessing that they intend to do so directly or through partnerships.
* Will a single dll, possibly named
* Will Native Code force any syntax changes to
* Is Native Code implemented using
* Do CPU processors need changes to optimally support Native Code? Remember, Windows 8 will run on ARM. ARM are the non-Intel processors that power most tablets. Do all existing processors and graphics chips support Native Code and MoSH? I'm particularly curious about the compatibility of legacy ARM processors.
What does Microsoft hope to gain by these changes?
* Build an eco system based on HTML5 standards. The idea being that no competitor can block Microsoft’s tools because they’re abstracted solely from an industry standard. The danger being that HTML5 might only be perceived as a Microsoft thing.
* Expose APIs to features of rich devices (touch, location, Kinect, voice commands)
* Implement a single Windows UI across devices to ease programming
* Create a single development platform for desktop, cloud and mobile devices
* Embrace new mobile processor architectures (ARM)
* Capture developers attention with powerful tools
* Expand security options by expanding sandboxing to new scenarios
* Offer sandboxing security to native code apps
* Expand base for MS applications (Office) to more devices
* Make Visual Studio the leading development tool for all HTML5 platforms
What Dangers does Microsoft face?
* missed schedules
* litigation, always
* threaten existing relationships (Intel)
* technical blocks (as has happened with Silverlight)
* internal intransigence
* developer pushback
* standards failure (HTML5 delays, limitations, lack of industry support (Apple?))
* lack of uptake because of disinterest in MoSH UI or development
* inability to gain critical mass due to lateness to market
What does Microsoft need to change to implement MoSH and Native Code?
* Develop MoSH; build controls from HTML5 primitives.
* Champion HTML5 standards that underly MoSH and Native Code
* Visual Studio – implement MoSH UI development
* Visual Studio – provide framework for WPF/Silverlight to MoSH conversion
* Visual Studio – implement Native Code throughout tool chain (major task)
* Visual Studio – enable MoSH and Native Code debugging (major task)
* Visual Studio – create templates for MoSH and Native Code projects
* Make MoSH app building dead simple
* Make a compelling case as to why WPF and Silverlight are dead-ends
* Net languages – transparent changes to backend
* Azure – more device support
* App Store – retool for cross-device, possibly iOS and Android support via plugins
* Internet Explorer – native MoSH support (no plugin required), virtual app support, new design patterns
* Toot the horn “IE is the most HTML5 complaint browser”. Creating demand for HTML5 compatibility is key to their strategy. If the industry moves elsewhere, well, not good.
Why isn't Microsoft telling us more?
* They don't mind telling YOU. They just want to withhold information from enemies (competitors, lawyers, unfriendly governments). They just don't want a competitor to do a crazy Ivan at a vulnerable moment.
* They want to ratchet up the excitement and explode it on stage.
* They don't want to talk about what might not be delivered.
How will Google react?
* Google is very slowly implementing their own Native Code technology called Native Client (NaCl). It supports C. Google recently announced that they will retool Chrome to go Native Client. This will enable plugins (Adobe reader, codecs) to run at full machine speed. When Google comprehended Native Client concept, it took maybe two blinks to see how Microsoft could run with it. We will all greatly benefit from Native but Microsoft will be a bigger winner than Google. Google's Native Client just doesn't have the market weight or resources to trump Microsoft's Native Code vision. A MoSH plugin for Chrome may be part of Microsoft’s grand strategy. Will Google create a Native Client implementation for IE? Doubtful.
* Mono – Moonlight (Silverlight) obsoleted. Mono will have become browser hostable.
* Mozilla – I’m predicting Microsoft or Mozilla will support MoSH via a plugin. It's in Microsoft's best interests. FireFox is a defacto standard and can’t be ignored. Aside: I don't think Mozilla will implement MoSH using their XUL API. I don't think FireFox has a strong enough presence to do it's own MoSH using XUL.
* Apple – Not threatened. MoSH for Safari probably won’t be welcome but won’t be blocked either. Not only is HTML5 not in their best interests but it also constrains flexibility.
* Chrome – Focused on developing their own Native tools. Development progress is dangerously slow. I predict Microsoft will leap past Google’s Native efforts.
What is the Timeline for the software release? Here's my crazy guesses:
* August 2010 - Proof of concept of marrying MoSH, IE and Native Code, first benchmarks
* June 2011 – Windows 8 early experience including MoSH but not Native Code anything
* September 2011 – Betas of Windows 8, Visual Studio 2012, Native Code,
* December 2011 – First release candidate
* March 2012 – Windows 8 release
* May 2012 – Office 2012 released with MoSH and Native Code support
* September 2012 – Build 2012 theme is Kinect Everywhere
Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?