Does anyone remember "Name That Tune"? Even watching a few loser minutes it was evident that the best contestants carried around many thousands of tunes in their wetware, most of which could be summoned in two and a half to four notes. What's difference does an iPod prosthesis make?
I had three failed drives back in the heyday of Fujitsu timebombs and IBM deathstars. One we had to send off to data recovery because it failed while it was being reconnected to my backup server. This is true. It was the first time the machine had been power cycled in six months, and when restarted in the location where I had it connected to my backup server, it never spun up. Most of the data from that drive was smeered around the network in various forms and locations, but it was simpler (though somewhat expensive) just to send if off for recovery.
A friend brought me a drive that wouldn't spin up that I managed to spin up just barely long enough to recover the data by power cycling a number of times with different power supplies. The death rattle was noticably increasing as I raced to copy off the files. There was only a few gigs that mattered so I won the race by a few minutes.
The third drive really wanted to spin up. You could feel the platter quiver momentarily on each power cycle. I put it in the fridge wrapped in a thick dishtowel for about four hours. When I took it out of the fridge I had to race to get it installed in the rescue machine before it warmed up too much. It started up. Woohoo! Then it was fine as far as I could tell, but it never started again after that.
I also had a few other Fujitsu's that were rotated out of important functions before they predictably failed. And there was one deathstar drive I installed in a friends machine just before it became widespread knowledge that deathstars sucked, and that drive has never so much as burped. Just as dangerous as the Fuji bombs, a little less predictable.
We had one drive at work that failed within 30 days of being installed. Wasn't either type of notoriously crappy drive, it was just a lemon.
Since that batch in rapid succession, I haven't witnessed a drive failure in two years over some two dozen spindles. Some of those drives in firewalls were from the old less than 10GB era. They made so much spindle noise we recently decided on a mercy killing.
Here's hoping the Seagate 7200.7s are one of the good batches. I've got a lot of them now.
Every piece I've read by Schneier over the past few years hammers on the same theme: software is fallible, no system ever works that fails to retain a phalanx of expensive security wonks. He's more right than wrong, but he sometimes delivers injustice to the details.
Let's think back a ways, a long ways to the original tabulating machine.
Counting votes is not rocket science. If ever there was a category of software that could be substantially more correct rather than less correct, it would have to counting. If, after 100 years and trillions of dollars, we still can't build a machine that counts correctly, let's fold up shop and go home.
Now, if the source code remains concealed, it certainly becomes much easier to build a machine that does not count correctly, but that's not a software failure and let's not blame that on an inherent imperfection of software.
Ideas similar to yours are easy to come up with, yet none have ever been shown practical
The only argument I see against the practicality of this solution is the point above, which is circular. An argument which depends upon a circular argument is also circular.
Armies of worm riddled broadband-connected Windows boxes
In my opinion, this is a strength of hashcash rather than a defect. Consider the ratios. I send maybe a few hundred e-mails a year to strangers. Each spammer wishes to send hundreds of millions. There aren't actually enough zombies to go around. The key is to allow the recipient side to adaptively adjust the amount of postage demanded based on multiple factors until there is no free lunch remaining for the spam kings.
Sorry dude, your spam response form has only served to add to the noise floor, not reduce it.
Furthermore, the whole premise of the spam form response is that a huge design mistake made by Unix hackers of old in the design of the e-mail infrastructure is beyond our collective willpower to fix.
I say: grab and backbone and deal with it. I'm embarrassed to be a member of such a pansy industry.
Re:Acoustic couplers were only 110 baud
on
Firefox 1.0 Released
·
· Score: 2, Interesting
You appreciated the breviety of the UNIX command line and the short command names (ls, cp, mv, ln, rm).
There was a discussion here recently about how buffer manipulations in C are inherently unsafe. What people forget is that many of the original C string functions didn't even take arguments for buffer protection. That historical oddity resulted from 110 baud accoustic modems connected to development systems equally capable. Back then, you appreciated not having to add extra parameters to function calls because it made life bearable in other dimensions.
I'd like to see a competition for the best engineered Java program written within a 24 hour time period over a 110 baud glass TTY to a PDP8. After reading the code that results, perhaps more people would appreciate that many historically crappy (and obscure) coding practices did not originate as conceptual errors.
How about a 32 lane PCI-E implementation with no lames or blinks devoted to Doom III? 40Gbps backplane, bidirectional.
http://arstechnica.com/articles/paedia/hardware/ pc ie.ars/5 PCIe's bandwidth gains over PCI are considerable. A single lane is capable of transmitting 2.5Gbps in each direction, simultaneously.
We fix things one problem at a time. We can't do anything about general input verification, but we can help sloppy programmers avoid problems with buffer overflows and memory allocation by automating it.
This is good. Once the sloppy programmer is freed of the burden of buffer allocation, they have more time to be sloppy about everything else. That can't possibly lead to more problems.
If there were programming languages which did not permit programmers to write constructs leading to buffer overflows, this debate would be long over. What these languages do is prevent certain consequences of incorrectly written programs. The fact that every car now comes with airbags and seatbelts does not eliminate the debate about whether driving skills should have been better in the first place.
The problems posed by C are not unique to programming languages. In mathematics, if you multiply both sides of an inequality by a non-positive number, or you divice both sides of an equality by zero, or you sum a divergent series to a fixed value, you have effectively "bombed out" your entire construct, and anything at all can thence be proven.
In a mathematical proof, every logical step must be properly guarded within its bounds of validity. This is no different that the discipline required to write correct programs in C. The validity conditions for a buffer manipulation in C are really quite simple. As a point of comparison, the validity conditions for escaping regular expressions or SQL statements or safe shell commands in PHP are much less straightforward. Where is the programming language that prevents those mistakes?
My position is that if a programmer can't manage to correctly handle the rather trivial validity conditions on buffer manipulation in C, the programmer will have difficulty in correctly handling the validity conditions on any other program construct. My position is that every statement written in a program needs to be written with consideration for its bounds of validity. I don't believe there are any magic languages out there that will save us from having to think so hard, certainly not if correctness is our ultimate goal.
If a tool is rarely used properly, this is often a sign that the tool sucks, or at least that it's too hard to use properly.
Adding buffer overflow checks to a programming language does not turn an incorrect program into a correct program. It turns an incorrect program into an incorrect program with less of a license to kill.
At the same time, there are many programmers out there who never make a bounds mistake in any language.
When I program in a bounds checked language, I don't sigh inwardly to myself "oh, I can program much faster now". I continue to put exactly as much work into the program as required to make my C code correct.
In the SCO vs Linux saga, SCO proposed to prove that Linux stole code out of SCO by demonstrating that the two codebases contain identical constructs.
What was rarely pointed out in the tedious debate surrounding this is that locating identical constructs does not prove that either project copied the other. There is a second step required to make this determination: that there does not exist an shared antecedant from which *both* projects have copied.
In the case of SCO vs Linux, there could well have been code that ultimately ended up under the BSD license from which both projects were later inspired. The BSD codebase goes back a long way.
The corollory to Sturgeon's law that 90% of everything is crap, Sturgeon's unstated corrolory, is that the other 10% is copied vigorously at every opportunity.
There used to be a joke about the thesis advisor who declares "your thesis is both good and original, unfortunately, the good part is not original and the original part is not good".
The author fails to point out the direct relationship between a distribution that sets out to conquer hell and the requirement for the participants to invest in a few pairs of asbestos underwear.
He also fails to point out the leadership qualities that OpenBSD has brought to the BSD buffet: OpenSSH, Darren Reed's packet filter, and soon the Via C5J Esther processor with user-space crypto acceleration, whose design was influenced by activities within the OpenBSD camp.
The author also throws a lot of unnecessary FUD at the stabalization of the FreeBSD 5.x series. The kinds of people who choose to deploy OpenBSD for their firewalls and FreeBSD for their application servers don't sit around and quaver about a few drops of -stable holy water. If you aren't prepared to read the lists, use 4-latest. If you are prepared to read the lists, you can decide for yourself whether the remaining troublespots in 5.x are a problem or not for your intended application.
You certainly are right about the instantaneous BS detector. You set mine off several times with your other comments.
You haven't even managed to keep your own arguments on the same page. At one point you cite the memorization of a phone book as evidence about the chunk-scale of human intellect, apparently forgetting that computers already exceed this extreme data point on human performance by a rough factor of a billion. Phone numbers are in no way the "chunks" of human processing that make human processing interesting.
The failure of computer hardware to perform "random access" information assessment is not a property of digital hardware, Wogger Penrose notwithstanding. It's a property of a class of algorithms appropriate to a scale of computation which we are rapidly exceeding.
We already have classes of algorithms which perform exceptionally well at random access classification: neural networks and statistical models encoded using hashing techniques. What seems to be apparent is that the human brain encodes information at a higher level of dimensionality than our toy neural networks.
I regard the Penrose algorithm as entirely circular. I'm altogether unimpressed with the creativity of the human brain. Open your eyes. Every day I witness hundreds of computational tasks orchestrated by the human brain that humans do badly or barely at all.
For example, the driver who makes three dangerous S-style lane changes from behind to pass you and gain 50 yards of progress before ass kissing the next obstruction and then coming to a grinding halt at the next red light, which you could see was red half a block back. Meanwhile, having coasted down to 10mph and arrives by good planning at the intersection just as the light changes green, the "laggard" car comes out the other side 20 yards ahead at half the gas consumption, and zero wear-and-tear on his break linings.
Then there are the large number of cases concerning how rarely most people even recognize the incompetence of human intellect all around them.
Of course, if you conceive of yourself as off-the-scale brilliant at the pinnacle of human intellectual achievement (creativity is usually trotted out) as Wogger does, then of course you need quantum mechanics to explain this.
If Wogger really were that bright, he might have noticed the circularity of his own argument. We need quantum mechanics to achieve this level of competence? I think not.
How is this model any different than the history of Linux kernel development? The packet filter portion of Linux comes to mind immediately.
It's not always a bad thing to strive toward production ready code. It can be a good and necessary counterbalance to the "think forever" reflex that takes hold in projects that go too far in the other direction.
Concerning the tone of the interview, I wouldn't be at all surprised that the best source-code revision system comes from a Theo-like development camp. Some projects can handle a "let's all get along and not say anything too combative" and some projects do much better at the other extreme.
Personally, I'll download my firewall, my filesystem, and my source control system from the crabbiest ubertard I can find.
That's not what the theory of capitalism says. Capitalism says that capital follows need, and corporations had better keep their feet moving if they don't want their bottom line to look like DeCaprio's private parts after he plunged.
It's corporatism not capitalism that says "try to keep the dull consumer buying what they don't need anyway".
A modest Pentium-M with silent cooling would serve the needs of most people far better than any Pentium-IV, complete with miniature nuclear cooling tower.
From where we are right now, a mad rush to 10GHz computing is not the most efficient use of available capital, a no amount of duping the average consumer can change that fact.
My view is that it was a sad day for humanity, democracy, and freedom of expression that ordinary, long established words from the English language (or any other) should have been subject to trademark rights in the first place.
Xerox should be trademarked. Kleenex should be trademarked. Pepsi should be trademarked. Coke should NOT be trademarked. McDonald's should NOT be trademarked. Fedex should be trademarked. Nike is debatable (obscure Greek mythology). Clorox should be trademarked. Lexmark should be trademarked. Apple should NOT be trademarked.
I think we should accept reality and just get rid of trademark registration altogether except for xemes(TM) containing the letter x.
New item today on The Wedgie that the VIA Esther C5J has now been branded as the C7. This core has accelerated instructions for AES, RSA, hardware entropy, and various SHA standards. It should run fanless at around 1GHz and outperform a P4 as a cypto NAT firewall.
http://www.monkey.org/openbsd/archive/misc/0402/ ms g00112.html
Once upon a time Theo de Raadt wrote:
>Got a couple figures on AES performance... the cool one at the bottom. > >type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes >aes-128-cbc 15985.10k 16924.93k 17238.12k 17319.74k 17339.74k > 1.6GHz amd64 in 32bit mode > >aes-128-cbc 13323.36k 14403.55k 13225.65k 14529.80k 14654.16k > P3/1GHz > >aes-128-cbc 13090.59k 51065.12k 174593.45k 426600.92k 735548.02k > VIA C3 with the xcrypt-* instructions. This is using a new diff > I have written which makes OpenSSL directly use the cpu instructions > if they are available, right in userland, without having to call to >/dev/crypto > >Two things are apparent. First, this CPU feature is really cool. >Second, the OpenSSL glue above crypto operation has pathetically high >overhead...
I vaguely recall a claim on the VIA site which I can't find right now that the Montgomery multiplier will perform one hundred 1024 bit RSA setups per second.
AND this chip supports NX.
I'm waiting until spring to replace my aging P200 firewalls. If those benchmarks prove out, I'll have the better part of a decade to seek out the next replacement.
Jump off your bike mid-ride, wander into the bush and pinch a couple of loaves. Then you can ride above your average speed all the way home.
Your 10% number boggles the mind. More likely the challenge was order of magnitude (factor of ten). Generally estimating within 20% is possible if you know mostly the right parameters and you estimate the arithmetic results.
Imagine if he could nail 10% all of the time. NASA would be on the phone asking him "for a chunk of foam travelling at 779 ft/s that impacts the wing of a shuttle on launch, how heavy would the foam have to be to cause lethal structural damage?"
Supercomputers can't answer these questions to within ten percent.
The only exception would have to be Sturgeon's law: 90% of everything (e.g. slashdot posts) is junk. Never fails in my experience.
Completely wrong. There are different scales available for dealing with different kinds of ignorance. I tried very hard to learn as little as possible about British royal succession with great success, spoiled only by the fabuluous movie "Henry V". Despite my highly cultivated ignorance, I'd have to be a complete moron not to know that there wasn't much of a British succession in the dark ages, and going back further in time there were a lot of Romans milling about, a lot of bridges and aqueducts, and a distinct shortage of royal castles in London.
Likewise, there weren't many presidents in America (of European descent) prior to 1492. There are always scales of knowledge available for a casting a wider net.
If you want a question worth complaining about: how many joules/kilogram are available from the isomeric decay of Hafnium 2m?
Einstein provided an upper bound, but it's very difficult to apply to this problem.
If Fabian is talking to the world at large, he should back up his complaints with constructive proposals. It's a complete waste of bandwidth to throw around a lot of complaints without putting those complaints into a context of how life might be someday improved. I read Fabian's original screed without learning anything solid I could take away as a perspective on SQL's weaknesses. I didn't notice a link to the REL project last time around, but this time when I looked at REL as least I came away with some concepts about how SQL's syntax is less than ideal. However, I'm not yet convinced that syntax matters as much as Fabian would like me to believe and I as far as I read the REL documentation, I didn't come away with any semantic insights.
BTW some people on this thread have argued that optimization is targetted at the semantics expressed by the syntax. This is far from being necessarily true: it's quite possible to a language to choose different optimizations for two expressions with semantic equivalence because there is a *cultural* difference in the intent and expectation of those expressions (e.g. assumptions about whether many or few results are expected). The "unless" syntax in Perl falls into this category of *cultural* semantics: the predicate is expected to evaluate 'true' for the productive execution path of the application.
As for your colleague, you provided her with a technical opinion on a project where it probably mattered to her whether she achieved a successful outcome. If you showed up for a job interview at my company and commented "isn't it OK to tell people their projects are going to fail without offering constructive advice" you'd be crossed off the list on the spot. It's useful to provide that advice if the time and place does not exist for something better, but it's also a sure sign of a bad attitude that you don't hold yourself to higher standards of contribution.
Which paragraph contributes more to the world long term: my blather about Fabian in my first paragraph, or my pointed observation about cultural effects that break down an abstraction barrier between syntax and semantics concerning optimization strategies in my second paragraph?
It appears that MS has also patented loser magnets: patents so bad that no one notices the patents in their portfolio filled with live ammunition pointed right at their head.
I have no problem with people spending money to investigate this system, as long as no claims are made whatsoever on the basis of "excess" heat. Wake me up and report the excess heat when the "excess" heat arrives at a steam turbine.
If a bunch of nuclear scientists go out for a dinner together, do the funds tended *ever* amount to l'addition?
Exotic isotopes swimming in your post-fusion afterglow are worth reporting. Reporting that you can't add up your pay stub is not.
Slashdot Mirror
Does anyone remember "Name That Tune"? Even watching a few loser minutes it was evident that the best contestants carried around many thousands of tunes in their wetware, most of which could be summoned in two and a half to four notes. What's difference does an iPod prosthesis make?
Why did the tone of that article remind me of all the spams I get promoting one stock or another? I rock. You suck. It's just that simple.
I had three failed drives back in the heyday of Fujitsu timebombs and IBM deathstars. One we had to send off to data recovery because it failed while it was being reconnected to my backup server. This is true. It was the first time the machine had been power cycled in six months, and when restarted in the location where I had it connected to my backup server, it never spun up. Most of the data from that drive was smeered around the network in various forms and locations, but it was simpler (though somewhat expensive) just to send if off for recovery.
A friend brought me a drive that wouldn't spin up that I managed to spin up just barely long enough to recover the data by power cycling a number of times with different power supplies. The death rattle was noticably increasing as I raced to copy off the files. There was only a few gigs that mattered so I won the race by a few minutes.
The third drive really wanted to spin up. You could feel the platter quiver momentarily on each power cycle. I put it in the fridge wrapped in a thick dishtowel for about four hours. When I took it out of the fridge I had to race to get it installed in the rescue machine before it warmed up too much. It started up. Woohoo! Then it was fine as far as I could tell, but it never started again after that.
I also had a few other Fujitsu's that were rotated out of important functions before they predictably failed. And there was one deathstar drive I installed in a friends machine just before it became widespread knowledge that deathstars sucked, and that drive has never so much as burped. Just as dangerous as the Fuji bombs, a little less predictable.
We had one drive at work that failed within 30 days of being installed. Wasn't either type of notoriously crappy drive, it was just a lemon.
Since that batch in rapid succession, I haven't witnessed a drive failure in two years over some two dozen spindles. Some of those drives in firewalls were from the old less than 10GB era. They made so much spindle noise we recently decided on a mercy killing.
Here's hoping the Seagate 7200.7s are one of the good batches. I've got a lot of them now.
Every piece I've read by Schneier over the past few years hammers on the same theme: software is fallible, no system ever works that fails to retain a phalanx of expensive security wonks. He's more right than wrong, but he sometimes delivers injustice to the details.
Let's think back a ways, a long ways to the original tabulating machine.
Counting votes is not rocket science. If ever there was a category of software that could be substantially more correct rather than less correct, it would have to counting. If, after 100 years and trillions of dollars, we still can't build a machine that counts correctly, let's fold up shop and go home.
Now, if the source code remains concealed, it certainly becomes much easier to build a machine that does not count correctly, but that's not a software failure and let's not blame that on an inherent imperfection of software.
This is extremely stupid.
If it works, users of email will put up with it.
Ideas similar to yours are easy to come up with, yet none have ever been shown practical
The only argument I see against the practicality of this solution is the point above, which is circular. An argument which depends upon a circular argument is also circular.
Armies of worm riddled broadband-connected Windows boxes
In my opinion, this is a strength of hashcash rather than a defect. Consider the ratios. I send maybe a few hundred e-mails a year to strangers. Each spammer wishes to send hundreds of millions. There aren't actually enough zombies to go around. The key is to allow the recipient side to adaptively adjust the amount of postage demanded based on multiple factors until there is no free lunch remaining for the spam kings.
Sorry dude, your spam response form has only served to add to the noise floor, not reduce it.
Furthermore, the whole premise of the spam form response is that a huge design mistake made by Unix hackers of old in the design of the e-mail infrastructure is beyond our collective willpower to fix.
I say: grab and backbone and deal with it. I'm embarrassed to be a member of such a pansy industry.
You appreciated the breviety of the UNIX command line and the short command names (ls, cp, mv, ln, rm).
There was a discussion here recently about how buffer manipulations in C are inherently unsafe. What people forget is that many of the original C string functions didn't even take arguments for buffer protection. That historical oddity resulted from 110 baud accoustic modems connected to development systems equally capable. Back then, you appreciated not having to add extra parameters to function calls because it made life bearable in other dimensions.
I'd like to see a competition for the best engineered Java program written within a 24 hour time period over a 110 baud glass TTY to a PDP8. After reading the code that results, perhaps more people would appreciate that many historically crappy (and obscure) coding practices did not originate as conceptual errors.
How about a 32 lane PCI-E implementation with no lames or blinks devoted to Doom III? 40Gbps backplane, bidirectional.
http://arstechnica.com/articles/paedia/hardware
PCIe's bandwidth gains over PCI are considerable. A single lane is capable of transmitting 2.5Gbps in each direction, simultaneously.
We fix things one problem at a time. We can't do anything about general input verification, but we can help sloppy programmers avoid problems with buffer overflows and memory allocation by automating it.
This is good. Once the sloppy programmer is freed of the burden of buffer allocation, they have more time to be sloppy about everything else. That can't possibly lead to more problems.
If there were programming languages which did not permit programmers to write constructs leading to buffer overflows, this debate would be long over. What these languages do is prevent certain consequences of incorrectly written programs. The fact that every car now comes with airbags and seatbelts does not eliminate the debate about whether driving skills should have been better in the first place.
The problems posed by C are not unique to programming languages. In mathematics, if you multiply both sides of an inequality by a non-positive number, or you divice both sides of an equality by zero, or you sum a divergent series to a fixed value, you have effectively "bombed out" your entire construct, and anything at all can thence be proven.
In a mathematical proof, every logical step must be properly guarded within its bounds of validity. This is no different that the discipline required to write correct programs in C. The validity conditions for a buffer manipulation in C are really quite simple. As a point of comparison, the validity conditions for escaping regular expressions or SQL statements or safe shell commands in PHP are much less straightforward. Where is the programming language that prevents those mistakes?
My position is that if a programmer can't manage to correctly handle the rather trivial validity conditions on buffer manipulation in C, the programmer will have difficulty in correctly handling the validity conditions on any other program construct. My position is that every statement written in a program needs to be written with consideration for its bounds of validity. I don't believe there are any magic languages out there that will save us from having to think so hard, certainly not if correctness is our ultimate goal.
If a tool is rarely used properly, this is often a sign that the tool sucks, or at least that it's too hard to use properly.
Adding buffer overflow checks to a programming language does not turn an incorrect program into a correct program. It turns an incorrect program into an incorrect program with less of a license to kill.
At the same time, there are many programmers out there who never make a bounds mistake in any language.
When I program in a bounds checked language, I don't sigh inwardly to myself "oh, I can program much faster now". I continue to put exactly as much work into the program as required to make my C code correct.
OK, the simple place to start in assessing your claims was to google for "NPTL Scheduler Activations".
l
The first link that comes up has an interesting disclaimer at the top:
http://people.redhat.com/drepper/glibcthreads.htm
I could continue my investigation by googling for "Ulrich Drepper", but I'm sure that would only lead to more interesting disclaimers.
In the SCO vs Linux saga, SCO proposed to prove that Linux stole code out of SCO by demonstrating that the two codebases contain identical constructs.
What was rarely pointed out in the tedious debate surrounding this is that locating identical constructs does not prove that either project copied the other. There is a second step required to make this determination: that there does not exist an shared antecedant from which *both* projects have copied.
In the case of SCO vs Linux, there could well have been code that ultimately ended up under the BSD license from which both projects were later inspired. The BSD codebase goes back a long way.
The corollory to Sturgeon's law that 90% of everything is crap, Sturgeon's unstated corrolory, is that the other 10% is copied vigorously at every opportunity.
There used to be a joke about the thesis advisor who declares "your thesis is both good and original, unfortunately, the good part is not original and the original part is not good".
Thus it ever was.
>>
How could it be _a lot higher_ than 100%?
The author fails to point out the direct relationship between a distribution that sets out to conquer hell and the requirement for the participants to invest in a few pairs of asbestos underwear.
He also fails to point out the leadership qualities that OpenBSD has brought to the BSD buffet: OpenSSH, Darren Reed's packet filter, and soon the Via C5J Esther processor with user-space crypto acceleration, whose design was influenced by activities within the OpenBSD camp.
The author also throws a lot of unnecessary FUD at the stabalization of the FreeBSD 5.x series. The kinds of people who choose to deploy OpenBSD for their firewalls and FreeBSD for their application servers don't sit around and quaver about a few drops of -stable holy water. If you aren't prepared to read the lists, use 4-latest. If you are prepared to read the lists, you can decide for yourself whether the remaining troublespots in 5.x are a problem or not for your intended application.
You certainly are right about the instantaneous BS detector. You set mine off several times with your other comments.
You haven't even managed to keep your own arguments on the same page. At one point you cite the memorization of a phone book as evidence about the chunk-scale of human intellect, apparently forgetting that computers already exceed this extreme data point on human performance by a rough factor of a billion. Phone numbers are in no way the "chunks" of human processing that make human processing interesting.
The failure of computer hardware to perform "random access" information assessment is not a property of digital hardware, Wogger Penrose notwithstanding. It's a property of a class of algorithms appropriate to a scale of computation which we are rapidly exceeding.
We already have classes of algorithms which perform exceptionally well at random access classification: neural networks and statistical models encoded using hashing techniques. What seems to be apparent is that the human brain encodes information at a higher level of dimensionality than our toy neural networks.
I regard the Penrose algorithm as entirely circular. I'm altogether unimpressed with the creativity of the human brain. Open your eyes. Every day I witness hundreds of computational tasks orchestrated by the human brain that humans do badly or barely at all.
For example, the driver who makes three dangerous S-style lane changes from behind to pass you and gain 50 yards of progress before ass kissing the next obstruction and then coming to a grinding halt at the next red light, which you could see was red half a block back. Meanwhile, having coasted down to 10mph and arrives by good planning at the intersection just as the light changes green, the "laggard" car comes out the other side 20 yards ahead at half the gas consumption, and zero wear-and-tear on his break linings.
Then there are the large number of cases concerning how rarely most people even recognize the incompetence of human intellect all around them.
Of course, if you conceive of yourself as off-the-scale brilliant at the pinnacle of human intellectual achievement (creativity is usually trotted out) as Wogger does, then of course you need quantum mechanics to explain this.
If Wogger really were that bright, he might have noticed the circularity of his own argument. We need quantum mechanics to achieve this level of competence? I think not.
How is this model any different than the history of Linux kernel development? The packet filter portion of Linux comes to mind immediately.
It's not always a bad thing to strive toward production ready code. It can be a good and necessary counterbalance to the "think forever" reflex that takes hold in projects that go too far in the other direction.
Concerning the tone of the interview, I wouldn't be at all surprised that the best source-code revision system comes from a Theo-like development camp. Some projects can handle a "let's all get along and not say anything too combative" and some projects do much better at the other extreme.
Personally, I'll download my firewall, my filesystem, and my source control system from the crabbiest ubertard I can find.
That's not what the theory of capitalism says. Capitalism says that capital follows need, and corporations had better keep their feet moving if they don't want their bottom line to look like DeCaprio's private parts after he plunged.
It's corporatism not capitalism that says "try to keep the dull consumer buying what they don't need anyway".
A modest Pentium-M with silent cooling would serve the needs of most people far better than any Pentium-IV, complete with miniature nuclear cooling tower.
From where we are right now, a mad rush to 10GHz computing is not the most efficient use of available capital, a no amount of duping the average consumer can change that fact.
My view is that it was a sad day for humanity, democracy, and freedom of expression that ordinary, long established words from the English language (or any other) should have been subject to trademark rights in the first place.
Xerox should be trademarked.
Kleenex should be trademarked.
Pepsi should be trademarked.
Coke should NOT be trademarked.
McDonald's should NOT be trademarked.
Fedex should be trademarked.
Nike is debatable (obscure Greek mythology).
Clorox should be trademarked.
Lexmark should be trademarked.
Apple should NOT be trademarked.
I think we should accept reality and just get rid of trademark registration altogether except for xemes(TM) containing the letter x.
New item today on
The Wedgie that the VIA Esther C5J has now been branded as the C7. This core has accelerated instructions for AES, RSA, hardware entropy, and various SHA standards. It should run fanless at around 1GHz and outperform a P4 as a cypto NAT firewall.
http://www.monkey.org/openbsd/archive/misc/0402
Once upon a time Theo de Raadt wrote:
>Got a couple figures on AES performance... the cool one at the bottom.
>
>type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
>aes-128-cbc 15985.10k 16924.93k 17238.12k 17319.74k 17339.74k
> 1.6GHz amd64 in 32bit mode
>
>aes-128-cbc 13323.36k 14403.55k 13225.65k 14529.80k 14654.16k
> P3/1GHz
>
>aes-128-cbc 13090.59k 51065.12k 174593.45k 426600.92k 735548.02k
> VIA C3 with the xcrypt-* instructions. This is using a new diff
> I have written which makes OpenSSL directly use the cpu instructions
> if they are available, right in userland, without having to call to
>
>
>Two things are apparent. First, this CPU feature is really cool.
>Second, the OpenSSL glue above crypto operation has pathetically high
>overhead...
I vaguely recall a claim on the VIA site which I can't find right now that the Montgomery multiplier will perform one hundred 1024 bit RSA setups per second.
AND this chip supports NX.
I'm waiting until spring to replace my aging P200 firewalls. If those benchmarks prove out, I'll have the better part of a decade to seek out the next replacement.
Jump off your bike mid-ride, wander into the bush and pinch a couple of loaves. Then you can ride above your average speed all the way home.
Your 10% number boggles the mind. More likely the challenge was order of magnitude (factor of ten). Generally estimating within 20% is possible if you know mostly the right parameters and you estimate the arithmetic results.
Imagine if he could nail 10% all of the time. NASA would be on the phone asking him "for a chunk of foam travelling at 779 ft/s that impacts the wing of a shuttle on launch, how heavy would the foam have to be to cause lethal structural damage?"
Supercomputers can't answer these questions to within ten percent.
The only exception would have to be Sturgeon's law: 90% of everything (e.g. slashdot posts) is junk. Never fails in my experience.
Completely wrong. There are different scales available for dealing with different kinds of ignorance. I tried very hard to learn as little as possible about British royal succession with great success, spoiled only by the fabuluous movie "Henry V". Despite my highly cultivated ignorance, I'd have to be a complete moron not to know that there wasn't much of a British succession in the dark ages, and going back further in time there were a lot of Romans milling about, a lot of bridges and aqueducts, and a distinct shortage of royal castles in London.
Likewise, there weren't many presidents in America (of European descent) prior to 1492. There are always scales of knowledge available for a casting a wider net.
If you want a question worth complaining about: how many joules/kilogram are available from the isomeric decay of Hafnium 2m?
Einstein provided an upper bound, but it's very difficult to apply to this problem.
If Fabian is talking to the world at large, he should back up his complaints with constructive proposals. It's a complete waste of bandwidth to throw around a lot of complaints without putting those complaints into a context of how life might be someday improved. I read Fabian's original screed without learning anything solid I could take away as a perspective on SQL's weaknesses. I didn't notice a link to the REL project last time around, but this time when I looked at REL as least I came away with some concepts about how SQL's syntax is less than ideal. However, I'm not yet convinced that syntax matters as much as Fabian would like me to believe and I as far as I read the REL documentation, I didn't come away with any semantic insights.
BTW some people on this thread have argued that optimization is targetted at the semantics expressed by the syntax. This is far from being necessarily true: it's quite possible to a language to choose different optimizations for two expressions with semantic equivalence because there is a *cultural* difference in the intent and expectation of those expressions (e.g. assumptions about whether many or few results are expected). The "unless" syntax in Perl falls into this category of *cultural* semantics: the predicate is expected to evaluate 'true' for the productive execution path of the application.
As for your colleague, you provided her with a technical opinion on a project where it probably mattered to her whether she achieved a successful outcome. If you showed up for a job interview at my company and commented "isn't it OK to tell people their projects are going to fail without offering constructive advice" you'd be crossed off the list on the spot. It's useful to provide that advice if the time and place does not exist for something better, but it's also a sure sign of a bad attitude that you don't hold yourself to higher standards of contribution.
Which paragraph contributes more to the world long term: my blather about Fabian in my first paragraph, or my pointed observation about cultural effects that break down an abstraction barrier between syntax and semantics concerning optimization strategies in my second paragraph?
It appears that MS has also patented loser magnets: patents so bad that no one notices the patents in their portfolio filled with live ammunition pointed right at their head.
Stupid bogus statistics cost American businesses one trillion dollars a year in lost credibility.
I have no problem with people spending money to investigate this system, as long as no claims are made whatsoever on the basis of "excess" heat. Wake me up and report the excess heat when the "excess" heat arrives at a steam turbine.
If a bunch of nuclear scientists go out for a dinner together, do the funds tended *ever* amount to l'addition?
Exotic isotopes swimming in your post-fusion afterglow are worth reporting. Reporting that you can't add up your pay stub is not.