But the only time it is buggy if you SAY it's Linux. If you say it's Windows, it works fine. That's not having the software passively become buggy, that's CHANGING the way the software works if and only if the OS is Linux, but working correctly if it's told (but isn't actually) Windows.

I don't think this is a conspiracy, but I don't think the characterization that users think that because OneDrive works on Windows better than Linux, buggy by inaction is assumed to be buggy by action: this situation is far more damning than that.

It seems entirely plausible that there are optimizations that are only applied on certain platforms or something with the idea that any platform should fall back to the slower but better-supported behavior.

Should be testable, for example what optimisations are in the FF48 code sent to Windows that breaks FF48 on Linux?

MS will I'm sure provide those details to demonstrate their lack of malice. /s

If you're that hot and bothered about it try fetching a page with both UAs.

Except that we're talking - as far as is visible to me at the moment - about server side behavior, something that need not change at all depending on the user's client.

No we're not. The bug report says 100% CPU. It's very clearly doing something client-side.

That is speculative. Yes, the client side is the one where the problem shows up but it's when the user agent is changed that the problem appears and the client side does not do anything with that user agent, it gets sent to the server. So something in the response from the server or some interaction with the server than causes the 100% CPU load.

That is exactly what the people you are responding to are saying.

The client makes a request to the server, and the server either returns the new optimized client code if the user agent is one that it knows supports the new code, or it sends back the older, slower, client code for an unknown user agent.

They are probably returning the older code because they KNOW it works, even if slower, while they aren't sure if the new code works or not on other machines. The author says it works fine on linux when getting the windows response, but we can't be sure he has tested every use case; maybe it fails under particular conditions, which is why they are still returning the old code. Or, perhaps, they just haven't tested it so they go with the safe thing, which is to return the older code.

So, you're telling me Microsoft is unable to tell the difference between code that doesn't work (the 'old' code) and code that does work (the 'new' code), and that to be safe they are returning the non-working code as a fix for potential problems that do not appear to exist?

If there is anything that would be more damaging to Microsoft than calling them malicious it is probably calling them incompetent, that's their core expertise you are challenging there.

Of course MS is unable to tell the difference between code that works and code that doesn't... on an unsupported platform.

Incompetent? "MS: We support Platform X, Y, Z." ... "Mob: MS must be malicious or incompetent because they aren't testing and pushing new code to Platform 9 3/4"

Unsupported. Means exactly that.

Well, from where I'm sitting a server should just do what it does for everybody without shipping different code to 'unsupported platforms' in order to make those platforms work worse. It either serves up the same to everybody or it contains code to support some platforms and blocks others.

A 'best effort but unsupported' isn't an option, it reminds me of the SMB days.

Either you support a platform outright, you send out the same code to everybody or you disable the platform completely. Other options are sufficiently gray to count as ways to coerce people into making a platform switch, and the MS rep seems to be pushing in exactly that direction.

" For the best experience, we recommend the operating system listed in this article. "

Right.

Well not all platforms are created equal... it's why you have fall-backs to "Stable but not shiny" for platforms you don't support... or platforms you don't know supports New Shiney Thing (tm).

If you know browser X, Y and Z support HTML5 video - because that's your actively supported platforms... but someone says I'm browser 6... do you push HTML5 video? Or do you fall back to stuff you know works but is years old tech?

If you don't know what Browser 6 is... then you have 2 options: Safe options or Feature Detection.

Safe option: I don't know if you can read HTML5... so I'm going to serve you HTML like it's 1999.

Feature Detection: I'm going to go out of my way to see if you can support random new technologies that I'm using. Can use HTML5? You can? Oh... Here's your scripts... or... You can't? Here's HTML like it's 1999.

The first option is a lot easier. "Unknown? You get 'Safe' tech that's not shiny, optimized or best-of-breed. Known? You get stuff we said we support on platforms we say we support".

Second option requires testing and blending the technology stack based on detected features. Possible - because plenty of people do it - but it's definitely not as easy to support dozens of techs in many many more possible combinations.

It looks like MS took Door #1.

Are you saying you would ship HTML5 code to platforms you don't know support HTML5? Because... that sounds like a recipe to send "broken" code to users because "everything should work the same everywhere" which is something that happens... never.

> Are you saying you would ship HTML5 code to platforms you don't know support HTML5?

No, I would stick to open standards supported by the vast majority of users until the next wave was supported by the vast majority of users and so on. I would never detect a user agent and make crippling decisions based on the response.

And if you do decide to resort to such trickery then you'd better make sure that you extract the maximum out of each platform that presents itself otherwise you open yourself up to claims of favoritism.

As for the HTML5 video, given that I've pioneered that stuff and worked very hard to keep the video-on-the-web scene plug-in free and working with all browsers it was with serious reluctance that I eventually switched to H.264 encoded video with flash as the player because to me that was the wrong way to go about it but the market literally demanded it.

I suspect that if we had not had flash a proper <video> tag would have been implemented ages ago.

"stick to open standards supported by the vast majority of users" is exactly what you get when the user agent isn't known. It just turns out in this case that it's unoptimized and performs pretty badly.

Please. If they displayed a page saying "sorry, Linux isn't supported; try using a supported platform instead" you'd be over here taking them to task for that.

Actually, I would not. MS is under no obligation to support anything other than their own platforms. But if it works it should work well rather than be effectively cripple-ware.

Well I completely disagree that not being able to use the software at all is better than a degraded experience and I can remember at one point Linux users railing against exactly what you're now advocating.