Originally Posted by 99semaj
but I think the MS model has had an enormous productivity penalty to humankind. In the post-PC era, we simply can't afford to be that lazy with footprint, processor cycles or battery energy.
I don't see any of these things being worse or better than what PCs do (specifically for footprint, processor cycles, battery energy). In fact, I see both mobile and PC platforms employing the same strategy.
For footprint, you just want to have all the devices on hand by the installer
. You don't actually write files to the device you don't need, or for hardware that isn't relevant.
For processor cycles, I don't see how that would be affected by what I'm suggesting. The OS code and application code is made for the general case anyway, they go through a OS "stack" and a driver "stack" that abstracts the hardware, which is exactly how desktops do it. There is a cycle cost, true. But apparently all the major players have decided that the cycle cost is worth it. Even on iOS. You don't draw directly to the screen. Classes like CGRect is well abstracted from the hardware - you're using Quartz 2D, and it's very much abstracted from your iPhone GPU hardware. If you were to try and optimize your code to the same level that some game devs do for consoles to do stuff like write directly to memory instead of using the graphics API, I doubt Apple would even approve your app for the App Store.
There were a couple special cases on iOS where devs made a lot of hardware assumptions. Stuff like iPhone screen size. And those are the apps that didn't use the full screen when the iPhone 5 came out. Now both Apple and Google encourage devs to spend the extra CPU cycles on dynamic layout code so that apps "just work" on new displays. Just like how the PC apps work.
For battery energy, well, it's the same discussion as processor cycles. The battery energy is burned because the mobile platforms use the same abstractions that the PC world uses. In fact, it's often the exact same abstractions between iOS and Mac OS X.
So, the suggestion of writing a OS that can dynamically detect attached devices and to get the proper drivers for them has no real down sides that I can see. The PC world has proven that it works. Sure, people may complain about the odd driver bug - but the mobile phone world has the same sort of issues. Witness the Nexus 4 and Nexus 7 (2013 model) which have WiFi driver issues, even though they're sold as a pre-configured product.
I think the main reason why the mobile OS makers haven't actually implemented it is because not many people could use it, primarily because such a small percentage of users would actually do it, and partly because the whole software update situation is very
screwed up on the mobile side.
For Android devices, carriers and handset makers molest the software and add their junk prior to the device getting into the consumers hands. This is just like what happens on the PC side with bloat-ware being added. It can ruin your experience, and Apple is the only company that I can think of that has never done this on their products. I think the complaints people have about PCs is largely a function of bloatware.