Actually, it isn't the fee; I believe that the computational cost of doing RSA or DSA schemes (but NOT DES, for which there should be fast cheap hardware), is deemed too high for hardware units that are meant to be consumer level and mass produced. Or it might also have been because of US export policy in the past which may have limited allowable key lengths. In any case, it almost surely came down to costs of production (and testing), not licensing, etc.
Just a nitpick: DES doesn't rely on any assumptions about primes at all. It assumes that no information about a key can be gathered from the ciphertext, or plaintext-ciphertexts pairs etc. (and this assumption is not always valid, BTW), and that the key is necessary to decode the message.
You probably mean RSA et al. (ie. public key encryption), which also doesn't rely on the assumption that primes are hard to find (because, in fact, they aren't), but rather that composites of two large primes are difficult to factor, or that discrete logorithms in a modular field are hard to invert.
And yes, I assume that now someone will nitpick this message.
Re:Wasn't the suit in federal court?
on
Fortune on Rambus
·
· Score: 1
What if your actual damages are much greater than $350k?
Re:Rambus should have counted their blessings...
on
Fortune on Rambus
·
· Score: 4
(Granted I don't know that Rambus really innovated on anything-- from the article and what I've heard, RDRAM "technology" is nearly identical to SDRAM except for a handful of minor changes..)
That is far from the truth. RAMBUS is significantly different in many ways, and can't be criticized for its lack of innovation. But those changes have their tradeoffs.
See Ars Technica article for the technical details.
The superior format was VHS, because it initially was able to offer the magical two hours of recording (over Beta's one hour). Beta never recovered from this initial disadvantage (IMO).
BTW, I grew up with Beta (which were very popular in Hawaii), and had to switch to VHS when we moved to California. I also bought an Amiga then, and loved it. But everyone else eventually caught up (mostly)...
I use GAIM (to talk to my girlfriend), and if the developers don't want to fight the power, I think they should should just name it Grime, for "Gtk Rename Instant MEssenger". (Grim would work, too)
Note that I don't think fighting this one is the best strategy, for the reasons you mention above. Let AOL get the bad publicity, and move on to more development, and more important fights.
I suppose Matlab might have incorporated the more recent LAPACK.
Oops. That is what I meant. Here is a help message from Matlab 6.0:
FLOPS Obsolete floating point operation count.
Earlier versions of MATLAB counted the number of floating point
operations. With the incorporation of LAPACK in MATLAB 6, this
is no longer practical.
One thing I thought would help matlab is a snoopahead on variable names. If a variable is no longer used in a function, it's memory can be freed. As it is, I often end of overwriting a single variable with each processing step (say an array of images), so that there aren't multiple unused variables held in core (keeping the working set size down).
Anyway, sorry for the mistake, and thanks for the correction.
Matlab is nice in many ways, and is probably becoming the defacto language for implementing scientific models, etc.
But, in has too many damn toolboxes (containing lots of stuff that should just be included with the base language, such as many image procesing and statistics functions... dct() is NOT included by default?)
Unfortunately, matlab is slow (version 6 may have improved due to incorporation of LINPACK), and absolutely STUPID(!!) about memory issues.
For my scientific computing degree, I used matlab almost exclusively, and was WISHING I could have used Fortran more often (even though I barely know it). Actually, I started using Octave (a freely available Matlab clone of sorts) quite a bit, and hope to contribute some work to it. It is actually faster than Matlab in many cases (and much of the numerical core is fortran)
You pretty much have to do compression if you're going to do encryption, since uncompressed data will have lots of cribs and repeated series of known data which will make cryptanalysis easier.
And since compression is deterministic, compressing wil do absolutely NOTHING to protect against a ciphertext-only attack, except reduce (slightly) the effectiveness of a "birthday attack". A 128-bit block cipher (such as AES) should be perfectly immune to such attacks. Ie. compression does NOT enhance security of the ciphertext, in any appreciable way, using a modern (ie. non-DES) cipher.
My point is not about whether or not the disk is coated on both sides, but rather, why writing a "0" bit on side A doesn't also write a corresponding "0" bit on side B. The magnetic field (it would seem to me), would be strong enough to act through the very thin disk and affect both sides. I suppose the answer is that my assumption is NOT true, and that the write field does not extend through to the back of the disk...
NEVER does Mike say "file size". He uses the phrase "total in size". In fact, here is a quote:
In order to meet the challenge you must provide to me a
compressed file and a decompressor which together total less
than the size of this original.dat, and which can generate a
file identical to original.dat.
He doesn't say "file size" in this or any other passage. It is Patrick who says (and assumes) this.
Also, Patrick specifically addresses the issue of filename based compression in this passage.
It's probably also possible to meet the challenge with smaller file sizes by storing information in the filename of the
compressed file or the decompressor, but I think most people would consider this to be cheating.
Thus, I think it is Patrick who hadn't considered the fact that his "decompressor" is not only just the 'dfi' script, but also the filename information used to indicate file boundaries and ordering. Like I said, his algorithm (much less his actual implementation) could not properly reassemble the file if it were fed all the properly ordered "compressed" files as an input stream (through a pipe, say), since it wouldn't know where to place the missing fives. So given that Mike said "total size", in all cases, when discussing and offering the challenge, I think his position is safe.
Now, I do think that Patrick was reasonably clever, and that Mike was overly smug in both the challenge and the initial news posting. And in the exchanges Patrick did explictly ask about file sizes, but I do not fault Mike for not clarifying further, since he had no a priori knowledge of the scheme, and therefore didn't know he would have to be so specific. But his use of terminology was consistent, and I think, appropriate, to protect against this type of scheme.
Anyway, that's just my take on it. Mike can hopefully learn some humility from this, and Patrick can learn that his "decompressor" is more than just the sum of its file bytes.
When Mozilla was started, this was sound advice (for portability sake). By the end of this year, it will be bad advice (in general). Use of templates (and STL) will be strongly favored for portability, speed, programmer man hours saved, etc.
However, the decompressor DOES depend on the filename numbering in order to work; it is part of the algorithm (and hence the "decompressor"), and those bytes (the bytes used to number the files) should be charged against the decompressor size. Then Patrick loses.
While not explicitly stated, those bytes ARE an integral part of the "decompressor" that was supplied (it can't work without them), and so including their size is consistent with the agreed upon rules, IMO.
I would argue that the decompressor needs the filename numbers in order to work (for ordering) It CANNOT work on a bitstream of the "compressed" files alone (even if the ordering is preserved), so it is dependent on the numbering in the filename, and thus, their size needs to be counted as part of the decompressor. If you add in these bytes, then the decompressor (file plus filename numbering bytes) and datafiles are larger than the original file.
So, after some consideration, I would say that Patrick didn't succeed, even considering the specific wording of the challenge (and the discussion in the emails).
I've heard this idea conjectured a lot by various people; but although the mandelbrot set is in some sense infinite, the set of images that can be produced has bounds. Basically, choosing any fractal, and sampling at any resolution, with any slice through the set, still won't produce the entire possible set of data that could be represented in the finite space that you've chosen. Due to the sampling, you would repeat some data and never produce others. In fact, the self-similarity properties of fractals would seem to indicate that this would be a rather poor (or inefficient) way to represent general data.
Slashdot Mirror
Actually, it isn't the fee; I believe that the computational cost of doing RSA or DSA schemes (but NOT DES, for which there should be fast cheap hardware), is deemed too high for hardware units that are meant to be consumer level and mass produced. Or it might also have been because of US export policy in the past which may have limited allowable key lengths. In any case, it almost surely came down to costs of production (and testing), not licensing, etc.
But, I'm just making a semi-informed guess...
Ha, I laughed at that one... But I assume you mean "E Coli", and not "ebola"...
Just a nitpick: DES doesn't rely on any assumptions about primes at all. It assumes that no information about a key can be gathered from the ciphertext, or plaintext-ciphertexts pairs etc. (and this assumption is not always valid, BTW), and that the key is necessary to decode the message.
You probably mean RSA et al. (ie. public key encryption), which also doesn't rely on the assumption that primes are hard to find (because, in fact, they aren't), but rather that composites of two large primes are difficult to factor, or that discrete logorithms in a modular field are hard to invert.
And yes, I assume that now someone will nitpick this message.
Vaporware...
What if your actual damages are much greater than $350k?
(Granted I don't know that Rambus really innovated on anything-- from the article and what I've heard, RDRAM "technology" is nearly identical to SDRAM except for a handful of minor changes..)
That is far from the truth. RAMBUS is significantly different in many ways, and can't be criticized for its lack of innovation. But those changes have their tradeoffs.
See Ars Technica article for the technical details.
But DDR SDRAM typically transfers 64 bits per clock (or half clock), and Rambus typically does 16 bits per clock.
Do THAT math, and all of a sudden DDR comes out ahead of RAMBUS (but, this is all oversimplification)
The superior format was VHS, because it initially was able to offer the magical two hours of recording (over Beta's one hour). Beta never recovered from this initial disadvantage (IMO).
h tml
http://www.urbanlegends.com/products/beta_vs_vhs.
BTW, I grew up with Beta (which were very popular in Hawaii), and had to switch to VHS when we moved to California. I also bought an Amiga then, and loved it. But everyone else eventually caught up (mostly)...
I use GAIM (to talk to my girlfriend), and if the developers don't want to fight the power, I think they should should just name it Grime, for "Gtk Rename Instant MEssenger". (Grim would work, too)
Note that I don't think fighting this one is the best strategy, for the reasons you mention above. Let AOL get the bad publicity, and move on to more development, and more important fights.
It is Ogg Vorbis, not be confused with "OOG, THE OPEN SOURCE CAVEMAN." OOG BREAK OPEN-SOURCE CD OVER HEAD FOR MAKING DUMB MISTAKE!!!!
Stupid lameness filter............
The Amiga GUI was called `Intuition'. As Peter Cherna (I believe), once said, "Intuition is the only one word oxymoron I know."
Oops. That is what I meant. Here is a help message from Matlab 6.0:
FLOPS Obsolete floating point operation count.
Earlier versions of MATLAB counted the number of floating point
operations. With the incorporation of LAPACK in MATLAB 6, this
is no longer practical.
One thing I thought would help matlab is a snoopahead on variable names. If a variable is no longer used in a function, it's memory can be freed. As it is, I often end of overwriting a single variable with each processing step (say an array of images), so that there aren't multiple unused variables held in core (keeping the working set size down).
Anyway, sorry for the mistake, and thanks for the correction.
Matlab is nice in many ways, and is probably becoming the defacto language for implementing scientific models, etc.
But, in has too many damn toolboxes (containing lots of stuff that should just be included with the base language, such as many image procesing and statistics functions... dct() is NOT included by default?)
Unfortunately, matlab is slow (version 6 may have improved due to incorporation of LINPACK), and absolutely STUPID(!!) about memory issues.
For my scientific computing degree, I used matlab almost exclusively, and was WISHING I could have used Fortran more often (even though I barely know it). Actually, I started using Octave (a freely available Matlab clone of sorts) quite a bit, and hope to contribute some work to it. It is actually faster than Matlab in many cases (and much of the numerical core is fortran)
And since compression is deterministic, compressing wil do absolutely NOTHING to protect against a ciphertext-only attack, except reduce (slightly) the effectiveness of a "birthday attack". A 128-bit block cipher (such as AES) should be perfectly immune to such attacks. Ie. compression does NOT enhance security of the ciphertext, in any appreciable way, using a modern (ie. non-DES) cipher.
The mantra of the myopic...
Yes they have; it was even mentioned in the intro. pr0n appears to be a profitable web business for some (or many).
My point is not about whether or not the disk is coated on both sides, but rather, why writing a "0" bit on side A doesn't also write a corresponding "0" bit on side B. The magnetic field (it would seem to me), would be strong enough to act through the very thin disk and affect both sides. I suppose the answer is that my assumption is NOT true, and that the write field does not extend through to the back of the disk...
Given that the internal plastic disk was quite thin, how did writing on one side of the disk not affect the bits stored on the other side.?
http://www.uwsg.iu.edu/hypermail/linux/kernel/0105 .1/0334.html
In order to meet the challenge you must provide to me a compressed file and a decompressor which together total less than the size of this original.dat, and which can generate a file identical to original.dat.
He doesn't say "file size" in this or any other passage. It is Patrick who says (and assumes) this.
Also, Patrick specifically addresses the issue of filename based compression in this passage.
It's probably also possible to meet the challenge with smaller file sizes by storing information in the filename of the compressed file or the decompressor, but I think most people would consider this to be cheating.
Thus, I think it is Patrick who hadn't considered the fact that his "decompressor" is not only just the 'dfi' script, but also the filename information used to indicate file boundaries and ordering. Like I said, his algorithm (much less his actual implementation) could not properly reassemble the file if it were fed all the properly ordered "compressed" files as an input stream (through a pipe, say), since it wouldn't know where to place the missing fives. So given that Mike said "total size", in all cases, when discussing and offering the challenge, I think his position is safe.
Now, I do think that Patrick was reasonably clever, and that Mike was overly smug in both the challenge and the initial news posting. And in the exchanges Patrick did explictly ask about file sizes, but I do not fault Mike for not clarifying further, since he had no a priori knowledge of the scheme, and therefore didn't know he would have to be so specific. But his use of terminology was consistent, and I think, appropriate, to protect against this type of scheme.
Anyway, that's just my take on it. Mike can hopefully learn some humility from this, and Patrick can learn that his "decompressor" is more than just the sum of its file bytes.
When Mozilla was started, this was sound advice (for portability sake). By the end of this year, it will be bad advice (in general). Use of templates (and STL) will be strongly favored for portability, speed, programmer man hours saved, etc.
The indices into Pi will take more room to represent (in terms of bits) than the data you are trying to represent (in general).
But it is a commonly suggested technique. Good try!
However, the decompressor DOES depend on the filename numbering in order to work; it is part of the algorithm (and hence the "decompressor"), and those bytes (the bytes used to number the files) should be charged against the decompressor size. Then Patrick loses.
While not explicitly stated, those bytes ARE an integral part of the "decompressor" that was supplied (it can't work without them), and so including their size is consistent with the agreed upon rules, IMO.
I would argue that the decompressor needs the filename numbers in order to work (for ordering) It CANNOT work on a bitstream of the "compressed" files alone (even if the ordering is preserved), so it is dependent on the numbering in the filename, and thus, their size needs to be counted as part of the decompressor. If you add in these bytes, then the decompressor (file plus filename numbering bytes) and datafiles are larger than the original file.
So, after some consideration, I would say that Patrick didn't succeed, even considering the specific wording of the challenge (and the discussion in the emails).
I've heard this idea conjectured a lot by various people; but although the mandelbrot set is in some sense infinite, the set of images that can be produced has bounds. Basically, choosing any fractal, and sampling at any resolution, with any slice through the set, still won't produce the entire possible set of data that could be represented in the finite space that you've chosen. Due to the sampling, you would repeat some data and never produce others. In fact, the self-similarity properties of fractals would seem to indicate that this would be a rather poor (or inefficient) way to represent general data.