Can someone explain to me how defacing this website makes piracy less wrong? Does this mean that if I find an overlooked cgi on fsf.org that I can consequently justify violating the GPL?
Not at all, you can add value in many ways, just not by forking the code.
There are a multitude of ways a developer can coexist with an existing codebase and forking is just one of these days. A developer can enhance code without forking or a developer can take only a small portion of a codebase and use just the bits which are relevant to their needs. The notion that the goals and desires of commercial development is simply to take GPL'd code and fork it is not at all accurate.
the GPL restrictions are there in order to protect the original author of a work
This is absolutely false. The original author and all subsequent contributors have NO rights and protection under the GPL. In fact, the GPL is stated as having been created to protect users from the rights of developers. It is about protecting the users' Freedom, not developers'.
A developer releasing code under the GPL gives away exactly the same rights and has exactly the same degree of "protection" as a developer who releases code into the public domain or a BSD-style defensive license. The unique aspect of the GPL is that it restricts the potential benefactors of the "sharing" to a smaller set of people since a nonzero number of users and developers will be unable to accomodate the restrictions imposed by the GPL.
Dragging this thread kicking and screaming back towards the topic, Apple NICs do. There's no need to use a crossover cable with a recent-generation Mac box or laptop.
How can a new improvement to code "stay" anything? It's new. Its state is undetermined.
The original code "stays" free, of course, since the free version still exists. The improvement, however, is the product of the labor of a third party who should be given the opportunity to choose how their code is licensed.
I fail to see how this is oxymoronical. Might not be accurate, but the statement is perfectly consistent. Think for a few minutes on what the word "total" is doing in the phrase "total cost of ownership".
strange, since I've always considered speed and economy of interface to be one of pine's weakest points. It's about the least efficient and most cumbersome interface I've used.
I still say that pine is the Outlook Express of unix mail readers:
They both focus on ease of learning at the expense of ease of use.
They're both preferred by relatively inexperienced users and win mainly due to "first exposure" intertia
The users of both appear to believe that theirs is the only similar email client. ("I like pine because I can ")
Pine embraces the Windows philosophy of monolithic applications by bundline an editor and a newsreader into the mail reader. Very un-unix.
Perhaps you meant to say "instance", not "implementation". In either case, my point stands.
Sure, switch to seti...
on
RC5-64 Success
·
· Score: 3, Funny
You just wait and see who has the last laugh when SETI@home manages to detect an alien signal only to discover that it's rc5 encrypted!:)
Re:I think many posters here are missing the point
on
RC5-64 Success
·
· Score: 2
This isn't strictly true. I think a strong case can be made that public challenges like this are very effective in driving the development of innovative or simply incrementally more efficient approaches to an algorithim's implementation.
Although CPU speeds are significantly faster now than when they were in 1997 when RSA announced the secret key challenges we've also gotten a lot better at optimizing rc5 in software.
Innovations like Kwan's bitsliced/sbox approach to DES are revolutionary and driven in part by the motivation created by public challenges such as the RSA Labs' contests.
I don't accept your statement that the existence of or participation in these public projects in any way reduces the chances that someone will discover a weakness in the underlying algorithm. If anything, it's more likely since optimized implementations of an algorithim such as we see in dnetc generate more interest and consequently more people becoming familiar with the mathematics.
Peter Trei (the RSA mind behind the secret key challenges and the article submitter for this story) explains that the secret key challenges (DES, RC5-foo) were designed to mimic the structure of an attack on captured IPSEC traffic where one could similarly search for valid or recognizable header information.
Rather than being an unrealistic excercise, the method used to brute-force the RC5-64 and other RSA Labs secret key challenges is actually relevant for this very reason.
The scenario is not as improbable as you imply.
Re:are you going to the meetup?
on
RC5-64 Success
·
· Score: 2
There is no "guy who made distributed.net" -- it is and has always been a collaborative effort and the product of many people's time, energy, and dedication. Even cow, himself, the reason the project was named the "Bovine RC5 Effort" (in February 1997) doesn't try to take credit for it.
Re:all I want to say now is
on
RC5-64 Success
·
· Score: 2
Now I'm glad I shaved today and wore a (relatively) nice shirt.
an interesting bit of trivia
on
RC5-64 Success
·
· Score: 5, Interesting
While the prospect of a false-positive key was the subject of much speculation during RC5-56, we did in fact encounter exactly such a beast during RC5-64.
In the interests of speed, only the first "block" of the crypted text is decrypted and evaluated for a solution. This means that it's possible for a key which isn't the correct key to report as a false positive because although it doesn't decrypt the text it does yield a plaintext which matches "The unkn" for the first eight bytes.
There's been much speculation and napkin scribbling on just how frequently such false positives might present themselves. The general consensus seemed to be that such an occurrence is extremely improbable but in a dataset the size of 2**64, extremely improbable may still yield a nonzero frequency.
The key 0xBB27D52F60FD932C does, indeed, decrypt to a plaintext for which the first eight bytes match the known plaintext for the contest. The remainder of the decrypted text, however, is just garbage. This key has actually been returned by clients twice over the course of the contest.
Again in July 2000, Team RC5 Chile submitted it. Since they're unfortunately using a shared email address for their team, there's no way to know which individual was the submitter.
I wasn't the winning key, but was a really unique "near miss". It also represents an interesting datapoint regarding the RC5 algorighim. A brute-force search is really the only way to conclusively determine the liklihood of such false positives.
So basically you're saying that it's acceptable for Linux's "stable" branch to be unstable and for it to frequently introduce catastrophic bugs and instability because, after all, everyone knows better than to expect it to be stable and deployable?
That's a rather forgiving and rose-coloured perspective.
Whoever told you that the "old BBS days" involved 2400 baud modems should be shot. If it didn't involve an acoustic coupler, it's not worth talking about.
In any event, recalibrate your sarcasm detector -- the original poster clearly knew the joke.
Yeah, the really big deal is that the stock firmware in the Archos is so abysmally crappy as to make the unit nearly unusable. It's tragically full of quirks and bugs and limitations.
As an Archos 20 owner I find this project immensely encouraging and hope that it will soon be in a position to make this Archos unit of mine desirable. As it stands, I hardly use the thing because it's so frustrating.
The unit is not without its frustrations, though. For instance, the only way to shuffle tracks in different directories is to create a playlist using the supplied Windows software. However, a playlist is limited to just 999 tracks. With 20Gb of space, 999 seems like a very short-sighted limit for playlisting. The first thing I wanted to do with the unit was to create an "all tracks" playlist in order to shuffle all the tracks. Can't be done. One positive note: The playlists are simply text files, one filename per line with relative pathing. A soon as I figured that out, I ditched the visually-appealing but typically unstable windows MusicMatch software supplied with the unit.
The front-panel user interface is even worse. You can tell this thing was designed by the programmers. Even though it does what it needs, the designers seemed to choose the least obvious, most cumbersome route to each feature. The insanity of having to press right and left on the navigation disk to scroll up and down through the setup menus is just the beginning.
I'm with you right up until the last part. You don't have to look too far back in history to see exactly what the world looks like without strong IP protection on software. This is effectively the exact situation we lived in up until the early 80's when IP law caught up software. Prior to then it was very unclear what, if any, protections were afforded software by IP law.
We did not, contrary to the utopian view, have a world of sharing where programers lived off nuts and berries and gave their work to the world gratis. Rather we had a motley assortment of miserable copy protection mechanisms, dongles, and constraining usage agreement contracts. The lack of IP protection doesn't add any more generosity to the world it merely forces the people who wish to earn a living by producing valuable software to find other mechanisms (like contract law and hardware protection) with which they can protect the value they've created.
Slashdot Mirror
But 99.999% of people will never own a patent...
I see no real problem here, since 99.999% of people will never have a genuinely novel or useful idea that's deserving of patent protection.
Can someone explain to me how defacing this website makes piracy less wrong? Does this mean that if I find an overlooked cgi on fsf.org that I can consequently justify violating the GPL?
Not at all, you can add value in many ways, just not by forking the code.
There are a multitude of ways a developer can coexist with an existing codebase and forking is just one of these days. A developer can enhance code without forking or a developer can take only a small portion of a codebase and use just the bits which are relevant to their needs. The notion that the goals and desires of commercial development is simply to take GPL'd code and fork it is not at all accurate.
the GPL restrictions are there in order to protect the original author of a work
This is absolutely false. The original author and all subsequent contributors have NO rights and protection under the GPL. In fact, the GPL is stated as having been created to protect users from the rights of developers. It is about protecting the users' Freedom, not developers'.
A developer releasing code under the GPL gives away exactly the same rights and has exactly the same degree of "protection" as a developer who releases code into the public domain or a BSD-style defensive license. The unique aspect of the GPL is that it restricts the potential benefactors of the "sharing" to a smaller set of people since a nonzero number of users and developers will be unable to accomodate the restrictions imposed by the GPL.
Dragging this thread kicking and screaming back towards the topic, Apple NICs do. There's no need to use a crossover cable with a recent-generation Mac box or laptop.
How can a new improvement to code "stay" anything? It's new. Its state is undetermined.
The original code "stays" free, of course, since the free version still exists. The improvement, however, is the product of the labor of a third party who should be given the opportunity to choose how their code is licensed.
Linux is poo.
I fail to see how this is oxymoronical. Might not be accurate, but the statement is perfectly consistent. Think for a few minutes on what the word "total" is doing in the phrase "total cost of ownership".
I still say that pine is the Outlook Express of unix mail readers:
They both focus on ease of learning at the expense of ease of use.
They're both preferred by relatively inexperienced users and win mainly due to "first exposure" intertia
The users of both appear to believe that theirs is the only similar email client. ("I like pine because I can ")
Pine embraces the Windows philosophy of monolithic applications by bundline an editor and a newsreader into the mail reader. Very un-unix.
Try mutt, you'll never look back.
pine: people ignorant of newer emailers.
Perhaps you meant to say "instance", not "implementation". In either case, my point stands.
You just wait and see who has the last laugh when SETI@home manages to detect an alien signal only to discover that it's rc5 encrypted! :)
This isn't strictly true. I think a strong case can be made that public challenges like this are very effective in driving the development of innovative or simply incrementally more efficient approaches to an algorithim's implementation.
Although CPU speeds are significantly faster now than when they were in 1997 when RSA announced the secret key challenges we've also gotten a lot better at optimizing rc5 in software.
Innovations like Kwan's bitsliced/sbox approach to DES are revolutionary and driven in part by the motivation created by public challenges such as the RSA Labs' contests.
I don't accept your statement that the existence of or participation in these public projects in any way reduces the chances that someone will discover a weakness in the underlying algorithm. If anything, it's more likely since optimized implementations of an algorithim such as we see in dnetc generate more interest and consequently more people becoming familiar with the mathematics.
Peter Trei (the RSA mind behind the secret key challenges and the article submitter for this story) explains that the secret key challenges (DES, RC5-foo) were designed to mimic the structure of an attack on captured IPSEC traffic where one could similarly search for valid or recognizable header information.
Rather than being an unrealistic excercise, the method used to brute-force the RC5-64 and other RSA Labs secret key challenges is actually relevant for this very reason.
The scenario is not as improbable as you imply.
There is no "guy who made distributed.net" -- it is and has always been a collaborative effort and the product of many people's time, energy, and dedication. Even cow, himself, the reason the project was named the "Bovine RC5 Effort" (in February 1997) doesn't try to take credit for it.
Cows are cool. ]:8)
Now I'm glad I shaved today and wore a (relatively) nice shirt.
In the interests of speed, only the first "block" of the crypted text is decrypted and evaluated for a solution. This means that it's possible for a key which isn't the correct key to report as a false positive because although it doesn't decrypt the text it does yield a plaintext which matches "The unkn" for the first eight bytes.
There's been much speculation and napkin scribbling on just how frequently such false positives might present themselves. The general consensus seemed to be that such an occurrence is extremely improbable but in a dataset the size of 2**64, extremely improbable may still yield a nonzero frequency.
The key 0xBB27D52F60FD932C does, indeed, decrypt to a plaintext for which the first eight bytes match the known plaintext for the contest. The remainder of the decrypted text, however, is just garbage. This key has actually been returned by clients twice over the course of the contest.
In August 1999, "Edward Scissorhands" turned in the key.
Again in July 2000, Team RC5 Chile submitted it. Since they're unfortunately using a shared email address for their team, there's no way to know which individual was the submitter.
I wasn't the winning key, but was a really unique "near miss". It also represents an interesting datapoint regarding the RC5 algorighim. A brute-force search is really the only way to conclusively determine the liklihood of such false positives.
So basically you're saying that it's acceptable for Linux's "stable" branch to be unstable and for it to frequently introduce catastrophic bugs and instability because, after all, everyone knows better than to expect it to be stable and deployable?
That's a rather forgiving and rose-coloured perspective.
It's cool!
What the world needs is more Mojo.
Another problem is that you need license which is like a gpl for fonts
What's wrong with public domain? That fits all your criteria and we've had it as an option forever.
Search for an artist, if they don't have any tracks by the artist online, they'll recommend similar indie artists that they do have.
Whoever told you that the "old BBS days" involved 2400 baud modems should be shot. If it didn't involve an acoustic coupler, it's not worth talking about.
In any event, recalibrate your sarcasm detector -- the original poster clearly knew the joke.
As an Archos 20 owner I find this project immensely encouraging and hope that it will soon be in a position to make this Archos unit of mine desirable. As it stands, I hardly use the thing because it's so frustrating.
To quote from my epinions review:
I'm with you right up until the last part. You don't have to look too far back in history to see exactly what the world looks like without strong IP protection on software. This is effectively the exact situation we lived in up until the early 80's when IP law caught up software. Prior to then it was very unclear what, if any, protections were afforded software by IP law.
We did not, contrary to the utopian view, have a world of sharing where programers lived off nuts and berries and gave their work to the world gratis. Rather we had a motley assortment of miserable copy protection mechanisms, dongles, and constraining usage agreement contracts. The lack of IP protection doesn't add any more generosity to the world it merely forces the people who wish to earn a living by producing valuable software to find other mechanisms (like contract law and hardware protection) with which they can protect the value they've created.