I don't think I've ever seen a usable answer on that site.
I reported it on answer.microsoft.com. They asked for a crash dump. Complied. Another non-ms person analyzed the crash dump and suggested that it's USB 3.0 related. Disabling that in the BIOS solved the issue.
But the MS guys kept on going. A few weeks later, a reply that they managed to get their hands on a similar device (!!, cost about $200), but they couldn't find a driver, so they asked for mine. Pointed them to the online driver location (hidden on manufacturer site). Some time after that they commented that they managed to reproduce the BSOD. A few months later they released a fix (into Windows).
I had one of those, and the Vista drivers were never released as a production version. Driver support for it was THE thing that kept me from upgrading from XP to 7, and also what convinced me to never again buy a Creative product.
The matter became moot, and XP took a hike, when it finally crapped out one day. My audio interface is now a Focusrite.
At least not from a Microsoft employee. Sadly, the majority of posts from Microsoft employees I have seen basically repeat the problem description, followed by "Did I understand that correctly?", sometimes people get generic advice like reboot their computer, make sure their system has all available updates installed, etc.
Most of the time I get the impression the person writing it is a employee who is reading someone else's notes, has no idea what the answer even is, and then does the best to cover it up by using abstractions, off topic insight and buzz words.
Sorry Microsoft just my opinion regarding this one area. Room to improve maybe ?
Google promotes normal users to moderators on their support forums if they just post enough, so instead of being brushed off by some underpaid employee you are being ignored and ridiculed by someone not even being paid to!
Seriously, it can't be that hard to call the NT equivalent of strerror(3) when formatting these messages.
Fwiw the identifier you posted isn't a UUID but the same justification applies.
but with Linux, the case for me is that given enough time, I can usually find all the information I need to figure it out. With Windows it's Google for 10 minutes then throw my hands in the air and figure out a workaround.
I'm not sure which is better for my productivity: realizing that I accidentally screwed up my DNS resolver and spending the next hour hunting through forum posts and man pages before finding the snippet that explains what I was supposed to do and reconfiguring my resolved.conf symlink or figuring out the quickest, crudest workaround on Windows.
Stackoverflow really changed the game. I really should get active there again to give back more, I can't tell you how much a random stackover/superuser question helped me narrow down an issue.
Also, has everyone forgotten about IRC?
You just have to be tricky: People will not help you, but as pedantic as they are, they’ll correct mistakes you make.
You go there, and say "I’m disappointed that you can’t even use <device> with Linux" and you’ll get hundreds of answers telling you exactly how to use it.
True! However, obligatory "Gentoo is rice" link: https://fun.irq.dk/funroll-loops.org/
source: I got trolled by swedes in #linux before abandoning that wasteland for greener pastures listed above.
Arch? You need to make sure you're not looking at something a decade old.
I often just scope my google search.
Also, I do not find that I can answer every question easily for linux, even though I've used it as my primary OS since ~2002 and have some idea what to google for.
In fact, I have both sound and bluetooth issues on my machine right now that I have given up trying to resolve.
I have seen my fair share of this in the Windows world, too. Edit registry keys you never even heard of, use that (mostly undocumented) command invocation (I'm look at you, SharePoint!), edit that XML file that sits in a place where it does not even make sense...
On Linux (and other Unix systems), at least you have man pages, on Windows I cannot recall a single instance where the builtin help system has actually helped me. I mean, even MS-freaking-DOS had a reasonably useful builtin help.
With Linux, at least it gets better once you get the hang of it. Microsoft's sorry excuse for documentation is (mostly) a joke. (The exception are developer tools - the documentation on T-SQL and the .Net framework classes is fairly good, even though it's such a mess that it's easier to Google for specific entries than using the TOC or the builtin search... once I find what I was looking for, I do usually find a helpful answer to my question.)
(To be fair, when I first started using Linux, I found it incredibly strange, complicated, confusing and intimidating; within the first six months of using Linux, I was this close to literally throwing my PC out the window on no less than three occasions. So I know the frustration you speak of.)
If I went back to trying Linux, I'd need a suite of 'just-works' solutions; Plug & Play was the main reason my family moved from DR-DOS & Norton Commander to 95. And of course driver compatibility.
Honestly, if I went to an open OS from 7 at this point, I'd go to ReactOS.
Man get-command
Get-help get-help
But I agree, PowerShell is a huge improvement.
It's a lot harder to pull a specific, coherent, considered answer out of the internet, which doesn't involve duct tape and breakable insecure awful things.
"How do I run x on startup" will as likely get you "download this Ruby script which calls IFTTT.com triggered by when your network adapter connects, btw install this binary wifi driver blob" as "put this with a plain text password in /etc/whoknowsbutitworks lol" as "on your distro with your shell the startup system is XYZ and the startup scripts run like a then b then /home/user/c so put it in ~/c"
To be fair, that isn't specific to Microsoft, and a lot of big company's support sites are useless.
IME, Apple's Q&A discussion site is equally useless. The answers there are always along the lines of "That's by design, you can't do that." or "Why do you want to turn that off anyway?!?" I've had much better luck on apple.stackexchange.com
This. I can remember asking years ago, back when I had to work on OS X, asking how to turn off that freakin' annoying jumping icon in the system tray that leaped up and down after every successful print job until you dismissed it, just like an excited two-year-old telling you they went potty in the potty chair AGAIN, "Just like a big kid!" I can't imagine anyone thinking that attention-grabbing, ADHD-exacerbating, flow-destroying behavior was good by design, but was asked, "Why do you want to turn that off anyway?"
The guy would've probably gotten fired if he was honest: "that almost looks like it was done on purpose to force people to use Windows", but he could have avoided completely dismissing the guy.
For instance, by saying: "thanks for reporting this, I'll pass this to the tech team. In the meantime you can keep using your solution if it solves the problem for you".
It's probably hard for a huge company to give good tech support. It's not as if the support guy has any power to be helpful, they probably give him some copy and paste responses according to what the problem is.
The best tech support that I happened to use was Apple's. The guy actually seemed to care about my problem, and bypassed the protocol to help me out when I spilled coffee on my laptop.
In this case, I doubt someone thought "hey, let's mess with Linux users and serve them a bunch of garbage, it'll encourage them to move to Windows".
Also, the percentage of desktops running Linux is still tiny relative to Windows. The last time I saw any numbers (about two or three years back), it was ~90% Windows, ~7.5% OS X, ~1.5% Linux, so there is little incentive for Microsoft to care about Linux desktops.
Not for this one reason, but for 'webpages just work faster on Windows', sure.
If the only change necessary to improve speed is to update a string in the UA, I would say that's pretty hard to do accidentally. In theory, it could be an artifact of some internal QoS systems that prioritize requests from Windows boxes without the explicit intent of damaging the experience of non-Windows users, but that seems like a stretch. It'd be interesting to know if Mac UAs experienced similar slowdowns or not.
It's much more likely that Microsoft is interested in doing what they can to make sure that people feel "things just work better on Windows", and little limitations or breakages like this are the perfect way to do that. Windows is Microsoft's bread and butter and they haven't forgotten that.
There is no reason with the modern setups that entirely different UI pages need to be sent based on user agent detection. Every best practice I have read says to detect for features, and fall back to something more general when a feature isn't present. Clearly that is not happening here, and that little bit of technical incompetence is enough room to slide in a few hundred mb/s of transfers for certain targets.
Microsoft has a long history of pretending to play and throwing curveballs. All the way back to Dr DOS. Their run in with the DOJ was just one time they got caught. They are even doing stuff now with CPU detection and not providing windows updates to people with and older but still "supported" OS and a newer CPU. Just because they won't let it go, they are still patent trolling android handset manufacturers.
Why do we think microsoft has changed for the better?
Not knowing the code behind it, but knowing the history of the OneDrive for Business client, I could see a few ways this could happen. The OD4B client has gone through a bunch of iterations before being merged with the regular (public) OneDrive client, so along the way, there could have been optimizations added on that were only available to the new merged client. Due to constraints, this could have been done using a simple UA check. These optimizations could have been merged down to the OSX/Linux clients (not sure if they're using a merged one there, or still the separate ones) but since different teams work on the clients (most likely different teams on each client) and server, the Linux client team never told the server team that the it also supports these optimizations.
Easily could see the above scenario happening, it's not completely crazy when talking about big companies that teams don't have the best insight into eachother's work.
Disclaimer: Work on Microsoft. Not on Windows, not on OneDrive, completely different part of the company.
I'm sure a company like MS, who've had traumatic run-ins with the DOJ in the past, has internalized this phony management persona even more than most. And I do believe low-level developers who work on the individual clients are probably 100% earnest. They usually are. It's the people in the political structure who set their priorities and schedules and use them as pawns that you have to worry about.
Even if your postulation is exactly accurate, MS still bears responsibility for crippling the Linux client, no matter which specific employee the communication "fault" falls on.
I have no inside knowledge of Microsoft, this is just generic commentary and extrapolation on corporate politics in general. It is possible that I'm incorrect and this is truly an honest mistake. If this gets any attention, management will certainly claim that, and we'll never know the reality of whether it was unintentional or whether "The Linux client supports those speedups" was intentionally swallowed by someone along the line (or whether the patch was delayed for additional review because it was "accidentally bundled" with a bigger branch, or whether the priority has just been "innocently" pushed down, or whether the team is "just understaffed", or...).
The proof is in the pudding with corporate politics. Being in management is being a professional politician. That's always true. They're always going to try to tell people what they want to hear and cloud up the picture around things that that person doesn't want to hear. If Microsoft is continually engaging in a series of accidents that hurt non-Windows clients, that pattern is sufficient proof of management's intent, regardless of what they claim.
My guess is that they whitelist javascript or other things based on specific browser strings.
Onedrive for Business is a real shitshow product. IMO, the people supporting it scramble to make it perform at all.
That would only be slightly less worse than the sabotaging theory.
At the same time, this company has printed money for 30 years, not just beat the competition but killed the competition in many cases, and even made that an internal mantra. They have a pile of very smart people, money, etc.. there are also browser compatibility test services. They could have a VM grid with every interesting browser ever and it's not a big cost to them. A 15 person startup? I get they you might skip some browsers and focus on a key supported set. The tooling for that VM grid is also something I think a lot of the community would eat up of MS made available, there are lots of ways to build good karma and improve community relations.
Intentional or not, it's just bad optics, if nothing else. A slate with the windows 10 linux subsystem looked like an interesting environment to play around with and maybe give a shot. This sort of thing makes it look a lot less interesting. No joke, I was thinking of getting my kids one.
It's not something they can say. The product is unsupported and the "tech team" won't care.
Customers would feel respected, the workaround would be found and used, and no one would feel ignored. It would leave a customer happier than telling them they don't warrant interest.
Wait what? Really?? What are they monitoring, seed ratios from trackers? That's an interesting/novel way of researching demand-makes sense given the service Netflix provides.
http://variety.com/2013/digital/news/how-netflix-uses-piracy...
"SEE ALSO: Netflix’s ‘House of Cards’ Falls Prey to Piracy"
Still, that's a very interesting and out of the box method of thinking by the Netflix team. Definitely want to try and find out more about this; thanks for bringing this up!
Maybe it's not wise to automatically assume malice if incompetence could be a factor, but it's also not correct to rule out malice just because incompetence is a possible explanation.
It wasn't an MS product, or supported, and they still took the time to help. I'd be surprised if one didn't find similar responsiveness from at least some of the o365 developers. More often than not, something is "unsupported" not because it doesn't or shouldn't work, but because it doesn't have the dedicated testing resources and in case there is an edge case bug that would be excessively costly to fix (ex: dealing with stupid flexbox issues with the current version of Safari on mac).
In any case, it doesn't matter, the response was a bad, canned response that doesn't take into account the troubleshooting the person reporting it already did.
"Supported" in this context is clearly "we want more money from your despite you already having paid the agreed amount for this product".
[1] https://www.reddit.com/r/linux/comments/60nj67/office_365_on...
I then go and let the person who owns that product know. Half the time, they say "that's not a supported usecase and it's a pain to change, so it's not happening". The other half of the time, they shrug and say "Put a ticket in, if I can fix it easily I will, I'll take a look when I have time".
Unsupported doesn't mean "no", it means "we're not going to invest noticeable effort into it, and it's lowest priority". Easy fixes may happen, but results are not guaranteed.
The charitable hypothesis someone else raised is that there's a bug in how onedrive handles unknown user agents. Neither you nor I have any idea how much effort that will take to fix. You'd hope not a lot but you should never make assumptions about another man's stack. But if it is low effort to fix, Microsoft could get a small land-slide of partial compatibility with one change, which is good PR even if they don't officially support the platforms. It's definitely worth asking nicely rather than giving up and moping about it.
What I want from customer support is for someone to take the time to understand why I am calling. Not to pat me on the head and tell me things will be alright while urgently trying to get rid of me.
I disagree. When I call support I'm not looking to commiserate or share my misfortune. I'm looking for acknowledgement of and resolution to a problem.
This view that empathy is what's important is the reason why hold messages say "your call is important to us" and why all customer support feigns empathy to my emotional plight when I call them about anything.
Saying I care and actually caring are not the same. When I call a hotline with a problem and am stuck in a loop telling me how important my call is to them, it tells me they don't care at all.
At least that how I understand the comment, and since I also wear a helpdesk-monkey-hat at work, it is how I try to deal with our users.
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.
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?
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.)
Wrong.
There are plenty of bugs that cannot be detected using feature detection, especially with events and <input> elements. Sometimes you can find a browser-agnostic workaround, but sometimes the only solution is to sniff the browser.
It is especially necessary if you need to support "obsolete" browsers that your customers still use.
It is important to really try and avoid browser sniffing when "fixing" bugs in current versions of browsers (since your "fix" is likely to break in future versions).
Note, feature detection usually implies that you are using JavaScript.
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.
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.
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'".