3 ms·

I don't really see it that way. I don't think Microsoft would be expected to offer support for an operating system that's not officially supported. I could see

by simias 10y ago

I don't really see it that way. I don't think Microsoft would be expected to offer support for an operating system that's not officially supported. I could see only two ways this could've turned out, either "we're planning to support linux in a future version, we'll keep you updated when that happens" or exactly what we got here. If this is actually a bug then I think it would be rather inappropriate for the support guy to escalate this to the devs when it only happens for an unsupported platform. And if they're purposefully throttling linux hosts then they won't admit to it there. So the entire exchange (including Dam Lec deciding to abandon Onedrive) seems perfectly reasonable to me.

CodeWriter23 10y ago
Obviously it works on Linux; the slow down is the direct result of OneDrive's User-Agent based code paths.
- askmike 10y ago
  And what if some programmers are put unto fixing this, to realise the normal code path has a number of other bugs for linux? If you write web software you clearly define what you support and what you do not. I've fallen into the "I know this browser is not supported, but everything works except for X" trap. Where you first spend a month fixing other bugs that also don't work, only to end up with a more complex QA dev process since you need to make sure all new features also work in this other browser or environment.
  - dv_dt 10y ago
    It's true, but the flip side is don't offer a web based product if you can't support a wide range of web browsers on multiple OSes. This gives me flashbacks to old (hopefuly dying) "web based" enterprise apps that were browser accessible only by a one magic version of windows explorer with a giant slew of automatically downloaded browser extensions. Just produce an app if that's all that can be supported.
    - askmike 10y ago
      You are right, but I guess Microsoft is somewhat biased towards their own products (Windows in this case).
- popey456963 10y ago
  This. People forget that they're _actively_ appearing to break it by using this UA detection. No company should _ever_ use user-agents for feature detection, because user agents themselves are screwy in so many ways [0]. Honestly, I feel like this was someone actively deciding to break the system on Linux (or any unrecognised UA). Wouldn't any reasonable developer just send back a fully-featured page if they couldn't understand a UA? [0] http://webaim.org/blog/user-agent-string-history/ http://webaim.org/blog/user-agent-string-history/
  - nathantotten 10y ago
    You don't know when this code was written or what the original purpose was. User agent detection used to be a best practice. Onedrive for business is a mountain of legacy software going from sharepoint to groove to who knows what. This bug could be buried in some library that was written 5+ years ago. Maliciously going out of your way to not support Linux sounds like a good way to have your code review rejected.
    - emn13 10y ago
      To this day, user agent detection is the only (practical) way to avoid sending large polyfills to the 95% of clients that don't need them.
  - greenhatman 10y ago
    Yea, call my cynical, but Microsoft Office is one of the few applications that doesn't have a good alternative on Linux. So this seems like a ploy to stop people from using Linux. At least the ones that would like to use Microsoft Office.
  - derefr 10y ago
    UA "detection" is an unworkable mess (i.e. a bad idea) when it's trying to differentiate between different consumer web browsers. But UA detection works just fine when it's only trying to differentiate between browsers as a whole, and things that are not browsers—like web spiders, or curl(1), or your native client app. I have a feeling that this is the latter case. The detection code was likely written to give a higher QOS priority to direct browser access, and a lower QOS priority to the native OneDrive sync service built into Windows (because it happens in the background.) But in doing so, they probably made the check ask the wrong question—"is this a browser" instead of "is this our client"—and thus wrote the check with a browser whitelist pattern (that was never tested outside of UA strings from browsers on Windows), rather than a blacklist pattern (their one sync-service UA.)
- simias 10y ago
  If said code paths work correctly on the supported operating systems and browsers why does it matter? You could say that it's a poor technical decision but that's really not up to the support to address. I guess you could reproduce the bug on a supported OS and browser by manually changing the user agent but I doubt the support would accept that either. It would be like complaining that the site becomes unusable if you disable javascript or images, they probably only support "vanilla" browsers.
colanderman 10y ago
Well if they want to play games with semantics, I'm pretty sure one could reproduce this bug on a Windows machine.
7952 10y ago
Web apps are marketed as "working anywhere" you have a browser. The underlying OS should not matter, and that again is a selling point. And presumably this issue is present on mobile browsers with low market share.
- simias 10y ago
  That's not the point I'm trying to make. Clearly support has to draw the line somewhere, "working anywhere" is not a reasonable commitment. Linux is not officially supported, the problem doesn't occur (I assume) on supported configurations, therefore it's not up to support to deal with this. I genuinely can't imagine what else the guy could do, checking for unsupported configurations is probably item #2 on his script, item #1 being "say 'Hi'".
1_2__3 10y ago
Remember when browsers were supposed to untether you from the OS? How is operating system support at all involved for a web-based application?
sametmax 10y ago
But it's not a support problem since clearly just changing the ua makes it faster. It has nothing to do with linux. Somebody hardcoded it.

by simias 10y ago

CodeWriter23 10y ago

Obviously it works on Linux; the slow down is the direct result of OneDrive's User-Agent based code paths.

askmike 10y ago
And what if some programmers are put unto fixing this, to realise the normal code path has a number of other bugs for linux? If you write web software you clearly define what you support and what you do not. I've fallen into the "I know this browser is not supported, but everything works except for X" trap. Where you first spend a month fixing other bugs that also don't work, only to end up with a more complex QA dev process since you need to make sure all new features also work in this other browser or environment.
- dv_dt 10y ago
  It's true, but the flip side is don't offer a web based product if you can't support a wide range of web browsers on multiple OSes. This gives me flashbacks to old (hopefuly dying) "web based" enterprise apps that were browser accessible only by a one magic version of windows explorer with a giant slew of automatically downloaded browser extensions. Just produce an app if that's all that can be supported.
  - askmike 10y ago
    You are right, but I guess Microsoft is somewhat biased towards their own products (Windows in this case).
popey456963 10y ago
This. People forget that they're _actively_ appearing to break it by using this UA detection. No company should _ever_ use user-agents for feature detection, because user agents themselves are screwy in so many ways [0]. Honestly, I feel like this was someone actively deciding to break the system on Linux (or any unrecognised UA). Wouldn't any reasonable developer just send back a fully-featured page if they couldn't understand a UA? [0] http://webaim.org/blog/user-agent-string-history/ http://webaim.org/blog/user-agent-string-history/
- nathantotten 10y ago
  You don't know when this code was written or what the original purpose was. User agent detection used to be a best practice. Onedrive for business is a mountain of legacy software going from sharepoint to groove to who knows what. This bug could be buried in some library that was written 5+ years ago. Maliciously going out of your way to not support Linux sounds like a good way to have your code review rejected.
  - emn13 10y ago
    To this day, user agent detection is the only (practical) way to avoid sending large polyfills to the 95% of clients that don't need them.
- greenhatman 10y ago
  Yea, call my cynical, but Microsoft Office is one of the few applications that doesn't have a good alternative on Linux. So this seems like a ploy to stop people from using Linux. At least the ones that would like to use Microsoft Office.
- derefr 10y ago
  UA "detection" is an unworkable mess (i.e. a bad idea) when it's trying to differentiate between different consumer web browsers. But UA detection works just fine when it's only trying to differentiate between browsers as a whole, and things that are not browsers—like web spiders, or curl(1), or your native client app. I have a feeling that this is the latter case. The detection code was likely written to give a higher QOS priority to direct browser access, and a lower QOS priority to the native OneDrive sync service built into Windows (because it happens in the background.) But in doing so, they probably made the check ask the wrong question—"is this a browser" instead of "is this our client"—and thus wrote the check with a browser whitelist pattern (that was never tested outside of UA strings from browsers on Windows), rather than a blacklist pattern (their one sync-service UA.)
simias 10y ago
If said code paths work correctly on the supported operating systems and browsers why does it matter? You could say that it's a poor technical decision but that's really not up to the support to address. I guess you could reproduce the bug on a supported OS and browser by manually changing the user agent but I doubt the support would accept that either. It would be like complaining that the site becomes unusable if you disable javascript or images, they probably only support "vanilla" browsers.

colanderman 10y ago

Well if they want to play games with semantics, I'm pretty sure one could reproduce this bug on a Windows machine.

7952 10y ago

Web apps are marketed as "working anywhere" you have a browser. The underlying OS should not matter, and that again is a selling point. And presumably this issue is present on mobile browsers with low market share.

simias 10y ago
That's not the point I'm trying to make. Clearly support has to draw the line somewhere, "working anywhere" is not a reasonable commitment. Linux is not officially supported, the problem doesn't occur (I assume) on supported configurations, therefore it's not up to support to deal with this. I genuinely can't imagine what else the guy could do, checking for unsupported configurations is probably item #2 on his script, item #1 being "say 'Hi'".

1_2__3 10y ago

Remember when browsers were supposed to untether you from the OS? How is operating system support at all involved for a web-based application?

sametmax 10y ago

But it's not a support problem since clearly just changing the ua makes it faster. It has nothing to do with linux. Somebody hardcoded it.