Hacker News new | ask | show | jobs
by piemonkey 3271 days ago
One amusing thing about this epic tale is Serious Industrial OCaml User disregarded direct, relatively easy to implement, very sound advice from Xavier Leroy about how to debug their system! I would like to think that, were I in a similar situation being advised by an expert of that calibre, I would at least humor his suggestions.

Why seek the expert if not for his advice? It brings to mind people disregarding doctors who give them inconvenient medical advice.

2 comments

Not saying this is what happened in this circumstance, but even an expert has to explain the 'why' of things. "Disable HT and try again" comes with a hint of "please go away", whereas "disable HT so we can eliminate a potential cause" smells more like "I really want to understand this thing."
I know nothing of OCaml culture or why the author is deemed worthy of having his name italicized, but the doctor comparison is upsetting. If the guy who wrote this:

I was tired of this problem, didn't know how to report those things (Intel doesn't have a public issue tracker like the rest of us), and suspected it was a problem with the specific machines at SIOU (e.g. a batch of flaky chips that got put in the wrong speed bin by accident).

were a doctor, he'd be guilty of malpractice. This bug went unreported eight months longer than it needed to. Am I misreading all this somehow?

His name is italicized because he is the primary author of OCaml (and a plethora of other great tools, like CompCert, the first fully-verified compiler). Overall, an exceedingly competent and productive programmer and scientist.

The doctor metaphor isn't perfect; what I was going for is, when you are seeking out an expert's advice and you ignore it, why do you go to see the expert in the first place?

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).

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.
No he wouldn't. Doctors are not obligated to write up case studies or submit them to medical publications.
It's a bad analogy, yes. I'm not sure who the people who suffered intermittent system problems for months longer than they otherwise would have, had he reported the problems when he found them, are under the doctor analogy - not patients under his treatment, certainly.

> Doctors are not obligated to write up case studies or submit them to medical publications.

That's true, although I think we'd all agree that a person who has the knowledge to create a lifesaving treatment for a disease and doesn't bother writing it down because, well, writing is boring, is behaving rather unethically.

But this is merely computer science, not medicine.