Re:Languages and Libraries
on
Pike 7.6 Released
·
· Score: 3, Insightful
Firstly, the library has nothing to do with extensibility. Extensibility is a property of the language which just means that the syntax and semantics make it easy to add new syntax or library functionality.
Library functions are any which can be (but don't have to be) implemented in terms of other existing functions. As you note, the JLS specifies a bunch of primitive functions. These are the functions without which it would be difficult or impossible to write other Java programs.
The problem with not having a good distinction between language and library is that your needs in the library are too easily allowed to corrupt the simplicity of the language. Look at Perl, for example, whose language and syntax is frightingly complicated because of the inbreeding between language and library. Perl 6 is attempting to correct a lot of this, and rightfully so. No matter how much you like Perl 5, at some point the hodgepodge becomes a barrier to further use.
Languages and Libraries
on
Pike 7.6 Released
·
· Score: 3, Insightful
There is (or should be) a strong difference between a language and its libraries. Perl has done a poor job separating the two. Its nice to see Pike (or at least the poster) carry on that tradition.
Parrot is an unproven VM. It makes some rather odd design decisions, such as using a register based design which they claim is for efficiency, but actually increases complexity with little expense since presumably you'll JIT to a native instruction set anyway and thus have to re-register allocate after you've destroyed all kinds of dependency information by register allocating the first time.
At the very least Parrot needs time to mature before its clear whether its a good target VM. And before its mature, creating languages on top of it will be like building a house on a moving fault line, so we're talking a lot of time before a strong high level language with a complete standard library can be made on Parrot.
In the meantime, the JVM is almost ten years old, and literally dozens of languages compile to it.
You'd have to compile Java to the CLR, since the CLR has a few properties that the JVM doesn't, like tail recursion optimization. There may be properties the JVM has which aren't supported by the CLR as well which prevent that.
Actually, a 64bit processor could (assuming it also had a 64 bit address line) address 18 million terabytes. As it currently stands, mainstream 64 bit processors (including the AMD K8) have a 48 bit line which can 'only' address 281 terabytes.
It will likely be in their architecture manual. The summary of the protection is that it allows the OS to mark pages of virtual memory with a No Execute (NX) bit. Attempting to execute any instructions from such a page would cause a trap to the OS.
An OS would then use this to mark pure data page and areas like the stack as NX so that overflowing datastructures doesn't allow arbitrary malicious code to be run.
Microsoft knows that the delay to 2006 is unfavorable for them. First its a problem for all of the companies that bought into the subscription licensing, who are now seeing their money wasted essentially, paying MS for nothing for three more years. Second, it gives their competition nearly three years to advance before MS has an answer to any of it. Mac OS and to a lesser extent the Linux desktop will be quite different in 2006.
Knowing that, Microsoft is deliberately drumming up the hype now with an outrageously early beta, leaked screenshots, and surreptitious press releases and leaks about their upcoming features. Why? To get the current installed base excited about the next release, and to quiet any concerns they have that might make them switch in the interim. If they saw no compelling reason to stick around until 2006 they may migrate to other platforms. The leaks and beta try to give them that reason.
I agree with what you've said, but the primary problem is that most people can't choose their phone service provider, so they're forced to pay whatever the local phone franchise charges and deal with mediocre service or do without.
Capitalism only works when there isn't a monopoly on the product or service.
Quantum cryptography is not an encryption algorithm per-se. In fact, its a means of transmitting bits using quatum entanglement that guarantees on a physical level that an evesdropper cannot tap into those bits without changing them.
The result is a perfectly secure method of exchanging secrets... keys for example.
Re:Pixlet is really efficient!
on
Jaguar is Over
·
· Score: 1
...er, 3x larger.
Pixlet is really efficient!
on
Jaguar is Over
·
· Score: 1
48 bits per pixel eh? Thats 2.5 times larger than uncompressed YUY2. Excellent.
There is a second issue beyond increasing bus speed, and thats cost. PCI Express uses far fewer wires than PCI, simplifying layouts and reducing manufacturing costs. Its also scalable, with the ability to add wires to increase bandwidth much like Hypertransport.
All this means cheaper, smaller, higher performance machines. A good thing, really.
While the encryption aspect of Locutus is interesting, the real achievement in Locutus is its searching algorithm, which, like Freenet, scales logarithmically. Freenet, as you know, cannot yet be searched in the same manner (keyword boolean searches).
Contrast this with other P2P networks with searching, all of which rely on either broadcast or superpeer mitigated broadcast searching, which are either difficult to scale (Gnutella), or vulnerable to attacks on the superpeers (Kazaa and friends).
There are several forms of encryption used in Freenet. In the case of data key protection, the Twofish algorith is with 128 bit strength. Data keys (called Content Hash Keys) are created by running a hash function over the length of the data, and using the resulting has as input to a key generator. The data is then encrypted with that key, and the decryption key is appended to the 'URL' that is distributed'. The URL is *not* used by Freenet to route or store the data, just the Routing Key. In this way, only someone who posseses the full URL can view the data.
This doesn't prevent a blacklist of keys from being used to check an individual Freenet node, however, a couple of things protect against that:
Large files can be split into multiple chunks using a RAID-like parity algorithm. In such a case, its unlikely that any given node would contain all parts of a file, in which case decryption would be impossible.
The Freenet datastore can operate in a 'paranoid' mode, where the store itself is encrypted and can be rendered useless by wiping the decryption key.
You can always take a look at the source yourself to check for backdoors, its GPL after all.
I think most people here are missing the point. The evolutionary idea here is that in the Type II encode, the stegonography does create an image that is distorted (there's no way around that if you modify the color bits). HOWEVER, it stores its modifications in the hidden data.
This means that a piece of software thats capable of reading the hidden data can also output the unmodified image.
But if you can get at the unmodified image, isn't this trivially defeated for watermarking purposes? By itself, yes. But this opens the door for combining the algorithm with an implementation that runs on a "trusted" computing base. If, for example, the Type II watermark is encrypted, and the decryption is controlled by Palladium, Voila, secure DRM for images.
Actually, I hate to post inflamatory comments, but when I was working with MS SQL, we found it had a documented bug (in the MSDN Database) where it would deadlock on certain *read only selects* even when no other app/process was querying the database (inserts or otherwise).
I've seen a lot of mis-statements by various/.ers that I'd like to clarify:
- ElGamal is not an elliptic curve algorithm. Its a classical public key encryption system based on the discrete logarithm problem. Most DL problems can be refactored as elliptic curve problems though, so perhaps the poster was referring to a possible EC ElGamal. At any rate, I'm pretty sure GPG uses classical ElGamal.
- Symmetric ciphers are rarely broken by raw computational power (brute force). In fact, algorithms above about 80 bits are impossible to break by brute force due to the laws of physics.
- Quantum Cryptography today involves means of transmitting data at very low bitrates over a channel in which eavesdropping is impossible. QC is pretty much only useful for exchanging keys for symmetric algorihms (like AES, Twofish) securely, as the data rate is to slow to be practical for anything else.
- Assymetric Cryptography (public key) is based on several hard problems. The two that are used widely today:
* The prime factoring problem (RSA)
* The Discrete Logarithm problem (DSA, ElGamal) One will become widely available soon:
* The elliptic curve problem
- Yes, OTP is still perfectly secure, but its still perfectly useless, as w/ OTP you just shift the security to two other areas; truely random pad generation, and secure distribution of the pads.
One-time-pad systems are not only unbreakable, they are a form of perfect cryptography. You cannot decrypt the message because any conceivable message of the same length as the pad is a 'valid' decryption.
The simplest OTP system is XOR applied to the pad and the plaintext, i.e. (P XOR K) where K is the pad. Without K, any P is equally valid.
That said, OTP systems are generally useless without a provably secure method of distributing the pads. Prescient has a 'proprietary' system for this apparently. This is a big signal to real crypto consumers to run far far away. The second clue-bell is the company's statement that they are 100% confident in it. No good cryptographer should ever feel 100% confident in his/her system.
Slashdot Mirror
... and two sheets of A2 become steak sauce.
Firstly, the library has nothing to do with extensibility. Extensibility is a property of the language which just means that the syntax and semantics make it easy to add new syntax or library functionality.
Library functions are any which can be (but don't have to be) implemented in terms of other existing functions. As you note, the JLS specifies a bunch of primitive functions. These are the functions without which it would be difficult or impossible to write other Java programs.
The problem with not having a good distinction between language and library is that your needs in the library are too easily allowed to corrupt the simplicity of the language. Look at Perl, for example, whose language and syntax is frightingly complicated because of the inbreeding between language and library. Perl 6 is attempting to correct a lot of this, and rightfully so. No matter how much you like Perl 5, at some point the hodgepodge becomes a barrier to further use.
There is (or should be) a strong difference between a language and its libraries. Perl has done a poor job separating the two. Its nice to see Pike (or at least the poster) carry on that tradition.
Contrast with C, Java, or Scheme.
Parrot is an unproven VM. It makes some rather odd design decisions, such as using a register based design which they claim is for efficiency, but actually increases complexity with little expense since presumably you'll JIT to a native instruction set anyway and thus have to re-register allocate after you've destroyed all kinds of dependency information by register allocating the first time.
At the very least Parrot needs time to mature before its clear whether its a good target VM. And before its mature, creating languages on top of it will be like building a house on a moving fault line, so we're talking a lot of time before a strong high level language with a complete standard library can be made on Parrot.
In the meantime, the JVM is almost ten years old, and literally dozens of languages compile to it.
You'd have to compile Java to the CLR, since the CLR has a few properties that the JVM doesn't, like tail recursion optimization. There may be properties the JVM has which aren't supported by the CLR as well which prevent that.
Actually, a 64bit processor could (assuming it also had a 64 bit address line) address 18 million terabytes. As it currently stands, mainstream 64 bit processors (including the AMD K8) have a 48 bit line which can 'only' address 281 terabytes.
It will likely be in their architecture manual. The summary of the protection is that it allows the OS to mark pages of virtual memory with a No Execute (NX) bit. Attempting to execute any instructions from such a page would cause a trap to the OS.
An OS would then use this to mark pure data page and areas like the stack as NX so that overflowing datastructures doesn't allow arbitrary malicious code to be run.
Microsoft knows that the delay to 2006 is unfavorable for them. First its a problem for all of the companies that bought into the subscription licensing, who are now seeing their money wasted essentially, paying MS for nothing for three more years. Second, it gives their competition nearly three years to advance before MS has an answer to any of it. Mac OS and to a lesser extent the Linux desktop will be quite different in 2006.
Knowing that, Microsoft is deliberately drumming up the hype now with an outrageously early beta, leaked screenshots, and surreptitious press releases and leaks about their upcoming features. Why? To get the current installed base excited about the next release, and to quiet any concerns they have that might make them switch in the interim. If they saw no compelling reason to stick around until 2006 they may migrate to other platforms. The leaks and beta try to give them that reason.
I agree with what you've said, but the primary problem is that most people can't choose their phone service provider, so they're forced to pay whatever the local phone franchise charges and deal with mediocre service or do without.
Capitalism only works when there isn't a monopoly on the product or service.
Quantum cryptography is not an encryption algorithm per-se. In fact, its a means of transmitting bits using quatum entanglement that guarantees on a physical level that an evesdropper cannot tap into those bits without changing them.
The result is a perfectly secure method of exchanging secrets... keys for example.
48 bits per pixel eh? Thats 2.5 times larger
than uncompressed YUY2. Excellent.
There is a second issue beyond increasing bus speed, and thats cost. PCI Express uses far fewer wires than PCI, simplifying layouts and reducing manufacturing costs. Its also scalable, with the ability to add wires to increase bandwidth much like Hypertransport.
All this means cheaper, smaller, higher performance machines. A good thing, really.
While the encryption aspect of Locutus is interesting, the real achievement in Locutus is its searching algorithm, which, like Freenet, scales logarithmically. Freenet, as you know, cannot yet be searched in the same manner (keyword boolean searches).
Contrast this with other P2P networks with searching, all of which rely on either broadcast or superpeer mitigated broadcast searching, which are either difficult to scale (Gnutella), or vulnerable to attacks on the superpeers (Kazaa and friends).
There are several forms of encryption used in Freenet. In the case of data key protection, the Twofish algorith is with 128 bit strength. Data keys (called Content Hash Keys) are created by running a hash function over the length of the data, and using the resulting has as input to a key generator. The data is then encrypted with that key, and the decryption key is appended to the 'URL' that is distributed'. The URL is *not* used by Freenet to route or store the data, just the Routing Key. In this way, only someone who posseses the full URL can view the data.
This doesn't prevent a blacklist of keys from being used to check an individual Freenet node, however, a couple of things protect against that:
You can always take a look at the source yourself to check for backdoors, its GPL after all.
I think most people here are missing the point. The evolutionary idea here is that in the Type II encode, the stegonography does create an image that is distorted (there's no way around that if you modify the color bits). HOWEVER, it stores its modifications in the hidden data.
This means that a piece of software thats capable of reading the hidden data can also output the unmodified image.
But if you can get at the unmodified image, isn't this trivially defeated for watermarking purposes? By itself, yes. But this opens the door for combining the algorithm with an implementation that runs on a "trusted" computing base. If, for example, the Type II watermark is encrypted, and the decryption is controlled by Palladium, Voila, secure DRM for images.
Actually, I hate to post inflamatory comments, but
when I was working with MS SQL, we found it had
a documented bug (in the MSDN Database) where it
would deadlock on certain *read only selects*
even when no other app/process was querying the database (inserts or otherwise).
I've seen a lot of mis-statements by various /.ers that I'd like to clarify:
- ElGamal is not an elliptic curve algorithm. Its a classical public key encryption system based on the discrete logarithm problem. Most DL problems can be refactored as elliptic curve problems though, so perhaps the poster was referring to a possible EC ElGamal. At any rate, I'm pretty sure GPG uses classical ElGamal.
- Symmetric ciphers are rarely broken by raw computational power (brute force). In fact, algorithms above about 80 bits are impossible to break by brute force due to the laws of physics.
- Quantum Cryptography today involves means of transmitting data at very low bitrates over a channel in which eavesdropping is impossible. QC is pretty much only useful for exchanging keys for symmetric algorihms (like AES, Twofish) securely, as the data rate is to slow to be practical for anything else.
- Assymetric Cryptography (public key) is based on several hard problems. The two that are used widely today:
* The prime factoring problem (RSA)
* The Discrete Logarithm problem (DSA, ElGamal)
One will become widely available soon:
* The elliptic curve problem
- Yes, OTP is still perfectly secure, but its still perfectly useless, as w/ OTP you just shift the security to two other areas; truely random pad generation, and secure distribution of the pads.
One-time-pad systems are not only unbreakable, they are a form of perfect cryptography. You cannot decrypt the message because any conceivable message of the same length as the pad is a 'valid' decryption.
The simplest OTP system is XOR applied to the pad and the plaintext, i.e. (P XOR K) where K is the pad. Without K, any P is equally valid.
That said, OTP systems are generally useless without a provably secure method of distributing the pads. Prescient has a 'proprietary' system for this apparently. This is a big signal to real crypto consumers to run far far away. The second clue-bell is the company's statement that they are 100% confident in it. No good cryptographer should ever feel 100% confident in his/her system.