The reason people attempt to file perpetual copyright is that the things being copyrighted, in most cases, still have value. If others are uncomfortable with that, they are perfectly free to create something different/better. People should stop arguing for the removal of other's rights because it's inconvenient for them.
You're looking at this through the European perspective -- as if the creator's monopoly on their work is a natural right.
Look at it again, as if the natural order of things in for information to be usable without restriction, and copyright is an artificial monopoly created for the sole purpose of benefiting the greater good of the public as a whole.
To be sure, things which are copyrighted may have value to the eventual rightsholder 90 years later -- but if you calculate present value at the time of creation (if you've never taken an accounting class, this determines the amount which would need to be invested, at current interest rates, to yield the same eventual income as the extended monopoly period would grant; this sum effectively represents the amount of economic motivation granted to an author to create their work), the amount of value which the creator receives at the time of creation based on this extended grant of exclusive rights is absolutely minimal. On the other hand, the costs levied on the rest of the economy -- even excluding the unknowns of derivative works which aren't created, public-benefit performances which don't occur, and enhanced breadth of society's culture as a whole based on expanded exposure to knowledge -- are considerable indeed.
I agree that shorter terms with an option to renew are desirable, but also hold that the length of renewal should be limited either explicitly or via economic incentives (ie. attaching significant cost for renewal after a reasonable period).
Just because you don't want others to retain rights doesn't mean that copyright needs to be limited by anybody other than the creator. If they want to give it away, fine. It's not up to you to decide that they've gotten enough out of it and it should be yours for free now. It's perfectly in your power not to use it or pay for it, but people seem to have issues with that as well....
Unlike European copyright law, which is premised on creators' rights, US copyright law is premised on public benefit -- encouraging creation of new works as a first and primary goal, accomplished by means of a temporary, government-provided monopoly by which creators can make a return on their work.
Perpetual copyright leads to economic inefficiencies (in which the cost to the public as a whole vastly outweighs tho benefit to the author and inheritors (if you need me to cite an peer-reviewed analysis to this effect, let me know and I'll dig up a few), to older works being lost because nobody has the rights to reproduce them (or enough economic incentive to do that at the price the present rightholder wishes to charge), and to new works which could leverage the public domain (the "creative commons") not being created.
If you want to argue that 10 years is a bad idea, that's an eminently reasonable position to take. Arguing that copyright should be perpetual, on the other hand, goes against everything US copyright law is based on, and favors a position which would be very much to the detriment of the public, including those who create new works.
But... but... You seem to think that because CPAN still supports older packages, everyone is going to use them.
No, I'm just explaining why CPAN's huge collection of outdated libraries really doesn't matter to someone deciding between Perl and Python today if they're going to be writing new code.
Having to run python 2 code through a convertor and then fix the rest by hand doesn't seem to compare very well with perl backwards compatibility across the same time frame.
I pretty much agree with you that the converter approach is unfortunate and unwieldy. On the other hand, having ill-defined changes which may or may not cause breakage without warning between minor releases (which is where Perl seemed to be back before I switched -- obviously your milage varies, and I'm certain this will be fully and completely resolved by Perl 6 with its formal language definition) isn't much fun either.
Picking between a number of well-documented XML technologies such as LibXSLT and Sablotron seems to me to be altogether better than going for The Newest From Scratch XSLT Implementation In My Favourite Language, as if this implementation is going to be the first ever not to have any bugs and not to deviate from the specs in any way whatsoever.
As I pointed out, part of the point of newer libraries is that they can leverage other modern tools; lxml, for instance, leverages libxml2 heavily, and thus is far from "from scratch", and benefits from all of libxml2's reliability and compliance. (Likewise, its API design borrows heavily from the good ideas of ElementTree, to the point of being backwards-compatible with the same). XML libraries written before libxml2 obviously cannot leverage that effective standard, or (at minimum) have high-level APIs designed with a different low-level implementation in mind.
If we all picked the oldest, most thoroughly battle-tested library that we could possibly use for any purpose, I would be using something like PyDOM when I needed to do DOM work -- and my code would be longer, more complicated and harder to read for it. ElementTree's API style gained traction because it was better -- fewer and more readable lines needed to achieve a desired result; lxml continues that further.
Also, what you are calling bit rot is what enables backwards compatibility. Python seems to be a bit better than PHP on this score, but, as I understand it, Python 3 will not be compatible with Python 2, and issuing warnings in Python 2.6 is supposed to magically update all legacy code.
To clarify -- Python 2.6 warns about only those things which the mechanical py2to3 (or whatever they're calling it) code conversion tool can't fix; the bulk of changes will be done programmatically by the translator, no human involvement (other than running the translator, checking in its result and bumping the release number) needed.
Anyhow, 'yall Perl folks don't have much room to talk on this count -- I was bit plenty by backwards incompatibility in a minor Perl interpreter release somewhere between 1998 and 2001 (sorry, don't remember more precisely than that). Python has had a formal language definition and change-control process for quite some time now, and benefitted quite undeniably, even now when backwards-compatible changes are deliberately taken place: Because all syntax changes are known and enumerated (rather than having language behavior defined by the implementation, as was historically the case with Perl), projects such as the mechanical translator are easier to develop and prove correct.
You could equally argue that many of the CPAN modules have been tested and fixed incrementally over a decade, ie that new code isn't necessary better code. Some of the major CPAN modules have stopped being updated because there is pretty much nothing left to fix.
For code with no dependencies, which interacts with no evolving standards, this may be true. For other code, one word: Bitrot.
A library may be perfect in and of itself, but the rest of the world moves on. Ten-year-old code is likely to reinvent wheels which modern code would use 3rd-party libraries to implement, increasing size and decreasing maintainability and debuggability. Ten-year-old code won't use newer interfaces (see ipchains vs iptables, select vs epoll, polling stat() vs inotify() vs dnotify()), won't support newer features (see: XML libraries without XPath), and aren't built with knowledge gained by observing their contemporary competitors. Even SMTP just went through a revision; time passes, the world moves on, and code over time goes bad.
Well, until I see proof otherwise, I see no reason why the percentage of crapware on CPAN is any different than the percentage of crapware on PyPi.
A few reasons which might partially account for the difference I've observed:
PyPi is newer. Less of what's there has bitrotted or become unmaintained.
Much of the Python crapware I've run across doesn't bother supporting setuptools, and thus doesn't get on PyPi. In cases where something is genuinely useful but the upstream author doesn't add setuptools support themselves, someone (and in a case or two, I've been that someone) provides a patch or forks the project.
All that said, you are right, much of it comes down to, is what I need there? Problem is, that answer depends based on the problem domain. And I'm willing to bet that, based purely on the sheer number of packages available in CPAN, it's more likely to cover obscure topics, in addition to the more popular subjects that both CPAN and PyPi are likely to cover adequately.
Could be -- but if you want to talk support for libraries for obscure purposes, being able to use third-party libraries written in Java or.NET (rather than relying only on CPAN or PyPi) is a clear win; in those cases, Jython and IronPython are compelling.
The right question is not "how many packages are on PyPi" -- that's like measuring SourceForge only by the number of projects hosted there, and we both have an idea of the percentage of crap.
The right question to ask is this: Can I find what I need on PyPi?
In real-world situations, the answer is overwhelmingly yes.
Even if CPAN was the only argument for using perl (which it isn't), it would still be one hell of an argument.
Not when the opposition has an equivalent tool/repository, at which point it's just par for the course. See PyPi and EasyInstall/Setuptools.
(As for good high-level Python XML toolkits, I'm personally fond of lxml, but there are plenty 'round; if you couldn't find one, it's because you didn't know where to look).
That's part of the problem, sure, but certainly not anything close to the whole picture.
If the financial industry had used more responsible risk models which recognized the inherent risk of unestablished derivatives, we wouldn't be where we are.
If the financial industry hadn't tried to get as much leverage as it possibly could, and thus (while maximizing sunny-day profits) multiplied its vulnerability, we wouldn't be where we are.
If the financial industry hadn't abandoned the model of holding the loans one originates long-term (and, with it, banks' incentives to make sure its loans would be repaid), we wouldn't be where we are.
If the loans weren't collected into instruments which were (collectively) given unwarranted AAA ratings, we wouldn't be where we are.
There's a big house of cards, and picking out only one element to put all the blame there is hardly appropriate.
It was a government mandate to put people who couldn't afford houses into houses.
You mean a government mandate to give mortgages at the same rates to people who met the same criteria, thereby preventing discrimination which was previously rampant.
That's a perfectly fine idea; that the banks failed to implement it correctly (by beefing up and enforcing their lending criteria) by no means makes this a failure caused by excessive government regulation.
SO? how can you not regret it if you didn't go to the other school, your school fails logic.
I could regret it if I saw things I was missing out on in life because I didn't have those contacts. I don't. (As an aside, your school fails grammar).
Contacts from school got me my first job working next door to big-name kernel hackers Paul Mundt and Robert Love. Sure, I had to do some work to get to know the right people to make those contacts -- where at a more prestigious school they might have come free with the partying -- but I'm in a pretty happy place right now, and I didn't end up saddled with $100K of educational loans getting there.
Like anything else, college is what you make of it. A decent state university, even without a big name, provides a fine education if one takes advantage of what it has to offer; one just needs to be more on top of things by way of networking than would necessarily be the case elsewhere.
(I speak from experience, having gone to one of the better schools in the CSU system -- while another school I was considering certainly had more big-name appeal, faculty at the CSU school deigned to give me the time of day when touring as a prospective student; my decision was made between that and economic factors, and I've not regretted it once).
That's not an example of a school failing to challenge a student. That's an example of a lazy student. Maybe he's a smart slacker, but at the end of the day, he's still just a slacker. What the hell does it matter if he's smart if he won't apply himself?
Depends on what the student is doing when not at school, of course.
If he's off writing software (or a novel), or doing original research, everyone involved is far better off with him not being there.
Even when young, there are more things in life than school, and some of them can be productive. We already know this student is a corner case due to his unusual attendance behavior (and ability to ace the quizzes and tests well enough without having been in class to make up for missed homework); why assume that this is the only respect in which such is so?
Like the linux kernel developers are any better...every OS maker is greedy about increased CPU power. I first ran Linux in 1995 and it isn't that much faster now.
Given that the Linux kernel is used in embedded systems with a tiny fraction of your desktop's RAM and CPU power, I'd call it pretty darned safe that the kernel isn't your problem. It's gotten somewhat bigger -- which is why 2.2 and 2.4 kernels are still in use in smaller environments -- but on any system with over 100MB of RAM, you're not going to notice.
Now, if you want to complain about application developers taking advantage of hardware resources (inclusive of the GNOME and KDE folks, browser developers, and the like), feel free.
Good point. If Mister Professor of Islamic and Arabic studies says the transcript is incorrect then he can provide ones he asserts is correct.
Ehh, did you read the quote? The passages in question weren't definitively comprehensible -- meaning no clear translation for those passages is possible.
2. gets his hands on the keyfob - more like sitting near you at a restaurant/bus/train/airpl
No, really, hands. You don't transmit the private key over wireless, of course, just do challenge-response.
And if the folks building this thing do their jobs right, it won't be possible to clone even then without (1) expensive equipment and people able to defeat the tamperproofing, and (2) destroying the device being inspected.
That's just regular tamperproofing: Put it in an enclosure constructed such that its contents are destroyed on any attempt to open it.
I'm not saying that it's an easy problem, necessarily... but there are plenty of folks who've done it, and there are standards which folks claiming to have implemented such a thing can be tested against. See FIPS 140-1.
What they are claiming is not that the key can't be extracted from transmissions- a relatively humdrum requirement- but rather that unlimited physical access to the device cannot reveal the key, which I find dubious in the extreme.
My mom attended a litigation support conference where NSA actually claimed to be able to read a drive's contents after SEVENTEEN zero overwrites.
Along those lines, I once knew a professor who claimed that the NSA was doing automated keyword scanning on the national phone system in the late seventies. There's quite a lot of uncertainty about just what their capabilities are and aren't... and presumably they like it that way.
Then why doesn't someone use the information in those papers to do just that and win this challenge?
Because it's not worth their time, and they can't justify it to the employer or institution that owns the equipment they'd need to use?
(Not, again, that I'm asserting that this is necessarily winnable with modern hard drives... but the argument that this "challenge" proves anything either way is ridiculous).
Why multiple passes of garbage, rather than just one?
Consider:
0->0 => 0.00 1->0 => 0.05 0->1 => 0.95 1->1 => 1.00 (this is admittedly oversimplified, as the initial state is never really a binary 1 or 0, but rather the result of all prior writes -- but the example here is that each write moves you 95% of the way from your present state to your desired target state).
If you have the sensitivity to distinguish between these four cases, the old data is distinguishable regardless of what the new data is. That's why multiple passes are needed.
That said, I'd urge you to read Gutmann's papers to appreciate any nuances I haven't made clear (ie. why multiple passes of "random" [or, preferably, built-to-purpose] data is superior to multiple passes of zeros). Again, I am not asserting that Gutmann's assumptions are correct with modern hardware -- something I personally doubt -- but I do assert that if they were correct, multiple passes would clearly be needed.
Everything that 'might' happen is a security risk. If you think I'm being an alarmist, then stop thinking about security. It's necessary to talk in such absolutes. Using a random garbage writer is, well, random. With random, there's almost no chance of it happening. On the other hand, using straight zeroes, it's not possible to recover data from a disk full of zeroes at all. No multiple obsessive compulsive garbage writing necessary. Simple, elegant, and true.
You're absolutely right that we're talking big brother paranoid level security -- but if you write straight zeros, and writing a zero makes 1->0.05 and 0->0, it may be possible to tell the two states apart. As binary as the data may be, it's still getting written to a physical medium -- and the Real World lives in analogs. Even were this true, however, writing multiple passes of garbage would prevent an entity able to distinguish 0.00 and 0.01 from being able to determine the media's prior state -- and that's the whole point of this operation. Claiming that writing multiple passes of random garbage (or, better, patterns selected to-purpose -- see the Gutmann method) is somehow worse security than a single pass of zeros is complete bunk; the likely case is that it simply doesn't buy anything worthwhile at all, at a cost of time and electricity.
That said -- absolutely, this isn't a likely attack; if there were a cheap way to make equipment which could read data with that level of precision off of magnetic platters, we'd be using it to make higher-density magnetic platters... and tolerances for how the data is written to those platters is much, much lower today than it was twenty years ago. (Against a twenty-year-old hard drive, I'd expect the chances of someone with a STM and a lot of time to actually be quite good).
"It can't be done" is a little strong: On older (early-1980s) hard drives it probably could be done. Modern drives, less likely. No-disassembly rule, no chance whatsoever.
That said, "industry best practices" is what it is. When I'm wearing my data security hat for a company managing people's medical records, I'm going to advise that we follow whatever accepted standards are for wiping drives; if FIPS says to degauss the drives, we're damned well degaussing the drives. "Nobody ever got fired for choosing IBM" may be a lousy rule for procurement, but "nobody ever got fired for insisting on industry-accepted security practices" is right on the money.
Slashdot Mirror
You're looking at this through the European perspective -- as if the creator's monopoly on their work is a natural right.
Look at it again, as if the natural order of things in for information to be usable without restriction, and copyright is an artificial monopoly created for the sole purpose of benefiting the greater good of the public as a whole.
To be sure, things which are copyrighted may have value to the eventual rightsholder 90 years later -- but if you calculate present value at the time of creation (if you've never taken an accounting class, this determines the amount which would need to be invested, at current interest rates, to yield the same eventual income as the extended monopoly period would grant; this sum effectively represents the amount of economic motivation granted to an author to create their work), the amount of value which the creator receives at the time of creation based on this extended grant of exclusive rights is absolutely minimal. On the other hand, the costs levied on the rest of the economy -- even excluding the unknowns of derivative works which aren't created, public-benefit performances which don't occur, and enhanced breadth of society's culture as a whole based on expanded exposure to knowledge -- are considerable indeed.
See this amicus brief to the Supreme Court challenge of the DMCA, An Economic Analysis of Copyright Law (Landes and Posner), Forever Minus A Day? Some Theory And Empirics of Optimal Copyright (Rufus Pollock), and (for lighter reading) this analysis in the Financial Times.
I agree that shorter terms with an option to renew are desirable, but also hold that the length of renewal should be limited either explicitly or via economic incentives (ie. attaching significant cost for renewal after a reasonable period).
Unlike European copyright law, which is premised on creators' rights, US copyright law is premised on public benefit -- encouraging creation of new works as a first and primary goal, accomplished by means of a temporary, government-provided monopoly by which creators can make a return on their work.
Perpetual copyright leads to economic inefficiencies (in which the cost to the public as a whole vastly outweighs tho benefit to the author and inheritors (if you need me to cite an peer-reviewed analysis to this effect, let me know and I'll dig up a few), to older works being lost because nobody has the rights to reproduce them (or enough economic incentive to do that at the price the present rightholder wishes to charge), and to new works which could leverage the public domain (the "creative commons") not being created.
If you want to argue that 10 years is a bad idea, that's an eminently reasonable position to take. Arguing that copyright should be perpetual, on the other hand, goes against everything US copyright law is based on, and favors a position which would be very much to the detriment of the public, including those who create new works.
No, I'm just explaining why CPAN's huge collection of outdated libraries really doesn't matter to someone deciding between Perl and Python today if they're going to be writing new code.
I pretty much agree with you that the converter approach is unfortunate and unwieldy. On the other hand, having ill-defined changes which may or may not cause breakage without warning between minor releases (which is where Perl seemed to be back before I switched -- obviously your milage varies, and I'm certain this will be fully and completely resolved by Perl 6 with its formal language definition) isn't much fun either.
As I pointed out, part of the point of newer libraries is that they can leverage other modern tools; lxml, for instance, leverages libxml2 heavily, and thus is far from "from scratch", and benefits from all of libxml2's reliability and compliance. (Likewise, its API design borrows heavily from the good ideas of ElementTree, to the point of being backwards-compatible with the same). XML libraries written before libxml2 obviously cannot leverage that effective standard, or (at minimum) have high-level APIs designed with a different low-level implementation in mind.
If we all picked the oldest, most thoroughly battle-tested library that we could possibly use for any purpose, I would be using something like PyDOM when I needed to do DOM work -- and my code would be longer, more complicated and harder to read for it. ElementTree's API style gained traction because it was better -- fewer and more readable lines needed to achieve a desired result; lxml continues that further.
To clarify -- Python 2.6 warns about only those things which the mechanical py2to3 (or whatever they're calling it) code conversion tool can't fix; the bulk of changes will be done programmatically by the translator, no human involvement (other than running the translator, checking in its result and bumping the release number) needed.
Anyhow, 'yall Perl folks don't have much room to talk on this count -- I was bit plenty by backwards incompatibility in a minor Perl interpreter release somewhere between 1998 and 2001 (sorry, don't remember more precisely than that). Python has had a formal language definition and change-control process for quite some time now, and benefitted quite undeniably, even now when backwards-compatible changes are deliberately taken place: Because all syntax changes are known and enumerated (rather than having language behavior defined by the implementation, as was historically the case with Perl), projects such as the mechanical translator are easier to develop and prove correct.
For code with no dependencies, which interacts with no evolving standards, this may be true. For other code, one word: Bitrot.
A library may be perfect in and of itself, but the rest of the world moves on. Ten-year-old code is likely to reinvent wheels which modern code would use 3rd-party libraries to implement, increasing size and decreasing maintainability and debuggability. Ten-year-old code won't use newer interfaces (see ipchains vs iptables, select vs epoll, polling stat() vs inotify() vs dnotify()), won't support newer features (see: XML libraries without XPath), and aren't built with knowledge gained by observing their contemporary competitors. Even SMTP just went through a revision; time passes, the world moves on, and code over time goes bad.
A few reasons which might partially account for the difference I've observed:
Could be -- but if you want to talk support for libraries for obscure purposes, being able to use third-party libraries written in Java or .NET (rather than relying only on CPAN or PyPi) is a clear win; in those cases, Jython and IronPython are compelling.
The right question is not "how many packages are on PyPi" -- that's like measuring SourceForge only by the number of projects hosted there, and we both have an idea of the percentage of crap.
The right question to ask is this: Can I find what I need on PyPi?
In real-world situations, the answer is overwhelmingly yes.
Not when the opposition has an equivalent tool/repository, at which point it's just par for the course. See PyPi and EasyInstall/Setuptools.
(As for good high-level Python XML toolkits, I'm personally fond of lxml, but there are plenty 'round; if you couldn't find one, it's because you didn't know where to look).
That's part of the problem, sure, but certainly not anything close to the whole picture.
If the financial industry had used more responsible risk models which recognized the inherent risk of unestablished derivatives, we wouldn't be where we are.
If the financial industry hadn't tried to get as much leverage as it possibly could, and thus (while maximizing sunny-day profits) multiplied its vulnerability, we wouldn't be where we are.
If the financial industry hadn't abandoned the model of holding the loans one originates long-term (and, with it, banks' incentives to make sure its loans would be repaid), we wouldn't be where we are.
If the loans weren't collected into instruments which were (collectively) given unwarranted AAA ratings, we wouldn't be where we are.
There's a big house of cards, and picking out only one element to put all the blame there is hardly appropriate.
You mean a government mandate to give mortgages at the same rates to people who met the same criteria, thereby preventing discrimination which was previously rampant.
That's a perfectly fine idea; that the banks failed to implement it correctly (by beefing up and enforcing their lending criteria) by no means makes this a failure caused by excessive government regulation.
The topic is the userbase of the development toolchain, not the particular target.
A cross-platform toolchain is, all things being equal, preferable to a single-platform one, and likely to have a wider already-familiar userbase.
Duh.
I could regret it if I saw things I was missing out on in life because I didn't have those contacts. I don't. (As an aside, your school fails grammar).
Contacts from school got me my first job working next door to big-name kernel hackers Paul Mundt and Robert Love. Sure, I had to do some work to get to know the right people to make those contacts -- where at a more prestigious school they might have come free with the partying -- but I'm in a pretty happy place right now, and I didn't end up saddled with $100K of educational loans getting there.
Like anything else, college is what you make of it. A decent state university, even without a big name, provides a fine education if one takes advantage of what it has to offer; one just needs to be more on top of things by way of networking than would necessarily be the case elsewhere.
(I speak from experience, having gone to one of the better schools in the CSU system -- while another school I was considering certainly had more big-name appeal, faculty at the CSU school deigned to give me the time of day when touring as a prospective student; my decision was made between that and economic factors, and I've not regretted it once).
Depends on what the student is doing when not at school, of course.
If he's off writing software (or a novel), or doing original research, everyone involved is far better off with him not being there.
Even when young, there are more things in life than school, and some of them can be productive. We already know this student is a corner case due to his unusual attendance behavior (and ability to ace the quizzes and tests well enough without having been in class to make up for missed homework); why assume that this is the only respect in which such is so?
Given that the Linux kernel is used in embedded systems with a tiny fraction of your desktop's RAM and CPU power, I'd call it pretty darned safe that the kernel isn't your problem. It's gotten somewhat bigger -- which is why 2.2 and 2.4 kernels are still in use in smaller environments -- but on any system with over 100MB of RAM, you're not going to notice.
Now, if you want to complain about application developers taking advantage of hardware resources (inclusive of the GNOME and KDE folks, browser developers, and the like), feel free.
Ehh, did you read the quote? The passages in question weren't definitively comprehensible -- meaning no clear translation for those passages is possible.
No, really, hands. You don't transmit the private key over wireless, of course, just do challenge-response.
And if the folks building this thing do their jobs right, it won't be possible to clone even then without (1) expensive equipment and people able to defeat the tamperproofing, and (2) destroying the device being inspected.
That's just regular tamperproofing: Put it in an enclosure constructed such that its contents are destroyed on any attempt to open it.
I'm not saying that it's an easy problem, necessarily... but there are plenty of folks who've done it, and there are standards which folks claiming to have implemented such a thing can be tested against. See FIPS 140-1.
Has anyone cloned a Crypto iButton?
Along those lines, I once knew a professor who claimed that the NSA was doing automated keyword scanning on the national phone system in the late seventies. There's quite a lot of uncertainty about just what their capabilities are and aren't... and presumably they like it that way.
Because it's not worth their time, and they can't justify it to the employer or institution that owns the equipment they'd need to use?
(Not, again, that I'm asserting that this is necessarily winnable with modern hard drives... but the argument that this "challenge" proves anything either way is ridiculous).
Consider:
0->0 => 0.00
1->0 => 0.05
0->1 => 0.95
1->1 => 1.00
(this is admittedly oversimplified, as the initial state is never really a binary 1 or 0, but rather the result of all prior writes -- but the example here is that each write moves you 95% of the way from your present state to your desired target state).
If you have the sensitivity to distinguish between these four cases, the old data is distinguishable regardless of what the new data is. That's why multiple passes are needed.
That said, I'd urge you to read Gutmann's papers to appreciate any nuances I haven't made clear (ie. why multiple passes of "random" [or, preferably, built-to-purpose] data is superior to multiple passes of zeros). Again, I am not asserting that Gutmann's assumptions are correct with modern hardware -- something I personally doubt -- but I do assert that if they were correct, multiple passes would clearly be needed.
You're absolutely right that we're talking big brother paranoid level security -- but if you write straight zeros, and writing a zero makes 1->0.05 and 0->0, it may be possible to tell the two states apart. As binary as the data may be, it's still getting written to a physical medium -- and the Real World lives in analogs. Even were this true, however, writing multiple passes of garbage would prevent an entity able to distinguish 0.00 and 0.01 from being able to determine the media's prior state -- and that's the whole point of this operation. Claiming that writing multiple passes of random garbage (or, better, patterns selected to-purpose -- see the Gutmann method) is somehow worse security than a single pass of zeros is complete bunk; the likely case is that it simply doesn't buy anything worthwhile at all, at a cost of time and electricity.
That said -- absolutely, this isn't a likely attack; if there were a cheap way to make equipment which could read data with that level of precision off of magnetic platters, we'd be using it to make higher-density magnetic platters... and tolerances for how the data is written to those platters is much, much lower today than it was twenty years ago. (Against a twenty-year-old hard drive, I'd expect the chances of someone with a STM and a lot of time to actually be quite good).
"It can't be done" is a little strong: On older (early-1980s) hard drives it probably could be done. Modern drives, less likely. No-disassembly rule, no chance whatsoever.
That said, "industry best practices" is what it is. When I'm wearing my data security hat for a company managing people's medical records, I'm going to advise that we follow whatever accepted standards are for wiping drives; if FIPS says to degauss the drives, we're damned well degaussing the drives. "Nobody ever got fired for choosing IBM" may be a lousy rule for procurement, but "nobody ever got fired for insisting on industry-accepted security practices" is right on the money.