You have been blessed then. I have seen modal dialogs on every platform, despite how horribly evil it is.

In that scenario, I would actually imagine history repeating itself. Microsoft OSes once were considered suitable *only* for trivial, non-critical home purposes and *real* work were done exclusively on Unix workstations and servers. Because of their overwhelming presence in the homes of workers, it managed to get into businesses even before they were *really* ready. No reason to think that the same hypothetical that destroys Windows on the desktop won't pull the same manuever as MS in the workspace, in before actually being ready, but *mostly* growing into it.

I personally do not share the enthusiasm for Visual Studio. The main thing is being from the same company that controls the APIs, so there is no risk of the APIs running away from the IDE that generally dings other IDE scenarios. If MS is in the boat of supporting third party OSes/APIs as the norm rather than the exception, I think Visual Studio is likely to lose a great deal of what makes it the product of choice for MS platform development.

The problem some people site is 'too much choice', but pick one set and be happy. GTK+ or Qt for GUI as an example where there is choice but the developer doesn't have to think about it if they don't want.

No, what caused *excessive* insecurity in the 9x/ME case was a complete lack of meaningful user privilege separation. It carried over into XP because everyone pretty much had to run as Administrator to get a lot of things done with the legacy crap of 9x/ME to contend with. Vista and newer actually do weird things to fake out old applications (ugly, but necessary) and so they admittedly have done a good job of making a secure admin/user separation in spite of shitty applications relying on actions that mandate what would logically seem to be admin level privilege.

Hardware compatibility didn't cause insecurity in the XP days nor does it today. Tdoay it's just a matter of mostly popularity with some blame for having an overly complicated architecture providing ample opportunity for malware to slip itself in unexpected ways. The latter Linux used to be justified in feeling proud for having a more straightforward scheme, but a modern Linux desktop has been accumulating all sorts of weirdness approach the complexity of the MS design (dbus, dconf, etc).

In terms of the more relevant topic, the hardware picture has actually become less heterogenous in x86 over time. Once upon a time, you had to worry about Matrox, S3, 3Dfx, nVidia, ATI, and others on video cards. You had to worry about a myriad of storage controller chips and IO controllers. Now, overwhelmingly, if you cover AMD, Intel, and nVidia on graphics, you are done (there are others, but increasingly marginalized, and especially so in gaming). For storage, it's almost always integerated to the *singular* southbridge that is supported with the processor (at least on desktop). USB is exceedingly standardized such that most usb devices don't *have* a driver particular to them. On top of this, Linux is taken more seriously than it was a decade ago,

Well, the premise of the headline was *if* windows doesn't dominate. You are technically rejecting the feasibilty of that precondition.

In terms of MS owning both gaming and workplace PCs, that's not something I'd want to bet on. For one, you have Valve throwing some weight behind Linux. For another, you have consoles that include, among other things, Android platforms that are fungible. Think about how the Wii, despite exceptionally mediocre capabilities dominated share in the wider game industry. The marketplace is a lot more fickle than you give them credit for.

In the workplace, there is an ever decreasing reason to be microsoft centric. Enterprise application developers are moving stuff more and more into server-side code with decreasing expectation of browser platform. HTML/Javascript are displacing clunky activex controls for example. Office no longer is a hard requirement for 99% of their users as alternatives that are 'good enough' exist. AD and Exchange interoperability are probably the two biggest generic reasons to stick with MS in that market.

As much as I would love for that to be the answer, I have to confess that it just isn't feasible.

-Game support. Valve has done a lot to change this, but a great deal of gaming is still Windows exclusive. Even in some open source programs that do support Linux, the Windows version is vastly better (e.g. PCSX2 graphics plugin for directx is actually usable, whereas the opengl one really isn't).
-Network streaming support. Netflix and now Amazon prime at least can no longer run in linux. For the time being, Hulu still can but amazon prime at least shows that it's highly likely to evaporate.

Besides, just as Windows 8 lost its mind with a seemingly desperate UI experiment, you have Gnome 3 and Unity presenting some of the same issues (though with the option to completely swap out for KDE, MATE, etc if desired).

The issue is that WinRT has to offer *something* that IOS and Android do not in order to gain share.

They didn't pursue lower price, their offerings are no less expensive than Apple.

The didn't pursue better specs. They focused on Tegra 3, which is respectable but dated. Their screen resolution is downright atrocious compared to comparably priced products. While Android and IOS both have high ppi displays, MS has been left behind on this front.

They don't have more apps. Android and IOS had to build their ecosystems from scratch, but they had early mover advantage. After letting that situation simmer for years, they release a product with a paltry number of apps despite having a legacy of the most application compatibilty of any platform. They don't even have app compatibility between their phone and winrt as it stands (though that wouldn't have helped *much*, it still is a sign that they made a mistake compared with the strategies of Apple and Android).

Basically, every possible advantage that MS could have brought to market, they failed to do so. Like it or not, their best hope was/is to focus on x86 solutions where their application compatibilty can really come into its own.

But even I can tell a world of difference between professional photographer with good equipment and random guy with a cell phone.

Embedded camera in cell phone is necessarily restricted in terms of optics. You can play with the sensor all you want, but the optics simply cannot do the sorts of things a good camera can do.

There is still a lot of things that require some knowledge in operating a camera in order to get a good photo.

I'm not sure if you're trolling or not. Lets assume you're not.

This should do it,

It does seem like overkill to use a foam padded case, where you could just throw them on a cart. Well, assuming your office is so big that you couldn't just carry them.

For the vast majority of even HPC code, it means compiler rework and math library development. The vast majority of benefit can be achieved with a drop in of a new library without rebuild of the application. In your example, it would be the interpreter, which actually tend to be the last things to receive this attention.

Nah, you have the honeymoon period right after marriage, which can last anywhere from minutes to years. For most, it's just a few days. After that, sex is strictly solo or with mistresses and prostitutes.

Oh for fucks sake, won't anyone consider the poor married blokes who need a wank once in a while.. Online smut is lot cheaper than a fine strumpet.

I'd consider the fact that the most demanding android applications are arm specific in terms of compile is the more critical thing.

Intel does have a product with high core count, Phi has 50 cores for example.

I haven't seen a lot of evidence that ARM under load offered better price performance than Intel before. The only thing making that claim I can recall committed a grevious mistake, measuring ARM power usage and then assuming TDP value rather than measuring x86 power usage. It was undeniable that under typical smartphone/tablet conditions Intel did horribly (mostly 'idle' but immediately able to do things on demand), and that seems to have been the engineering focus this time, a shallower sleep state that's possible without screen blanking is one notable facet.

While Intel's prospects in the mobile arena are slim (Andorid has a lot of momentum, and that momentum is largely tied to ARM in much the same way as Windows is tied to x86), I suspect they will continue to rule the roost in the datacenter and workstation-like workloads.

I'm saying robbing the user of the control is bad. A lot of workflows got crippled.

For example, it is common for me to hit a slow loading website and tab-away to do something else for a second. In Metro IE, tabbing-away stops the loading activity.

In therms of fostering app developers who fail to properly tombstone, if android ecosystem has taught us anything is that developers are content to churn out shoddy work and never care. A platform that *forces* the developer to do more work isn't a defensible feature when an alternative model has existed for decades without a lot of issue.

The task switcher is only a gui nicety. Look in an aftermarket task manager. Swiping away does not kill it necessarily, it just removes it from display. , Conversely, just because you see a screenshot of it, it still might have been killed by the OS and switch back will be a start over. The ICS last application UI acts like its previous incarnation, except it scales to more apps, allows swipe to remove elements, and has thumbnail screenshots (*not* live preview as WebOS had, for example).

At least in ICS, this is the case. I don't have any Jelly Bean device to look at its behavior. Maybe the swipe to kill works now, but I would be massively surprised if Android ever removes its 'kill on a whim' design.

The music industry situation was different. At the time the market went to drm-free by a landside, music playback devices by and large had no wireless or cellular radios. They were fixed-function devices that could only consume non-executable content (mostly). In that ecosystem, supporting multiple platforms was difficult to the point of being unfeasible. For the no-name cheap devices, DRM was completely out of reach. Customers more keenly felt the pitfalls of DRM given the state of the ecosystem. Even if each publisher *could* put their content into walled garden apps, the nature of how music is consumed suggests back to back playback of arbitrary selections from a customers library over the course of minutes. Also, ripping CDs was trivial for even casual users.

The state of devices used for reading and movie playback are generally internet connected and companies can deploy their own content management application. Having to navigate and switch between the applications is less disruptive relative to how much time the consumer is going to spend in one specific work. Scanning books in is in no way feasible as a casual endeavor comparing with CD ripping. All the 'no name' devices that are available are android devices meaning DRM is feasible.

I'd like to think that the music industry went mostly DRM-free because they saw it as the non-evil way to go, but it was more about feasibility and the CD market pretty much leaving the barn door open, rendering it a silly exercise to DRM protect content that is trivial to rip in other ways.