That'll weed out those who have no commitment. It'll also make the handful of math-oriented people in the class more aware of the connections between mathematics and computer science. It's not like people these days are encouraged to get rid of the bad habits they picked up with J. Random Wanker Language or anything. Also, interactive programming with hugs. Who doesn't like hugs?
Hell, maybe it'll teach kids better habits (like focusing on the algorithm and on getting a working program first) than some heavy mittens language like Python or Javur. The error messages could probably be a little much for 10-year olds though. Maybe Helium, a Haskell variant geared for education and without some of the more esoteric features, would suit that better?
NNTP traffic tends to be, at least in europe where ISPs provide local news servers, local to the ISP's own networks. And therefore just a slight blip on the larger whole of backbone traffic. (Hell, I'd expect SSH to look bigger on the graph.)
You probably already knew all that, I'm just educating the masses here...
I mean, jeez, I've implemented a progressive-mesh generation algorithm myself, almost five years ago! Mesh detail reduction based on, say, the quadric error metric of Whatsisname and Cantremember has been around for _decades_ now.
Filesystems, the TCP/IP stack, memory management, overdesign. I suppose in roughly that order.
But hey, I've installed a Debian GNU/Hurd computer once. It wasn't very fun (clearly very much in a development stage), but it worked far enough for me to read a few comments from bash.org in w3m from the console.
Yes, the number is in the hundreds of megabytes. Typically, to crack a weakly-keyed wireless network you need to see about two gigabytes' worth of data, though the margin of error for this number is rather large since you'll be looking for packets with weak generated keys, and the occurrence of those is somewhat random. Could be more, could be less.
The nice thing is that you don't need to capture and save the encrypted frames. The cracking clients merely need to see enough traffic, which means that you could even crack a wireless network with one of those D-Link CF WLAN cards and any old IPaq, if the network had enough traffic going through it while your batteries last;-)
Then there's anything at all that requires a not-quite-trivial amount of computation per item but that generates absolutely huge datasets. Or just medium datasets that need to be gone over several times, as with some iterative clustering algorithms. I'm sure there are other examples where the given data is not naturally in a floating-point format.
In any case, the cluster is pretty neat. Apart from the obvious hack value I'd think that it would be quite nice having something like that to develop your parallel processing applications on, considering the low power requirement and heat dissipation (which I'd expect would help with reliability, though really I haven't a clue), provided that you kept your development datasets small enough to fit on one non-RAIDed 160-gig volume.
If you're going to compute the kind of numbers one would run across in an astrophysics simulation, it would sound reasonable that you'd also be using some kind of a rational number library (GNU MP comes to mind), especially with the concern for numerical error you talk about. Though I can't be sure -- I guess the performance tradeoff would be rather large. Anyway, from a quick read of some of the multi-precision floating-point number code in GNU libgmp, I'd conclude that it doesn't do all that much with the FPU. ICBW tho.
Not that I disagree with you on the fixed-point matter. The original poster must have been brought up on old 486s or early Pentium 1s and the canonical affine texture-mapping loop or something:-)
Dude, the 800mhz VIA chips have the 3dNOW! extensions in them. Remember the AMD K6-2 and K6-3? The ones with the completely non-pipelined x87-style FPU that, quite frankly, sucked? But they ended up having a fully pipelined, 2-cycle latency packed 2-way SIMD floating-point thingy in 3dNOW! that could totally issue a pfadd/pfmul pair on every damn cycle in parallel. Remember how the optimized Voodoo2 driver for a K6 absolutely blew anything else out of the water?
Anyway. What I'm trying to say is that you generally wouldn't provide a SIMD floating-point implementation if your underlying core is rubbish. Still, the site states that the cluster is probably equivalent to a significantly costlier cluster of 5 or 6 2.4ghz P4 boxes, and with the credentials the builder's got I'd say he's done some proper benchmarking already. That said, it wouldn't be hard to convert whatever the hell he's using for linear algebra to use 3dNOW! loops for the matrix multiplications, seeing as that the builders of one experimental cluster (made of Athlon Thunderbirds, IIRC) already wrote a patch to cantrememberthename to that effect.
Not to mention what kind of games it'll play with processors that have a high branch misprediction penalty. Like, for example, anything at all that Intel has cranked out in the last six years, from the pentium pro and up.
Isn't ethanol more properly written out as C2H5OH (i.e. a distinct OH group in the molecule, instead of a sixth hydrogen atom connected to one of the carbons)?
No. If a company is in violation of the GNU GPL, and at some point in the future decides to comply, it does not erase past violations in one fell swoop. Out-of-court settlements aside, a company that has once upon a time been in violation of your code is in exactly the same sort of actionable position (though some countries will consider sufficiently old crimes as too old to sue over, this time is typically measured in decades) as a company that has been and still is in violation.
You're right in that getting out of the "in violation" state can be accomplished by either getting into a position where the GNU GPL no longer applies (i.e. removing GPL'ed code from the offending binary) or by getting in compliance with the GPL by releasing source code as required by the license.
IANAL, even though there's no reason or requirement for me to say so.
Because, apparently, the FSF doesn't have any particular ambition to become known as a hard-ass, vindictive copyright violation enforcer. Let's face it -- in all but the most egregious of cases (think SCO), it'd be very much past the overkill marker to go for the jugular and sue for piles and piles of damages (most of which the plaintiff wouldn't even see -- how many companies do you know of that can afford to cough up, say, $150k times 5000?), destroying a potentially worthwhile company in the process.
A much better resolution, in my view, is to settle out of court and not press formal charges in exchange for full source code release or a behind-the-scenes agreement that the offender Won't Do That Again, and a public apology. That way, the FSF gets nice-guy points, the offender is given a chance to save face and the press releases that may follow show for everyone that when you mess with the FSF and/or the GNU GPL, you're likely to end up capitulating in the end.
Far as I've understood, the FSF isn't exactly hurting for money, considering all the donations and free lawyering they're getting.
Fortunately, in most of the civilized countries (i.e. European nations and others that have been significantly influenced by their legal traditions), in lawsuits where licenses (and contracts as well, though the GNU GPL is not one) are involved they are primarily evaluated on the intent of the licensor instead of the tiniest little bits of wording. IANAL, and I don't have to remind you about that from where I'm sitting, but around here you can't play semantic games with the courts. You can try, but don't expect to win.
Also, given that the GNU GPL is worded to be essentially semantic-game-proof in the US, it would seem that you'd need some heavy bribery or pre-existing bias to get a court to not outright defenestrate wording-based arguments.
I heard someone say, though I forget when and where, that if all stories are stripped of the particulars down to the abstract bone, there are about seven distinct story outlines. Total. In any culture.
Obviously, most of these were already explored by the ancient Greeks. Most likely even before that.
If we were to apply this outline to, say, the first Matrix movie, we'll get:
1. Neo meets Trinity 2. There's nothing going on at first (apparently) 3. Trinity remembers (or considers, or whatever) what the Oracle supposedly told her 4. Fight fight fight, shoot shoot shoot, techno techno techno 5. Circumstances (agents and stuff) intervene between N. and T. (i.e. morpheus, the father-figure, gets captured) 6. Big fights and all 7. N. finally wins over the matrix's evil underlords (the agents, again), comes back from the brain-dead and gets the girl 8. Everybody lives happily ever after.
See? It isn't that hard. Try the same for Shakespeare's Romeo and Juliet just for fun.
It keeps you from getting shoved around by bullying a##eholes like the US really well. Also, the radiation safety and other protocols will go a long way toward getting a proper nuclear energy program (i.e. using something else than breeder reactors) bootstrapped, assuming that you're planning to build nuclear power plants after you've built nuclear explosives and not the other way around.
It's like this: there were very few native OS/2 applications because first, the operating system had a pretty good win32 emulation layer for the day, and second, it didn't particularly encourage development of free software (not to mention that GNU/Linux hadn't really taken off like it did in 1996 at the time).
So, yeah, this emulation layer is precisely what we want to discourage. Me, if I had any kind of clout over the driver interface layers in the Linux kernel, I'd go out of my way to technologically kneecap this perverse little project of theirs. I'm sure many kernel developers share this sentiment (after all, I got it from the LKML, originally), being that it will be their work that is put in a bad light once a Volish binary-only crud driver craps all over some critical file system structures and completely, totally, entirely fucks up your pr0n filesystem.
Slashdot Mirror
You, sir, are a thief and a charlatan. I spit on you.
That film has a penis.
That'll weed out those who have no commitment. It'll also make the handful of math-oriented people in the class more aware of the connections between mathematics and computer science. It's not like people these days are encouraged to get rid of the bad habits they picked up with J. Random Wanker Language or anything. Also, interactive programming with hugs. Who doesn't like hugs?
Hell, maybe it'll teach kids better habits (like focusing on the algorithm and on getting a working program first) than some heavy mittens language like Python or Javur. The error messages could probably be a little much for 10-year olds though. Maybe Helium, a Haskell variant geared for education and without some of the more esoteric features, would suit that better?
NNTP traffic tends to be, at least in europe where ISPs provide local news servers, local to the ISP's own networks. And therefore just a slight blip on the larger whole of backbone traffic. (Hell, I'd expect SSH to look bigger on the graph.)
You probably already knew all that, I'm just educating the masses here...
Yes, let's all bend over willingly and apply lubricant to our rectums so that perhaps the reaming won't hurt quite so much.
Shouldn't that be bovonic media, if it's made from the proteins in cow guts?
The Iraq chapter of Mensa is going to have a real field day.
+5 Insightful, all the way.
I mean, jeez, I've implemented a progressive-mesh generation algorithm myself, almost five years ago! Mesh detail reduction based on, say, the quadric error metric of Whatsisname and Cantremember has been around for _decades_ now.
Filesystems, the TCP/IP stack, memory management, overdesign. I suppose in roughly that order.
But hey, I've installed a Debian GNU/Hurd computer once. It wasn't very fun (clearly very much in a development stage), but it worked far enough for me to read a few comments from bash.org in w3m from the console.
And besides, the RC4 weak key scheduling thing wasn't known until after the WEP specification became widely accepted.
Yes, the number is in the hundreds of megabytes. Typically, to crack a weakly-keyed wireless network you need to see about two gigabytes' worth of data, though the margin of error for this number is rather large since you'll be looking for packets with weak generated keys, and the occurrence of those is somewhat random. Could be more, could be less.
;-)
The nice thing is that you don't need to capture and save the encrypted frames. The cracking clients merely need to see enough traffic, which means that you could even crack a wireless network with one of those D-Link CF WLAN cards and any old IPaq, if the network had enough traffic going through it while your batteries last
Then there's anything at all that requires a not-quite-trivial amount of computation per item but that generates absolutely huge datasets. Or just medium datasets that need to be gone over several times, as with some iterative clustering algorithms. I'm sure there are other examples where the given data is not naturally in a floating-point format.
In any case, the cluster is pretty neat. Apart from the obvious hack value I'd think that it would be quite nice having something like that to develop your parallel processing applications on, considering the low power requirement and heat dissipation (which I'd expect would help with reliability, though really I haven't a clue), provided that you kept your development datasets small enough to fit on one non-RAIDed 160-gig volume.
If you're going to compute the kind of numbers one would run across in an astrophysics simulation, it would sound reasonable that you'd also be using some kind of a rational number library (GNU MP comes to mind), especially with the concern for numerical error you talk about. Though I can't be sure -- I guess the performance tradeoff would be rather large. Anyway, from a quick read of some of the multi-precision floating-point number code in GNU libgmp, I'd conclude that it doesn't do all that much with the FPU. ICBW tho.
:-)
Not that I disagree with you on the fixed-point matter. The original poster must have been brought up on old 486s or early Pentium 1s and the canonical affine texture-mapping loop or something
Dude, the 800mhz VIA chips have the 3dNOW! extensions in them. Remember the AMD K6-2 and K6-3? The ones with the completely non-pipelined x87-style FPU that, quite frankly, sucked? But they ended up having a fully pipelined, 2-cycle latency packed 2-way SIMD floating-point thingy in 3dNOW! that could totally issue a pfadd/pfmul pair on every damn cycle in parallel. Remember how the optimized Voodoo2 driver for a K6 absolutely blew anything else out of the water?
Anyway. What I'm trying to say is that you generally wouldn't provide a SIMD floating-point implementation if your underlying core is rubbish. Still, the site states that the cluster is probably equivalent to a significantly costlier cluster of 5 or 6 2.4ghz P4 boxes, and with the credentials the builder's got I'd say he's done some proper benchmarking already. That said, it wouldn't be hard to convert whatever the hell he's using for linear algebra to use 3dNOW! loops for the matrix multiplications, seeing as that the builders of one experimental cluster (made of Athlon Thunderbirds, IIRC) already wrote a patch to cantrememberthename to that effect.
Not to mention what kind of games it'll play with processors that have a high branch misprediction penalty. Like, for example, anything at all that Intel has cranked out in the last six years, from the pentium pro and up.
Isn't ethanol more properly written out as C2H5OH (i.e. a distinct OH group in the molecule, instead of a sixth hydrogen atom connected to one of the carbons)?
Yeah, that's pretty much it. Just felt that these things needed to be pointed out for those with significantly higher UIDs ;-)
No. If a company is in violation of the GNU GPL, and at some point in the future decides to comply, it does not erase past violations in one fell swoop. Out-of-court settlements aside, a company that has once upon a time been in violation of your code is in exactly the same sort of actionable position (though some countries will consider sufficiently old crimes as too old to sue over, this time is typically measured in decades) as a company that has been and still is in violation.
You're right in that getting out of the "in violation" state can be accomplished by either getting into a position where the GNU GPL no longer applies (i.e. removing GPL'ed code from the offending binary) or by getting in compliance with the GPL by releasing source code as required by the license.
IANAL, even though there's no reason or requirement for me to say so.
Because, apparently, the FSF doesn't have any particular ambition to become known as a hard-ass, vindictive copyright violation enforcer. Let's face it -- in all but the most egregious of cases (think SCO), it'd be very much past the overkill marker to go for the jugular and sue for piles and piles of damages (most of which the plaintiff wouldn't even see -- how many companies do you know of that can afford to cough up, say, $150k times 5000?), destroying a potentially worthwhile company in the process.
A much better resolution, in my view, is to settle out of court and not press formal charges in exchange for full source code release or a behind-the-scenes agreement that the offender Won't Do That Again, and a public apology. That way, the FSF gets nice-guy points, the offender is given a chance to save face and the press releases that may follow show for everyone that when you mess with the FSF and/or the GNU GPL, you're likely to end up capitulating in the end.
Far as I've understood, the FSF isn't exactly hurting for money, considering all the donations and free lawyering they're getting.
Fortunately, in most of the civilized countries (i.e. European nations and others that have been significantly influenced by their legal traditions), in lawsuits where licenses (and contracts as well, though the GNU GPL is not one) are involved they are primarily evaluated on the intent of the licensor instead of the tiniest little bits of wording. IANAL, and I don't have to remind you about that from where I'm sitting, but around here you can't play semantic games with the courts. You can try, but don't expect to win.
Also, given that the GNU GPL is worded to be essentially semantic-game-proof in the US, it would seem that you'd need some heavy bribery or pre-existing bias to get a court to not outright defenestrate wording-based arguments.
I heard someone say, though I forget when and where, that if all stories are stripped of the particulars down to the abstract bone, there are about seven distinct story outlines. Total. In any culture.
Obviously, most of these were already explored by the ancient Greeks. Most likely even before that.
If we were to apply this outline to, say, the first Matrix movie, we'll get:
1. Neo meets Trinity
2. There's nothing going on at first (apparently)
3. Trinity remembers (or considers, or whatever) what the Oracle supposedly told her
4. Fight fight fight, shoot shoot shoot, techno techno techno
5. Circumstances (agents and stuff) intervene between N. and T. (i.e. morpheus, the father-figure, gets captured)
6. Big fights and all
7. N. finally wins over the matrix's evil underlords (the agents, again), comes back from the brain-dead and gets the girl
8. Everybody lives happily ever after.
See? It isn't that hard. Try the same for Shakespeare's Romeo and Juliet just for fun.
It keeps you from getting shoved around by bullying a##eholes like the US really well. Also, the radiation safety and other protocols will go a long way toward getting a proper nuclear energy program (i.e. using something else than breeder reactors) bootstrapped, assuming that you're planning to build nuclear power plants after you've built nuclear explosives and not the other way around.
Shouldn't that be, like, "ecstasy (MDMA, hopefully, among other things)" these days?
Then again, I suppose the 'tards will pop anything that has a smiley face on it.
It's like this: there were very few native OS/2 applications because first, the operating system had a pretty good win32 emulation layer for the day, and second, it didn't particularly encourage development of free software (not to mention that GNU/Linux hadn't really taken off like it did in 1996 at the time).
So, yeah, this emulation layer is precisely what we want to discourage. Me, if I had any kind of clout over the driver interface layers in the Linux kernel, I'd go out of my way to technologically kneecap this perverse little project of theirs. I'm sure many kernel developers share this sentiment (after all, I got it from the LKML, originally), being that it will be their work that is put in a bad light once a Volish binary-only crud driver craps all over some critical file system structures and completely, totally, entirely fucks up your pr0n filesystem.