It is simply impossible to implement DRM with free software because DRM relies entirely on security by obscurity. The DRM system can hold no secrets from the user because the user (read: the user's computer) needs to know everything in order to decrypt and access the media. Breaking DRM is a matter of finding the obscured information that is already available.
As it was already pointed out by example, in being transparent and showing the source code there no way to obscure any information, unlike a proprietary system that is only available in an obscured, compiled form.
So someone was either confused or tricked here. The marketing double-speak quoted in TFA seems to indicate the latter.
Conceptually, the size of the code is how many different things -- variables, blocks of code -- a developer has to think about and keep track of in his head. For a metric, I would parse the code, then count how many nodes there are in the parse tree, or look at the depth or width of the parse tree. This gets around all of the actual formatting of the code and ignores comments.
It still wouldn't be very strong. If someone wanted to artificially inflate code, they could easily refactor in a bunch of new variables, which wouldn't do anything but add conceptual load to do code, making it worse. This operation is a feature in most IDEs.
Ah, I see 1.5 came out in June, which was after I stopped following Subversion's development. For at least a couple of years, they had been promising merge tracking was coming, so I assumed it was still just a promise. However, the version we use where I work, and will use for a long while still, is older than 1.5, so standard procedure right now is to just not branch.
Thanks for pointing this out! I stand corrected.
I really did love Subversion for awhile, especially once it freed me from the mess that is CVS. It was a huge improvement no doubt. However, moving to Git is that same huge leap of improvement, and, for me, looking back at Subversion from Git is like looking back at CVS from Subversion.
I keep a copy of Applied Cryptography, Second Edition by my bed. Looking right now, on page 461, section 19.1.
The concept of public key-cryptography was invented by Whitfield Diffie and Martin Hellman, and independantly by Ralph Merkle.
So your own source says otherwise.:-P
However, on page 31, section 2.5, it says that the NSA claims it came up with it back in 1966, ten years earlier, but they offer no proof. I have read this book cover to cover, and I don't remember seeing anything about the British secret service and public-key cryptography.
Sheesh tagging and branching really is the weak point of CVS while SVN does both pretty well!
To say Subversion is pretty good at branching is to say you are pretty good at sex because you know how to put on a condom.
Subversion branching is easy, constant time O(1) operation, but the real work is in merging, which Subversion completely fails at. Currently, all merging must be manually tracked separately from Subversion itself. Branches are a last resort in Subversion, while they are commonplace in better equipped VCSs.
but it doesn't mean much when SVN's handling of merges is so primitive.
Precisely. I like this think of it this way: Einstein said "Make everything as simple as possible, but not simpler." When Subversion tried to be elegantly simple by having tagging and branching be exactly same operation as cheap copies, they went too simple.
You have a load of data which resides on your filesystem (basically a full repo copy) while SVN keeps only parts of the metadata locally.
Something very interesting about that is that Git clones generally smaller than the equivalent Subversion checkout. To see how these look, I made clones of several large project Subversion repos, including Freeciv (~15000 revisions) and Ruby (~36000 revisions), using git-svn, then did a "git gc" on it to pack it all together nice and tight. Cloning from Subversion is very slow so this can take a few days to complete. Next, I did a separate normal svn checkout.
In all cases I looked at, the Git clone, which contains the entire repository in full, was actually smaller than the single revision Subversion checkout. And this was just with the default "git gc" settings. So, if someone is making a point that the size of the checkout is a factor -- probably assuming a repository clone will be bigger -- Git actually wins it.
Unfortunately, appealing to the general public is a lowest common denominator thing, and, in the end, it tends to create boring, worthless garbage like Garfield and Family Circus.
My sarcasm detector didn't go off, so, to me, it seems that you are quite serious.
You are completely wrong, as both of them are part of the "protect the children" rhetoric/bullshit. They both co-sponsoredthis load of bullshit (KIDSPA). The fact that the next president of the US is going be so completely devoid of reason to support such a thing is scary.
This was devised long ago as something called spook words. In fact emacs has a spook function specifically for this purpose. Tag them on the end of your e-mail or IM or whatever. If enough people do this then they break the filters, kind of like spammers with Bayesian poisoning.
STARLAN ASIO ASO quiche world domination bemd Leitrim Crypto AG Croatian SP4 SSL Jiang Zemin CIA Centro afsatcom
But the duress key decrypts the same data to war and peace (or whatever you think appropriate).
I would use something legal and unincriminating, but possibly embarrassing, like pornography. That way the encryption would seem much more plausible; the nastier the porn the more plausible it is.
With XHTML, there are two different types of validation, "strict" and "transitional" (more casual allowing some old-style things). And one may argue, from some certain point of view, that these might be degrees of compliance to XHTML.
The closing tags for <p> elements are optional and the <br> element type is empty.
This is true for plain old HTML4, however the newer (and arguably improved) XHTML standard is a bit more strict about it. The XHTML specs, section 4.3 it says "For non-empty elements, end tags are required" and in 4.6 "Empty elements must either have an end tag or the start tag must end with/>." That is, for both strict and transitional, all <p> tags must be closed with a closing </p> tag, and <br> is not allowed without either a closing tag or instead as closed start tag, <br/>.
Now, most browsers won't choke on not closing your paragraph tags and will get along as if you did close them, probably due in great part to HTML4, which is why the grandparent doesn't bother with it, but this doesn't really make it a standard. Implementation defined behavior is not a good way to go about things if you want to have many different compatible browsers (for example, this is why there is only one Perl5 interpreter), because different browsers may choose different ways to handle the ambiguous code.
Your key smashing doesn't produce as much entropy as you think. In fact, there is very little entropy in there at all (there are patterns and many repeated characters), and is probably equivalent to just a few randomly generated printable characters.
However, it is true that you don't need software to generate a good password. Use Diceware.
When I saw one of them was called "Home" I assumed this was the Microsoft one, as they have a history of hijacking common words for their products (Word, Works, Windows, etc.), which has even caused trouble for them in the past (paying Linspire millions in a settlement). However, I see that it is actually Sony's that is called "Home". Hmm...
As a Debian user who always starts from the bare bones install and apt-gets my way to ideal, I agree with you that the base install shouldn't include Python. The base install is an example of something we want to be tight and small.
However, not everything worth writing should be written in C.
In general, writing C is expensive, compared to interpreted languages. More bugs need to be ironed out. There are portability issues, so moving to each new architecture or platform takes more and more effort. The program is longer and more complicated. And, worst of all, you are repeating a lot of work other people have already done. In the end, your C program is going to be tighter and faster than the interpreted one, but at what cost? And what have you gained? The user will not be able to notice the difference between 10ms and 100ms run times. Most desktop software spends almost all of its time waiting on I/O (this includes user input), and there is pretty much nothing that can be done (software-wise) to make I/O faster. Meatspace is too slow.
The interpreted version is usually fast enough and it's easier to write and maintain. To use your example, writing a build system in C is premature optimization, and the general rule for that is Don't Do It. Programs have bottlenecks, which cannot be found until you are done. If you really need speed, use a good profiler to find those bottlenecks and make them faster, which, in the case of interpreted languages, you then write those small parts in C using whatever C interface is provided.
Everyone knows it's a mistake to write your whole program by hand in machine language. What's less often understood is that there is a more general principle here: that if you have a choice of several languages, it is, all other things being equal, a mistake to program in anything but the most powerful one.
Write in C and assembly when you really need the raw power, such as when you are writing some kind of data compressor or high-precision scientific simulation. For everything else, use a more powerful, higher level language -- especially when doing lots of text processing. You will be done faster and with fewer bugs and security holes.
The reason we have so many interpreters is because no one can agree on which language is the most powerful.
It is possible to remain both anonymous and authenticate yourself at the same time. An example that comes from Freenet, let's say you want to blog anonymously -- that is, no one knows your true identity -- under some pen name but you don't want other people running around claiming to be you under your blogging pseudonym. You can use digital signatures to prove your identity by signing all your blog posts and any other information you post. This way, only the person with the secret key, which is the true identity behind the pen name, can generate such a signature.
Over time, people can come to trust the pseudonym. You now have total anonymity and privacy along with security.
It may be much harder to achieve similar results in other systems, but here is at least one case where you can have your cake and eat it too.
Slashdot Mirror
Under dutch jurisprudence a "good" is something that is "owned by" someone and that has a value to the person that owns it.
Given the context of the conversation, don't you mean "pwned by"?
It is simply impossible to implement DRM with free software because DRM relies entirely on security by obscurity. The DRM system can hold no secrets from the user because the user (read: the user's computer) needs to know everything in order to decrypt and access the media. Breaking DRM is a matter of finding the obscured information that is already available.
As it was already pointed out by example, in being transparent and showing the source code there no way to obscure any information, unlike a proprietary system that is only available in an obscured, compiled form.
So someone was either confused or tricked here. The marketing double-speak quoted in TFA seems to indicate the latter.
Conceptually, the size of the code is how many different things -- variables, blocks of code -- a developer has to think about and keep track of in his head. For a metric, I would parse the code, then count how many nodes there are in the parse tree, or look at the depth or width of the parse tree. This gets around all of the actual formatting of the code and ignores comments.
It still wouldn't be very strong. If someone wanted to artificially inflate code, they could easily refactor in a bunch of new variables, which wouldn't do anything but add conceptual load to do code, making it worse. This operation is a feature in most IDEs.
I was wondering this as well. Going undercover as a gang biker's girlfriend seems like a really nasty, dirty job.
Think Mike Rowe will give it a shot sometime?
Ah, I see 1.5 came out in June, which was after I stopped following Subversion's development. For at least a couple of years, they had been promising merge tracking was coming, so I assumed it was still just a promise. However, the version we use where I work, and will use for a long while still, is older than 1.5, so standard procedure right now is to just not branch.
Thanks for pointing this out! I stand corrected.
I really did love Subversion for awhile, especially once it freed me from the mess that is CVS. It was a huge improvement no doubt. However, moving to Git is that same huge leap of improvement, and, for me, looking back at Subversion from Git is like looking back at CVS from Subversion.
I keep a copy of Applied Cryptography, Second Edition by my bed. Looking right now, on page 461, section 19.1.
The concept of public key-cryptography was invented by Whitfield Diffie and Martin Hellman, and independantly by Ralph Merkle.
So your own source says otherwise. :-P
However, on page 31, section 2.5, it says that the NSA claims it came up with it back in 1966, ten years earlier, but they offer no proof. I have read this book cover to cover, and I don't remember seeing anything about the British secret service and public-key cryptography.
Sheesh tagging and branching really is the weak point of CVS while SVN does both pretty well!
To say Subversion is pretty good at branching is to say you are pretty good at sex because you know how to put on a condom.
Subversion branching is easy, constant time O(1) operation, but the real work is in merging, which Subversion completely fails at. Currently, all merging must be manually tracked separately from Subversion itself. Branches are a last resort in Subversion, while they are commonplace in better equipped VCSs.
but it doesn't mean much when SVN's handling of merges is so primitive.
Precisely. I like this think of it this way: Einstein said "Make everything as simple as possible, but not simpler." When Subversion tried to be elegantly simple by having tagging and branching be exactly same operation as cheap copies, they went too simple.
Wikipedia is the search for fact, not truth. If it's truth you're looking for, Dr. Tyree's philosophy class is right down the hall.
You have a load of data which resides on your filesystem (basically a full repo copy) while SVN keeps only parts of the metadata locally.
Something very interesting about that is that Git clones generally smaller than the equivalent Subversion checkout. To see how these look, I made clones of several large project Subversion repos, including Freeciv (~15000 revisions) and Ruby (~36000 revisions), using git-svn, then did a "git gc" on it to pack it all together nice and tight. Cloning from Subversion is very slow so this can take a few days to complete. Next, I did a separate normal svn checkout.
In all cases I looked at, the Git clone, which contains the entire repository in full, was actually smaller than the single revision Subversion checkout. And this was just with the default "git gc" settings. So, if someone is making a point that the size of the checkout is a factor -- probably assuming a repository clone will be bigger -- Git actually wins it.
For many people, all they use their computer for is the web browser
Same for me with my work computer!
Katz tries to appeal to the more general public
Unfortunately, appealing to the general public is a lowest common denominator thing, and, in the end, it tends to create boring, worthless garbage like Garfield and Family Circus.
Freenet has distributed (by its nature), anonymous, uncensorable forum software. I wonder if they will go/have gone that route.
Possible tag: shootingfishinabarrel ?
My sarcasm detector didn't go off, so, to me, it seems that you are quite serious.
You are completely wrong, as both of them are part of the "protect the children" rhetoric/bullshit. They both co-sponsored this load of bullshit (KIDSPA). The fact that the next president of the US is going be so completely devoid of reason to support such a thing is scary.
criminals ripping off other criminals runs rampant
Are you saying there really is no honor among thieves?
This was devised long ago as something called spook words. In fact emacs has a spook function specifically for this purpose. Tag them on the end of your e-mail or IM or whatever. If enough people do this then they break the filters, kind of like spammers with Bayesian poisoning.
STARLAN ASIO ASO quiche world domination bemd Leitrim Crypto AG Croatian SP4 SSL Jiang Zemin CIA Centro afsatcom
But the duress key decrypts the same data to war and peace (or whatever you think appropriate).
I would use something legal and unincriminating, but possibly embarrassing, like pornography. That way the encryption would seem much more plausible; the nastier the porn the more plausible it is.
There aren't degrees of validity.
With XHTML, there are two different types of validation, "strict" and "transitional" (more casual allowing some old-style things). And one may argue, from some certain point of view, that these might be degrees of compliance to XHTML.
The closing tags for <p> elements are optional and the <br> element type is empty.
This is true for plain old HTML4, however the newer (and arguably improved) XHTML standard is a bit more strict about it. The XHTML specs, section 4.3 it says "For non-empty elements, end tags are required" and in 4.6 "Empty elements must either have an end tag or the start tag must end with />." That is, for both strict and transitional, all <p> tags must be closed with a closing </p> tag, and <br> is not allowed without either a closing tag or instead as closed start tag, <br/>.
Now, most browsers won't choke on not closing your paragraph tags and will get along as if you did close them, probably due in great part to HTML4, which is why the grandparent doesn't bother with it, but this doesn't really make it a standard. Implementation defined behavior is not a good way to go about things if you want to have many different compatible browsers (for example, this is why there is only one Perl5 interpreter), because different browsers may choose different ways to handle the ambiguous code.
I don't have a television so the only way for me to watch it is online.
And yes, I have seen that Onion article.
Your key smashing doesn't produce as much entropy as you think. In fact, there is very little entropy in there at all (there are patterns and many repeated characters), and is probably equivalent to just a few randomly generated printable characters.
However, it is true that you don't need software to generate a good password. Use Diceware.
When I saw one of them was called "Home" I assumed this was the Microsoft one, as they have a history of hijacking common words for their products (Word, Works, Windows, etc.), which has even caused trouble for them in the past (paying Linspire millions in a settlement). However, I see that it is actually Sony's that is called "Home". Hmm...
Border guards aren't that stupid, most of them are halfway decent people, but they've got fairly broad ranging powers and nobody likes a smart ass.
Only new chum would be on Authority payroll.
As a Debian user who always starts from the bare bones install and apt-gets my way to ideal, I agree with you that the base install shouldn't include Python. The base install is an example of something we want to be tight and small.
However, not everything worth writing should be written in C.
In general, writing C is expensive, compared to interpreted languages. More bugs need to be ironed out. There are portability issues, so moving to each new architecture or platform takes more and more effort. The program is longer and more complicated. And, worst of all, you are repeating a lot of work other people have already done. In the end, your C program is going to be tighter and faster than the interpreted one, but at what cost? And what have you gained? The user will not be able to notice the difference between 10ms and 100ms run times. Most desktop software spends almost all of its time waiting on I/O (this includes user input), and there is pretty much nothing that can be done (software-wise) to make I/O faster. Meatspace is too slow.
The interpreted version is usually fast enough and it's easier to write and maintain. To use your example, writing a build system in C is premature optimization, and the general rule for that is Don't Do It. Programs have bottlenecks, which cannot be found until you are done. If you really need speed, use a good profiler to find those bottlenecks and make them faster, which, in the case of interpreted languages, you then write those small parts in C using whatever C interface is provided.
To quote Paul Graham,
Everyone knows it's a mistake to write your whole program by hand in machine language. What's less often understood is that there is a more general principle here: that if you have a choice of several languages, it is, all other things being equal, a mistake to program in anything but the most powerful one.
Write in C and assembly when you really need the raw power, such as when you are writing some kind of data compressor or high-precision scientific simulation. For everything else, use a more powerful, higher level language -- especially when doing lots of text processing. You will be done faster and with fewer bugs and security holes.
The reason we have so many interpreters is because no one can agree on which language is the most powerful.
It is possible to remain both anonymous and authenticate yourself at the same time. An example that comes from Freenet, let's say you want to blog anonymously -- that is, no one knows your true identity -- under some pen name but you don't want other people running around claiming to be you under your blogging pseudonym. You can use digital signatures to prove your identity by signing all your blog posts and any other information you post. This way, only the person with the secret key, which is the true identity behind the pen name, can generate such a signature.
Over time, people can come to trust the pseudonym. You now have total anonymity and privacy along with security.
It may be much harder to achieve similar results in other systems, but here is at least one case where you can have your cake and eat it too.