Thanks, that makes sense. I don't disagree about taking expert advice! I was just really disappointed to read the part of the article where the author doesn't bother to figure out how to navigate Intel support and report the bug.

Bug reports are gifts from inconvenienced users to vendors who have just done free work on the vendors behalf. There is absolutely no obligation on the part of a user to report bugs.

I am shocked by this attitude. Maybe I shouldn't be, and I'll certainly give this all some thought.

There's at least one obvious error in your statement: if an inconvenienced user's bug report results in less downtime for other users, it is a "gift" to other users, as well as a "gift" to the vendor.

But it says something about our profession if we regard putting flags down to mark the landmines we find a mere courtesy (a gift!) instead of an obligation. I guess that's a debate for a different time and place.

Well, guess what: you're as entitled to your opinion as I am to mine.

But just like a user has no obligation to 'mark the landmines' for vendors they also have no such obligation towards other users. They do have a right to receiving bug free software in the first place, alas our industry is utterly incapable of doing so which has lowered our expectations to the point where you feel that we have an actual obligation as users to become part of the debugging process.

That is not going to make our lives better.

What will make our lives better is if software producers accept liability for their crap they put out and if they were unable to opt-out of such liability through their software licenses and other legal trickery.

You're just a small step away from making it an obligation rather than an optional thing for users to report bugs, the only difference is that for you the obligation is a moral one rather than a legal one. I really do not subscribe to that, when I pay for something I expect it to work and I expect the vendor (and definitely not the other users) to work as hard as they can to find and fix bugs before the users do.

But we're 'moving fast and breaking shit' in the name of progress and part of that appears to extend to being in perpetual beta test mode. That's not how software should be built and I refuse to subscribe to this new world order where the end user is also the Guinea pig.

Keep in mind that users have their own work to do, are not on the payroll of the vendors usually have forked over cold hard cash in order to be able to use the code (ok, not in the case of open source) and tend to be less knowledgeable about this stuff than the vendors. They really should not have a role in this other than that they may - at their option - upgrade their software from time to time when told very explicitly what the changes are (and hopefully without pulling in a boatload of things that are good for the vendor but not for them).

> You're just a small step away from making it an obligation rather than an optional thing for users to report bugs, the only difference is that for you the obligation is a moral one rather than a legal one.

I'd argue that a person does have that obligation in some circumstances, yes. And yes, I am thinking in moral rather than legal terms. The legal picture is pretty far outside my expertise, and the professional ethics of software engineering (which would in turn inform the legal picture) seems to be woefully opt-in. As you say, 'moving fast and breaking shit,' perpetual beta test mode, etc. So I'd put the legal stuff aside for now.

For me, the key is that "user" is a deceptive term here. A mere user cannot point to a small piece inside a much larger machine and say "that will blow up occasionally, and I know exactly when." We are talking about engineers. Or at least, I was thinking of the professional obligations of engineers - on the user side of the fence and the vendor side of the fence - and that was informing my comments.

> Keep in mind that users have their own work to do, are not on the payroll of the vendors usually have forked over cold hard cash in order to be able to use the code (ok, not in the case of open source) and tend to be less knowledgeable about this stuff than the vendors.

Yeah, and I don't think I disagree with you in the "user" case. I really think a software engineer finding a CPU bug is a different case. It seems me that if we're in possession of knowledge of something as serious and wide-reaching as a CPU bug, we have a reproducible test case, and we don't do anything with it (I mean, at least a tweet or something, for the love of God) we are part of the problem with our profession.

I'm on board with a reporting duty if such a thing will always result in:

(1) a payment from the vendor to the reporter compensating them for time and effort spent at getting the bug to be reproduced

and, crucially,

(2) a requirement for all vendors of software and hardware to timely respond to bug reports and to have a standardized reporting process.

In that case I can see how such a shared responsibility would work, but as it is the companies get the benefits and the users get the hardship with a good portion of reported bugs (sometimes including a solution) that go unfixed, that's not a fair situation.

Case in point: I've reported quite a few bugs to vendors over the years but I've stopped doing it because in general vendors simply don't care, most of the time bug reports seem to result in a 'wont fix' or 'here is a paid upgrade for you with your fix in it'.

The security guys seem to be converging on a way of managing these - the compensation of the person reporting the bug and the factors motivating vendors to respond to the bug report in a timely fashion or suffer consequences - with bug bounties. Intel should make it easy to report this stuff, but if everyone understood that finding something genuinely interesting resulted in a serious payday, nobody would skip making the call.

The difference between something like Google's bug bounty (capped at over $30k, I think) and a hypothetical bounty for Intel is, well, Intel has a lot more at stake. It's honestly strange that they don't have something in place already. Something like Skylake costs on the order of billions to get out there. It's cool that this Skylake bug was fixable via microcode, but the Pentium FPU bug back in the day cost them half a billion dollars. If such a bug exists, that is the kind of thing Intel should want to have reported as soon as humanly possible. Even the reputational damage they take from something milder like the Skylake bug would justify a bounty system with very serious payouts.

I am genuinely wondering why you think this way? I do not expect my users to report failures. If they do I am more than pleased (not sure I would call it a "gift") because it shows that my product is good enough that they won't just leave out of frustration.

As technologists, we develop tools and services to capture bugs (both server side and client) so that we gain more insight into how our product operates. A user that takes time to give a well crafted bug report is rare. Most of the time it tends to be legitimate gripe that a feature isn't working.

Update: After writing I am re-reading your comment and now thinking we are on same page.

> figure out how to navigate Intel support

Do you have a step-by-step guide for doing that or are you just assuming that there must be some magic way?

Since we're communicating via rhetorical questions, are you asserting that it's literally impossible to contact Intel support with a defect, or merely tedious? Does it become easier or more difficult if you have a reproducible test case and the sort of connections a prominent FP compiler person has?

I'm trusting the account of the prominent FP compiler person who had a test case and wrote in the linked article that he found no way to submit the issue. You're the one saying this cannot be true, but you're not saying why you think so.

1. That's not what I'm saying

2. That's not what he wrote