3 ms·

I clicked through to the github exchange he links to, and I don't think you can call that shabby treatment. Perhaps a bit too terse (though I don't think so), b

I clicked through to the github exchange he links to, and I don't think you can call that shabby treatment. Perhaps a bit too terse (though I don't think so), but it's just saying "the docs say data must meet requirement X, and that's good enough". His other examples sound prima facie troubling (I don't know enough clojure to have a real opinion), but he's miss-characterizing that interaction.

mcguire 10y ago
Once upon a time, many years ago, I was taking a database implementation class at the same time as working as a sysadmin of the university. We started having a weird problem with our AIX 3.2.5 (...years ago...) machines: the NFS subsystem would deadlock and become a tar-baby; any process that touched the affected filesystem would block, including other users' processes, system processes, and (the important part) the automounter. As a result, the boxen were effectively unusable until rebooted. Considering that they were serving 8 x-terminals and remote users, that was a problem. We eventually narrowed it down to students working on their DB implementation projects, and further to the use of mmap. If you mmap'ed a region larger than a physical file and wrote to the outside region, that NFS filesystem went belly-up. Yes, that's explicitly mentioned as a thing not to do in the mmap documentation. (On the other hand, it worked fine on a local AIX filesystem and in fact was how local file systems extended files; I'd spent the previous couple of years working with AIX filesystem developers.) Anyway, after getting the professor to tell the students not to do that, I notified IBM tech support. The response I received was exactly, "the docs say data must meet requirement X, and that's good enough". In a sudden fit of ethics (honestly, I have no idea what came over me), I completely failed to advertise the nifty denial-of-service attack widely. It would have been spectacularly amusing to embarrass my former employer on BUGTRAQ, say. Not to mention imagining the face of the tech support guys when they tried reading their "good enough" spiel to an IBM customer who had more than our handful of machines. On the other hand, AIX 4 was a complete re-write and fixed the problem with the NFS filesystems. Yay. Anyway, the bottom line is that using documentation to cover your ass for implementation infelicities is not a very good idea.
- hyperpape 10y ago
  This is a nice example of when that's a garbage answer. But I wasn't saying Nolen gave a technically sound answer (not denying it either--it all depends on the details of the case and the consequences). I just meant that it wasn't shabby treatment--if his technical judgment is wrong here, that wouldn't make him a jerk.
  - mcguire 10y ago
    The thing is that "the documentation says not to do that" is almost always a garbage answer---even when the docs say it in big flashing letters, like mmap. A good interface should never produce garbage, even when fed garbage. In those cases where it's a necessary answer (say, the interface has no way to have the information necessary---which certainly doesn't apply here), Nolan's answer was completely insufficient and demonstrates a serious lack of respect for the poor sot who spent the time to report the issue.

mcguire 10y ago

Once upon a time, many years ago, I was taking a database implementation class at the same time as working as a sysadmin of the university. We started having a weird problem with our AIX 3.2.5 (...years ago...) machines: the NFS subsystem would deadlock and become a tar-baby; any process that touched the affected filesystem would block, including other users' processes, system processes, and (the important part) the automounter. As a result, the boxen were effectively unusable until rebooted. Considering that they were serving 8 x-terminals and remote users, that was a problem. We eventually narrowed it down to students working on their DB implementation projects, and further to the use of mmap. If you mmap'ed a region larger than a physical file and wrote to the outside region, that NFS filesystem went belly-up. Yes, that's explicitly mentioned as a thing not to do in the mmap documentation. (On the other hand, it worked fine on a local AIX filesystem and in fact was how local file systems extended files; I'd spent the previous couple of years working with AIX filesystem developers.) Anyway, after getting the professor to tell the students not to do that, I notified IBM tech support. The response I received was exactly, "the docs say data must meet requirement X, and that's good enough". In a sudden fit of ethics (honestly, I have no idea what came over me), I completely failed to advertise the nifty denial-of-service attack widely. It would have been spectacularly amusing to embarrass my former employer on BUGTRAQ, say. Not to mention imagining the face of the tech support guys when they tried reading their "good enough" spiel to an IBM customer who had more than our handful of machines. On the other hand, AIX 4 was a complete re-write and fixed the problem with the NFS filesystems. Yay. Anyway, the bottom line is that using documentation to cover your ass for implementation infelicities is not a very good idea.

hyperpape 10y ago
This is a nice example of when that's a garbage answer. But I wasn't saying Nolen gave a technically sound answer (not denying it either--it all depends on the details of the case and the consequences). I just meant that it wasn't shabby treatment--if his technical judgment is wrong here, that wouldn't make him a jerk.
- mcguire 10y ago
  The thing is that "the documentation says not to do that" is almost always a garbage answer---even when the docs say it in big flashing letters, like mmap. A good interface should never produce garbage, even when fed garbage. In those cases where it's a necessary answer (say, the interface has no way to have the information necessary---which certainly doesn't apply here), Nolan's answer was completely insufficient and demonstrates a serious lack of respect for the poor sot who spent the time to report the issue.