Skip to main content

The fallacy that WP7 is immune from the race to the bottom

People left and right are claiming that if Nokia had chosen Android, they would be one vendor amongst many competing on thinner and thinner margins, while WP7 somehow isolates them for that. As far as I can tell, that is now commonly accepted as truth. It is amusing how a fallacy turns into "common sense" when repeated enough times.

In reality, of course, people don't buy operating systems. They buy phones, and they would not buy a more expensive phone if a cheaper one offered the same capabilities given comparable manufacture quality and design. This is such a simple and fundamental truth that it is almost unbelievable that it is ignored.

Apple is always used as a counter-example, but in reality an unlocked iPhone costs about the same as any other high-end smartphone with comparable parameters. Granted, people will pay more for good design or even just a fancy logo, but the name of the OS running in the phone hardly even enters the equation.  In particular the notion that consumers will pay premium specifically for WP7 is frankly laughable.

Of course there are other factors: the brand name of the manufacturer, the quality of the app ecosystem and so on. Those are valid considerations, except that most of those currently point towards an advantage for Android, not the other way around.

So, specifically the fallacy is this: while it is commonly accepted that Android is "comparable", if not "better" than WP7, at the same time it is also claimed that WP7 will bring in higher premiums.

Nokia can manufacture some pretty good phone hardware, so they deserve high margins, but the sad reality is they are in the same race to the bottom as everybody else, including Apple, and one day the license cost of WP7 (compared to free Android and IOS) might end up being a huge problem.

That is my objective evaluation of the situation, but it doesn't mean I like it. We will end up getting crappier and crappier product as a result, just as today it is almost impossible to buy a high quality PC regardless of the price.

Comments

Popular posts from this blog

You Don't Like Google's Go Because You Are Small

When you look at Google's presentations about Go, they are not shy about it. Go is about very smart people at Google solving very BIG problems. They know best. If you don't like Go, then you are small and are solving small problems. If you were big (or smart), you would surely like it. For example, you might naively think that printing the greater of two numbers should be as simple as std::cout << max(b(),c()) That is because you think small. What you really should want is: t1 := b() if t2 := c(); t1 < t2 { t1 = t2 } fmt.Print( t1 ) Isn't it much better? We didn't have to type all those extra semicolons that were killing productivity before. If you don't like it, you are small. If you wanted to extract an attribute of an optional parameter, you may be used to typing something like: a = p ? p->a : 0; or even: a = p && p->a You just make me sad because obviously what you really want is: a = 0 if p != nil { a = p->

Apple2TC: an Apple II Binary to C Decompiler - Part 7, Using The IR

 This is part 7 in a series of posts describing Apple2TC.  The start is in  Part 1 . Part 6 introduced our SSA-based Intermediate Representation. In this part we look at a running IR example and how it is transformed by our decompiler pipeline. Introducing The Example To demonstrate the utility of our IR, we have devised a slightly contrived example that nevertheless illustrates challenges encountered in real code.  The source of the example can be seen here:  https://github.com/tmikov/apple2tc/blob/master/blog/part6/ex.s . We assembled it with a6502: a6502 ex.s ex.b33 and disassembled it: apple2tc ex.b33 --asm > ex.lst Producing the following listing: /*0300*/ TSX /*0301*/ INX /*0302*/ INX /*0303*/ LDY M_0101,X ; $0101 /*0306*/ INY /*0307*/ STY M_90 ; $0090 /*0309*/ LDA M_91 ; $0091 /*030B*/ STA M_92 ; $0092 /*030D*/ L

Apple2TC: an Apple II Binary to C Decompiler - Part 1

This is a series of blog posts to serve as a log documenting my work on Apple2TC - an open source hobby project developed on GitHub:  https://github.com/tmikov/apple2tc . There are various interesting things that come up all the time and I thought it might be useful to record them for posterity. Part 2  describes the different components of the project Part 3 shows how we validate our disassembly by generating a working C representation of it. Part 4 shows the Apple II tricks we had to deal with to get to correct running code. Part 5 describes decompiling and running Robotron 2084 and Snake Byte. Part 6 introduces our SSA-based intermediate representation . Part 7 shows how to transform the IR to discover the original intent of the code.   What is Apple2TC? Apple2TC is an open source project to decompile original Apple II binaries, mostly games, into understandable and working modern C code,  completely automatically  by analyzing the runtime behavior of the code via custom softw