This isn't a one time pad, and it's not terribly secure.
Why This Program Isn't Very Secure
Audio data is not very random. It contains lots of patterns. Record a sound file (or save an MP3 as a WAV) and look at the file. Some bytes show up more frequently than others. So at a minimum, an attacker can probably perform some messy statistics and discover some general things about your file--which byte values show up more often than others, for example.
Some Good Things About This Program
This program uses a poor encryption algorithm but a very large key. So even if parts of the file are decrypted, other parts will always be garbage. Most attacks on this progam will give probabilities, not definite results.
How to Fix It
Remove the one-time-pad entirely. Replace it a quality block cypher (this allows you to use the same key more than once, which you can't ever do with a one-time pad). Use your audio file (or other file) to generate a large key. Decide on a way to use your enormous key effectively.
How to Lean More
Read Applied Cryptography. Modern cryptography is very, very good, and there's no reason to fool around with one-time-pads and pseudo-random number generators.
It is quite clear that you only have to give due credit when the software with said clause is being totted as a feature of whatever you are advertising.
Yes. This is a problem. For example, if you have thirty different credit clauses in your TCP/IP network stack, and you say that you support TCP/IP networking, you'll have a big credit block in every ad.
If you want credit, ask for it on a splash screen or in the manual. This doesn't turn into advertising gridlock, and nobody really minds adding an extra few pages to their documentation. The credit clause wouldn't be so obnoxious if it only said "UC Berkley"--it's when every single developer wants separate credit.
The best license choices are (in no particular order) the GPL, LGPL, XFree86 and fixed BSD license.
The GPL
The GNU General Public License is used for Linux and GCC. It allows anyone to make copies of your code--and change things as they wish--but it doesn't allow one user to take these rights away from another user. Use the GPL if you want every user of your program to always have source available.
The LGPL
The GNU Lesser (or Library) General Public License is like the GPL, but allows proprietary software to link against a free library. The Linux C library uses the LGPL. Use this if you want your code to remain free, but don't care about who uses it in their program.
The XFree86 License
This license allows anybody to do anything with your code, but it tries to prevent people from suing you. For example, a software company could take your program and turn it into a proprietary product without giving you any money. The X Window System uses this license.
The BSD License
The BSD license is sort of like the XFree86 license, but older versions had a bad bug. The older BSD licenses required certain phrases to appear in advertisements for the software. Because of this, it used to be illegal to advertise a NetBSD CD-ROM without giving credit to 75 people in every ad. Newer versions of the BSD license often remove the obnoxious advertising clause. If you want to use the BSD license, it's probably safer to use the XFree86 license instead--they both do the same thing, but no version of the XFree86 license contains bugs.
Custom Licenses
Avoid these if at all possible. Writing new open source licenses is very, very difficult and most people (even good lawyers) screw it up. The licenses listed above should cover most possibilities, and each one is known to work.
So Microsoft's prepared a big page with some truths, some nonsense and a few inaccuracies.
The major Linux vendors needs to run some public price/performance benchmarks of their own through various respectable organizations. I bet Pacific High Tech can do something useful with clusering, for example.
But overall, we should thank Microsoft for providing such valuable feedback.;-)
OK, so it still has lots of bugs. But it sure looks good. I'll be switching my primary browser to Mozilla by M6 or M7, if development continues at this rate.
AIUI, Dylan is a higher-level language that doesn't special-case primitive types and encourages slinging around closures and other powerful but hard-to-optimize idioms.
You're reasonably close.;-) Dylan does allow some very powerful dynamic features which are a royal pain to optimize. (I spent last week crawling around inside a Dylan optimizer, so I know what I'm talking about.) However, these are all optional features--you can easily write very static programs which run fast.
Primitive types are handled specially in Dylan, but the language tries to be graceful about it. Just because integers show up in the class hiearchy doesn't mean that they're actually compiled that way. It's sort of like making 'int' and 'Int' into the same thing, and having the compiler use the more efficient representation whenever possible. It's actually pretty easy to get right.
Were they comparing a native Dylan compiler to a native Java compiler, or a portable Dylan bytecode interpreter to a JVM, or were they cooking their results?
Actually, the benchmark compared Harlequin Dylan to Microsoft Visual C++. It was run by a scientist who needed to do some number-crunching.
Harlequin Dylan finished within five percent of MSVC++. Gwydion Dylan (which I help maintain) wouldn't have done so well because it's still not finished. We usually see code that runs at half the speed of C.
All that said, there's no reason why Java should be any slower than Dylan. A good Java compiler should be able to match a C++ compiler for most tasks, which should amount to a three-way tie: C++, Dylan and Java, with some of the naive Dylan programmers paying a slight performance penalty by using excessively dynamic features.
One response I can anticipate: The idea that corporations do not have rights is baloney. Individuals have rights, and corporations are just associations of individuals. If each of Microsoft's shareholders and employees have rights to free speech, property, etc, why would MS not have that right.
I would argue that you cannot posses moral rights unless you have moral responsibilities. Under United States law, shareholders in a coporation are protected against many forms of legal liability if that corporation does something wrong.
Since Microsoft's shareholders have been give partial legal exemption from the consequences of Microsoft's actions, Microsoft cannot "inherit" all of their rights.
Asking for Microsoft to have all the rights possesed by its shareholders without making the shareholders take responsibility for Microsoft is morally inconsistent.
(This isn't academic--remember, the fines for anti-competitive practices are often three times the amount of money obtained illegally. Some studies show the Microsoft may have gained $10 billion dollars through monopoly pricing. They have $17 billion dollars in liquid assets. This means that Microsoft could hypothetically be $13 billion short (excluding their non-liquid assets).
If it weren't for limited liability, Microsoft shareholders would be responsible for that $13 billion. As it is, Microsoft would just go bankrupt in this scenario, and the shareholders would loose nothing but their Microsoft stock. So you see, they're really not responsible for Microsoft's actions.)
Well, my favorite language is Python, but I just wondered, is there any documentation about Dylan-to-C compiler ? The internals manuals aren't very verbose:-).
Oops. We're still filling those out as we find our way around the code.
Sure... but if you learned Dylan well enough to implement a Python compiler in Dylan, then you might find yourself losing interest in Python in favor of Dylan.:-)
That's not true! I help maintain a Dylan compiler, and I still like Python!
Wow. Somebody's posted an advertisement for our project. Since high praise always makes me nervous, let me try to deflect some of that enthusiasm in various directions.:-)
You also want the check out GNU Common Lisp, GNU Guile, Eiffel, ML, Prolog, Haskell and the various R4RS scheme interpreters.
There's a lot of free (and GPL'd) programming languages out there, and some of them are pretty fast and impressively powerful.
Slashdot Mirror
Why This Program Isn't Very Secure
Audio data is not very random. It contains lots of patterns. Record a sound file (or save an MP3 as a WAV) and look at the file. Some bytes show up more frequently than others. So at a minimum, an attacker can probably perform some messy statistics and discover some general things about your file--which byte values show up more often than others, for example.
Some Good Things About This Program
This program uses a poor encryption algorithm but a very large key. So even if parts of the file are decrypted, other parts will always be garbage. Most attacks on this progam will give probabilities, not definite results.
How to Fix It
Remove the one-time-pad entirely. Replace it a quality block cypher (this allows you to use the same key more than once, which you can't ever do with a one-time pad). Use your audio file (or other file) to generate a large key. Decide on a way to use your enormous key effectively.
How to Lean More
Read Applied Cryptography. Modern cryptography is very, very good, and there's no reason to fool around with one-time-pads and pseudo-random number generators.
It is quite clear that you only have to give due credit when the software with said clause is being totted as a feature of whatever you are advertising.
Yes. This is a problem. For example, if you have thirty different credit clauses in your TCP/IP network stack, and you say that you support TCP/IP networking, you'll have a big credit block in every ad.
If you want credit, ask for it on a splash screen or in the manual. This doesn't turn into advertising gridlock, and nobody really minds adding an extra few pages to their documentation. The credit clause wouldn't be so obnoxious if it only said "UC Berkley"--it's when every single developer wants separate credit.
The best license choices are (in no particular order) the GPL, LGPL, XFree86 and fixed BSD license.
The GPL
The GNU General Public License is used for Linux and GCC. It allows anyone to make copies of your code--and change things as they wish--but it doesn't allow one user to take these rights away from another user. Use the GPL if you want every user of your program to always have source available.
The LGPL
The GNU Lesser (or Library) General Public License is like the GPL, but allows proprietary software to link against a free library. The Linux C library uses the LGPL. Use this if you want your code to remain free, but don't care about who uses it in their program.
The XFree86 License
This license allows anybody to do anything with your code, but it tries to prevent people from suing you. For example, a software company could take your program and turn it into a proprietary product without giving you any money. The X Window System uses this license.
The BSD License
The BSD license is sort of like the XFree86 license, but older versions had a bad bug. The older BSD licenses required certain phrases to appear in advertisements for the software. Because of this, it used to be illegal to advertise a NetBSD CD-ROM without giving credit to 75 people in every ad. Newer versions of the BSD license often remove the obnoxious advertising clause. If you want to use the BSD license, it's probably safer to use the XFree86 license instead--they both do the same thing, but no version of the XFree86 license contains bugs.
Custom Licenses
Avoid these if at all possible. Writing new open source licenses is very, very difficult and most people (even good lawyers) screw it up. The licenses listed above should cover most possibilities, and each one is known to work.
So Microsoft's prepared a big page with some truths, some nonsense and a few inaccuracies.
The major Linux vendors needs to run some public price/performance benchmarks of their own through various respectable organizations. I bet Pacific High Tech can do something useful with clusering, for example.
But overall, we should thank Microsoft for providing such valuable feedback. ;-)
Mmmmm. Fresh code.
OK, so it still has lots of bugs. But it sure looks good. I'll be switching my primary browser to Mozilla by M6 or M7, if development continues at this rate.
AIUI, Dylan is a higher-level language that doesn't special-case primitive types and encourages slinging around closures and other powerful but hard-to-optimize idioms.
You're reasonably close. ;-) Dylan does allow some very powerful dynamic features which are a royal pain to optimize. (I spent last week crawling around inside a Dylan optimizer, so I know what I'm talking about.) However, these are all optional features--you can easily write very static programs which run fast.
Primitive types are handled specially in Dylan, but the language tries to be graceful about it. Just because integers show up in the class hiearchy doesn't mean that they're actually compiled that way. It's sort of like making 'int' and 'Int' into the same thing, and having the compiler use the more efficient representation whenever possible. It's actually pretty easy to get right.
Were they comparing a native Dylan compiler to a native Java compiler, or a portable Dylan bytecode interpreter to a JVM, or were they cooking their results?
Actually, the benchmark compared Harlequin Dylan to Microsoft Visual C++. It was run by a scientist who needed to do some number-crunching.
Harlequin Dylan finished within five percent of MSVC++. Gwydion Dylan (which I help maintain) wouldn't have done so well because it's still not finished. We usually see code that runs at half the speed of C.
All that said, there's no reason why Java should be any slower than Dylan. A good Java compiler should be able to match a C++ compiler for most tasks, which should amount to a three-way tie: C++, Dylan and Java, with some of the naive Dylan programmers paying a slight performance penalty by using excessively dynamic features.
One response I can anticipate: The idea that corporations do not have rights is baloney. Individuals have rights, and corporations are just associations of individuals. If each of Microsoft's shareholders and employees have rights to free speech, property, etc, why would MS not have that right.
I would argue that you cannot posses moral rights unless you have moral responsibilities. Under United States law, shareholders in a coporation are protected against many forms of legal liability if that corporation does something wrong.
Since Microsoft's shareholders have been give partial legal exemption from the consequences of Microsoft's actions, Microsoft cannot "inherit" all of their rights.
Asking for Microsoft to have all the rights possesed by its shareholders without making the shareholders take responsibility for Microsoft is morally inconsistent.
(This isn't academic--remember, the fines for anti-competitive practices are often three times the amount of money obtained illegally. Some studies show the Microsoft may have gained $10 billion dollars through monopoly pricing. They have $17 billion dollars in liquid assets. This means that Microsoft could hypothetically be $13 billion short (excluding their non-liquid assets).
If it weren't for limited liability, Microsoft shareholders would be responsible for that $13 billion. As it is, Microsoft would just go bankrupt in this scenario, and the shareholders would loose nothing but their Microsoft stock. So you see, they're really not responsible for Microsoft's actions.)
Well, my favorite language is Python, but I just wondered, is there any documentation about Dylan-to-C compiler ? The internals manuals aren't very verbose :-).
Oops. We're still filling those out as we find our way around the code.
Sure... but if you learned Dylan well enough to implement a Python compiler in Dylan, then you might find yourself losing interest in Python in favor of Dylan. :-)
That's not true! I help maintain a Dylan compiler, and I still like Python!
Wow. Somebody's posted an advertisement for our project. Since high praise always makes me nervous, let me try to deflect some of that enthusiasm in various directions. :-)
You also want the check out GNU Common Lisp, GNU Guile, Eiffel, ML, Prolog, Haskell and the various R4RS scheme interpreters.
There's a lot of free (and GPL'd) programming languages out there, and some of them are pretty fast and impressively powerful.
This is a really good book. It explains garbage collection in lots of detail and covers various implementation tradeoffs.
If you're not willing to read several hundred academic papers on this subject--and sort them all out--this book is definitely the best starting place.