The GPL says (in clause 9) that the other party (the one getting the licence) can choose to switch to a later version of the license if they so choose. If they don't want to switch, then they don't have to.
However, if portions GPL v2, for example, were struck down, then people would be left without a legal licence. But if the license switching part were left intact (which it probably would since it allows users even more rights) then as soon as the FSF releases GPL v4, everyone can switch to that, and regain whatever rights the FSF grants them in GPL v4.
The GPL is actually very interesting reading. I personally like the clause (# 5) that spells out that the licence, and only the licence, is the only thing that gives you the right to redistribute and modify the software, and if you don't agree to the GPL, then you don't have the right to redistribte and modify the software (as per your default rights under the GPL).
Overall, for what it's goals are, it is very well spelt out, and takes into consideration most of the scenarios that people have suggested could 'break' it.
A friend of mine is in charge of the public database of genes here at Washington University, St. Louis. Just about everything the HGP researchers sequence ends up in that database by the end of the day. And he has over a gig of log files generated by Celera grabbing everything off the server as soon as it comes out.
The general opinion of the HGP researchers seems to be that Celera is just posturing to keep their stock up. HGP is very close to finishing, and Celera figures that they've alread patented everything that they can. So, really, the Celera announcement should be read as "We've decided to stop now because spending more money on finding stuff would be a waste and generate bad returns."
But I do have privacy when I walk into a store in the mall, simply because nobody at the mall knows who I am. But if the P3P protpcal is implemented, tying some random IP number to my name, address, phone number, SSN, and credit card data can all happen automatically. Privacy isn't so much about doing stuff anonymously, but the inability of others to tie information about you together.
So now Rob knows that there is a guy whose nick is cannes, who (supposedly) buys porno every once in a while, and has a fake email address of fuzz_face_05@hotmail.com. He also knows at least one valid email address tied to that nick. But that's about it. The hotmail account (probably real) has very little to no attachment to some real person.
Rob doesn't know where you live. He doesn't know what your specific tastes in porn are, or what other products you buy. He doesn't know your phone number, your credit card, or your bank account numbers. He has no idea what your income is, whether you are married, have kids, and if so, how many. But if P3P is implemented, he could find out all of that with little difficulty.
The danger of that is that then Rob can do some very mean things. If Rob was a perspective employer, he could not hire you because he has issues with pron. As a bank, he could deny you a loan, or give you a worse interest rate. He could even pretend to be you, getting credit cards in your name, or use your name as a cover for criminal acts, since this information is the way you validate your identity to the rest of the world.
Each individual bit of information is worthless. All of it together has a lot more worth, and is a lot more dangerous to give away.
You only need to forward everything through the clients if both sides want to be totally anonomous. If the reciever doesn't mind being known, then the sender can send directly to them using forged IP headers. Then the error-correction can be forwarded back to the sender through the clients. If the sender doesn't mind being known, but the reciever wants to hide, then the actual files must be forwarded, but the error correction can go directly. This would much faster for the case where the reciever doesn't care, and marginally faster when only the sender doesn't care.
I'm fairly sure it would be possible to set a distributed filesystem like Gnutella up so that people never know who they are recieving from, only who they are sending to (for forwarding). That would make tracking just about impossible.
RSA was patented, not copywrited. Patents are entirely different.
Re:Can someone give 1 good reason to use C++ over
on
Who's Afraid Of C++?
·
· Score: 1
That won't cut it on a RISC machine. A good optimizer for a RISC machine can generally produce machine code 20% faster than hand-optimized assembly. And even on CISC machines, a human can't keep track of all of the scheduling constraints to meet your data dependancies while keeping the pipeline full. It just gets harder on a EPIC processor.
On the other hand, C++ code is generally a bit harder to optimize, given that the global optimizer is written to work best in a C-like language. But most C++ code is valid C anyway, and there are global optimizers tuned to OO code, so it really doesn't matter.
Re:Can someone give 1 good reason to use C++ over
on
Who's Afraid Of C++?
·
· Score: 1
If you get gcc from gnu.org, and make it yourself, it installs multiple different binaries (gcc, g++, g77 (for fortran), etc).
By the same token, on some systems cc is just a link to c++ (since the c++ compiler can always handle c, but a cc compiler can't always handle c++).
Re:Can someone give 1 good reason to use C++ over
on
Who's Afraid Of C++?
·
· Score: 1
How about g++ as a workaround to annoying admins.
I've had admins disable gcc because it's a "security hole" and leave the system nearly useless for users. However, very rarely have I come across g++ disabled.
On the other hand, one overly bright admin just disabled the linker...
Re:Can someone give 1 good reason to use C++ over
on
Who's Afraid Of C++?
·
· Score: 1
If you are using strict ANSI C, variables must be declared at the beginning of the block. This means you can't go:
for(int i = 0; i < 10; i++){ //Do stuff }
Also, <<, >>, new, and delete are much easier to use, and fancy data constructs are much easier to code OO. Besides the fact that the STL already has most of what you need anyway.
If you code in C++, you don't have to do a bunch of fancy OO stuff if you don't want to, but it does give you the option. Every C program is a valid C++ program (except for a bit of funny stuff that was a mistake in the first place).
While the x86 instruction set might be hairy, dumping it wouldn't make designing processors any simpler. Modern processors have so much complexity they are nearly impossible to understand in their entirety.
First off, they are all pipelined. So now you have all sorts of problems with branching. The good chips have branch prediction hardware. Then they have hardware to deal with missed predictions. Now there's hardware to take both branches and dump the incorrect result. Also, to the most speed out of pipelining, you need to reorder the instructions. So there's hardware to find read data dependancies, write data dependencies, and register dependancies. And if you branch, it's screwed.
They have an I cache and a D cache, so their's hardware to manage the translation between those, hardware to make sure reads and writes reflect the actual values, hardware to predict what needs to be loaded, and hardware to choose what's the best thing to throw out. And if you branch, it's screwed.
Not only are they pipelined, but they have multiple execution paths (at least an i path and an f path, but sometimes more than one). So you're issuing more than one instruction at a time, besides just pipelining it. Some paths can only take certian types of instructions. Some instructions requre the use of other execution units which are in limited supply. You have to add hardware to reorder the instructions to keep all of the paths full, otherwise you aren't squeezing enough performance out. And if you branch, it's screwed.
Now there's secondary and event tertiary levels of caching. So there's hardware to handle that. There's hardware to handle block access patterns, hardware to handle streaming access patterns, and hardware to figure out which of the two will give youthe best performance. There's even pipelined RAM. And if you branch, it's screwed.
You might bash the x86 ISA, but dumping it isn't a cure-all. In any case, the designers have been very clever. All of the nasty instructions that are almost never used and are hard for compilers to take advantage of have been getting slower and slower. Sure, the x86 has loads of instructions. But the ones that run really fast, and get used a lot by compilers, are mostly just the ones that you'd find in the most asture RISC ISAs.
>The unsuccessful are rewarded, and the successful are put to death.
The point of anti-trust law is not that large successful companies are bad, but that large successful companies can use their size bully their competitors, throw up barriers to entry, stifle innovation, and generally be not very nice.
>No longer is the consumer important, but just its competitors.
The ruling recognizes the fact that Microsoft was acting to the detriment of consumers and of market forces. To violate anti-trust law you have to be hurting consumers (killing Dr. Dos, trying to kill Netscape, price fixing, compelling OEMs to exclucively carry their product, forced product bundling, etc.).
>No longer is innovation lauded, but persecuted.
So driving Dr. Dos into the ground wasn't persecution? Burying DESCView was lauding innovation? Blocking startups from entering the playing field increases innovation? Hell's frozen over as well then?
>No longer is technology guided by the marketplace, but on the whims of its competitors.
Other way around. Now technology may (finally) be guided by the marketplace, rather than on the whims of Microsoft.
You make a good point about how the encoder makes a big difference. Everything I've ever encoded has either been with Fraunhoffer (sp?) or lame, and I can't tell the difference between the real thing and the copy at 128 (I even bothered doing a blind randomized test to see if I could). On the other hand, some stuff my brother encoded with MediaJukebox (I think) sounded terrible, even at 160.
Anybody who has trouble with 128s should just use a better encoder. Go out and buy Fraunhoffer, or download lame. Unless of course you're one of those horrible people causing trouble for the rest of us by stealing all of your music. In which case you deserve all the compression artifacts one can stuff into 128k.
As somebody else has already said, it is quite a bit better than LP videotape. However, I don't think that it is up to snuff to SP videotape. If you sit back a bit from the monitor there isn't really anything noticably bad with it. If you sit a bit closer though (as close as I usually sit from my monitor) you can pick out the compression artifacts. Some of them get pretty bad in action intensive sequences. However, the framerate holds up just fine regardless.
So far as compression ratio, I don't know exactly, but what I was watching was the Matrix ripped from the DVD onto a single CD-R. There was enough spare room on the CD-R to hold the CD-soundtrack as well, and a small bit of other stuff. I guess that would mean that "Saving Private Ryan" in under 350 Mb would look pretty bad compared to the original. Of course, I'm a little picky about a lack of compression artifacts (they jump out at me). So if I was a movie industry exec, I wouldn't get too worried about massive copying of movies using Div-X (although, I suppose if I was an industry exec, I'd be worried about 9th generation copies of somebody taking a camcorder into the theatre with them, so...)
In any case, the problem isn't going to be transmitting these over the internet (350 meg is a lot to transfer to see a crappy copy of a movie). The big problem is going to be on college campuses, where a profusion of burners and 100mB/sec ethernet makes swapping a couple of gigabytes of files fairly trivial. The copy of the Matrix I saw was legal (space shifting by the owner), but I know that a lot of other movies are available on campus ethernet. I know that at least the Matrix, American Pie, The Phantom Menace, and South Park were all available near the beginning of the semester last year. I have no clue how much stuff will be up next year, but I don't think most people will be heading out to blockbuster to get their favorite movies...
>So does Emacs on Windows or X. It feels like Notepad with different key bindings, and even those can be remapped.
While it may seem nice at first glance, don't do that. Ctrl-C should be the command to kill a process, not the command to copy.
GNU Emacs is much more powerful that notepad. Notepad is nice because it is so lightweight, but I'd never want to give up the flexibility of arbitrary macros.
M-x load-lib arbitrary_macro M-x arbitrary_macro
And does notepad come with tetris and a web browser? I think not.
In order to get certified, you have to turn over your source. The gov't will sign an NDA, but you are still required to turn over your source. Also, to get the higher level security ratings they require you to provide "assurances" that your code is secure, along with additional security features. For the highest level (A1) you have to submidt a formal proof that your system is secure, and have written your code in such a way that they can veriry your prood easily.
There's a good reason why there are no A1 rated OS's (commercial, at least).
Actually, they don't have to worry about that one. The french economy is already collapsed, and you'd probably have to work pretty hard to make it any worse.
Actually, the Nintendo patent doens't appear to be all bad. From what I can tell, it is just a design patent. Therefore, an *almost* identical connecter with just the most superficial changes (say, make the 'handle' part of the plug squareish) would not fall under this patent.
It's just that Nintendo doesn't want other people making perfect duplicates of their connector. They aren't preventing compatable connectors, though.
Slashdot Mirror
The GPL says (in clause 9) that the other party (the one getting the licence) can choose to switch to a later version of the license if they so choose. If they don't want to switch, then they don't have to.
However, if portions GPL v2, for example, were struck down, then people would be left without a legal licence. But if the license switching part were left intact (which it probably would since it allows users even more rights) then as soon as the FSF releases GPL v4, everyone can switch to that, and regain whatever rights the FSF grants them in GPL v4.
The GPL is actually very interesting reading. I personally like the clause (# 5) that spells out that the licence, and only the licence, is the only thing that gives you the right to redistribute and modify the software, and if you don't agree to the GPL, then you don't have the right to redistribte and modify the software (as per your default rights under the GPL).
Overall, for what it's goals are, it is very well spelt out, and takes into consideration most of the scenarios that people have suggested could 'break' it.
Celera does download it every night.
A friend of mine is in charge of the public database of genes here at Washington University, St. Louis. Just about everything the HGP researchers sequence ends up in that database by the end of the day. And he has over a gig of log files generated by Celera grabbing everything off the server as soon as it comes out.
The general opinion of the HGP researchers seems to be that Celera is just posturing to keep their stock up. HGP is very close to finishing, and Celera figures that they've alread patented everything that they can. So, really, the Celera announcement should be read as "We've decided to stop now because spending more money on finding stuff would be a waste and generate bad returns."
aitch tee tee pee colon slash slash slashdot dot org
dot dot station
Hmm.. I wonder who their target audience could possible be?
But I do have privacy when I walk into a store in the mall, simply because nobody at the mall knows who I am. But if the P3P protpcal is implemented, tying some random IP number to my name, address, phone number, SSN, and credit card data can all happen automatically. Privacy isn't so much about doing stuff anonymously, but the inability of others to tie information about you together.
So now Rob knows that there is a guy whose nick is cannes, who (supposedly) buys porno every once in a while, and has a fake email address of fuzz_face_05@hotmail.com. He also knows at least one valid email address tied to that nick. But that's about it. The hotmail account (probably real) has very little to no attachment to some real person.
Rob doesn't know where you live. He doesn't know what your specific tastes in porn are, or what other products you buy. He doesn't know your phone number, your credit card, or your bank account numbers. He has no idea what your income is, whether you are married, have kids, and if so, how many. But if P3P is implemented, he could find out all of that with little difficulty.
The danger of that is that then Rob can do some very mean things. If Rob was a perspective employer, he could not hire you because he has issues with pron. As a bank, he could deny you a loan, or give you a worse interest rate. He could even pretend to be you, getting credit cards in your name, or use your name as a cover for criminal acts, since this information is the way you validate your identity to the rest of the world.
Each individual bit of information is worthless. All of it together has a lot more worth, and is a lot more dangerous to give away.
You only need to forward everything through the clients if both sides want to be totally anonomous. If the reciever doesn't mind being known, then the sender can send directly to them using forged IP headers. Then the error-correction can be forwarded back to the sender through the clients. If the sender doesn't mind being known, but the reciever wants to hide, then the actual files must be forwarded, but the error correction can go directly. This would much faster for the case where the reciever doesn't care, and marginally faster when only the sender doesn't care.
I'm fairly sure it would be possible to set a distributed filesystem like Gnutella up so that people never know who they are recieving from, only who they are sending to (for forwarding). That would make tracking just about impossible.
RSA was patented, not copywrited. Patents are entirely different.
That won't cut it on a RISC machine. A good optimizer for a RISC machine can generally produce machine code 20% faster than hand-optimized assembly. And even on CISC machines, a human can't keep track of all of the scheduling constraints to meet your data dependancies while keeping the pipeline full. It just gets harder on a EPIC processor.
On the other hand, C++ code is generally a bit harder to optimize, given that the global optimizer is written to work best in a C-like language. But most C++ code is valid C anyway, and there are global optimizers tuned to OO code, so it really doesn't matter.
If you get gcc from gnu.org, and make it yourself, it installs multiple different binaries (gcc, g++, g77 (for fortran), etc).
By the same token, on some systems cc is just a link to c++ (since the c++ compiler can always handle c, but a cc compiler can't always handle c++).
How about g++ as a workaround to annoying admins.
I've had admins disable gcc because it's a "security hole" and leave the system nearly useless for users. However, very rarely have I come across g++ disabled.
On the other hand, one overly bright admin just disabled the linker...
If you are using strict ANSI C, variables must be declared at the beginning of the block. This means you can't go:
for(int i = 0; i < 10; i++){}
Also, <<, >>, new, and delete are much easier to use, and fancy data constructs are much easier to code OO. Besides the fact that the STL already has most of what you need anyway.
If you code in C++, you don't have to do a bunch of fancy OO stuff if you don't want to, but it does give you the option. Every C program is a valid C++ program (except for a bit of funny stuff that was a mistake in the first place).
Personally, I think that disbarring lawyers who file exessive frivilous lawsuits would work. Shouldn't that fall under unethical conduct anyway?
Adding more registers is an issue the designers have. There's nothing to keep them from adding additional registers, except that they don't want to.
As for the segmented addressing scheme, try the extended registers (eax, ebx, and so on) and 32-bit mode programming. Works much better.
While the x86 instruction set might be hairy, dumping it wouldn't make designing processors any simpler. Modern processors have so much complexity they are nearly impossible to understand in their entirety.
First off, they are all pipelined. So now you have all sorts of problems with branching. The good chips have branch prediction hardware. Then they have hardware to deal with missed predictions. Now there's hardware to take both branches and dump the incorrect result. Also, to the most speed out of pipelining, you need to reorder the instructions. So there's hardware to find read data dependancies, write data dependencies, and register dependancies. And if you branch, it's screwed.
They have an I cache and a D cache, so their's hardware to manage the translation between those, hardware to make sure reads and writes reflect the actual values, hardware to predict what needs to be loaded, and hardware to choose what's the best thing to throw out. And if you branch, it's screwed.
Not only are they pipelined, but they have multiple execution paths (at least an i path and an f path, but sometimes more than one). So you're issuing more than one instruction at a time, besides just pipelining it. Some paths can only take certian types of instructions. Some instructions requre the use of other execution units which are in limited supply. You have to add hardware to reorder the instructions to keep all of the paths full, otherwise you aren't squeezing enough performance out. And if you branch, it's screwed.
Now there's secondary and event tertiary levels of caching. So there's hardware to handle that. There's hardware to handle block access patterns, hardware to handle streaming access patterns, and hardware to figure out which of the two will give youthe best performance. There's even pipelined RAM. And if you branch, it's screwed.
You might bash the x86 ISA, but dumping it isn't a cure-all. In any case, the designers have been very clever. All of the nasty instructions that are almost never used and are hard for compilers to take advantage of have been getting slower and slower. Sure, the x86 has loads of instructions. But the ones that run really fast, and get used a lot by compilers, are mostly just the ones that you'd find in the most asture RISC ISAs.
Don't bash what works.
at least it kept John Travolta busy for a while, so he couldn't curse us with more terrible movies.
Maybe they want to increase their ranking on Distributed.net.
Maybe it's an experiment that got out of control.
Maybe pigs will fly.
Idiot.
>The unsuccessful are rewarded, and the successful are put to death.
The point of anti-trust law is not that large successful companies are bad, but that large successful companies can use their size bully their competitors, throw up barriers to entry, stifle innovation, and generally be not very nice.
>No longer is the consumer important, but just its competitors.
The ruling recognizes the fact that Microsoft was acting to the detriment of consumers and of market forces. To violate anti-trust law you have to be hurting consumers (killing Dr. Dos, trying to kill Netscape, price fixing, compelling OEMs to exclucively carry their product, forced product bundling, etc.).
>No longer is innovation lauded, but persecuted.
So driving Dr. Dos into the ground wasn't persecution? Burying DESCView was lauding innovation? Blocking startups from entering the playing field increases innovation? Hell's frozen over as well then?
>No longer is technology guided by the marketplace, but on the whims of its competitors.
Other way around. Now technology may (finally) be guided by the marketplace, rather than on the whims of Microsoft.
I feel the need to repeat myself: idiot.
You make a good point about how the encoder makes a big difference. Everything I've ever encoded has either been with Fraunhoffer (sp?) or lame, and I can't tell the difference between the real thing and the copy at 128 (I even bothered doing a blind randomized test to see if I could). On the other hand, some stuff my brother encoded with MediaJukebox (I think) sounded terrible, even at 160.
Anybody who has trouble with 128s should just use a better encoder. Go out and buy Fraunhoffer, or download lame. Unless of course you're one of those horrible people causing trouble for the rest of us by stealing all of your music. In which case you deserve all the compression artifacts one can stuff into 128k.
As somebody else has already said, it is quite a bit better than LP videotape. However, I don't think that it is up to snuff to SP videotape. If you sit back a bit from the monitor there isn't really anything noticably bad with it. If you sit a bit closer though (as close as I usually sit from my monitor) you can pick out the compression artifacts. Some of them get pretty bad in action intensive sequences. However, the framerate holds up just fine regardless.
So far as compression ratio, I don't know exactly, but what I was watching was the Matrix ripped from the DVD onto a single CD-R. There was enough spare room on the CD-R to hold the CD-soundtrack as well, and a small bit of other stuff. I guess that would mean that "Saving Private Ryan" in under 350 Mb would look pretty bad compared to the original. Of course, I'm a little picky about a lack of compression artifacts (they jump out at me). So if I was a movie industry exec, I wouldn't get too worried about massive copying of movies using Div-X (although, I suppose if I was an industry exec, I'd be worried about 9th generation copies of somebody taking a camcorder into the theatre with them, so...)
In any case, the problem isn't going to be transmitting these over the internet (350 meg is a lot to transfer to see a crappy copy of a movie). The big problem is going to be on college campuses, where a profusion of burners and 100mB/sec ethernet makes swapping a couple of gigabytes of files fairly trivial. The copy of the Matrix I saw was legal (space shifting by the owner), but I know that a lot of other movies are available on campus ethernet. I know that at least the Matrix, American Pie, The Phantom Menace, and South Park were all available near the beginning of the semester last year. I have no clue how much stuff will be up next year, but I don't think most people will be heading out to blockbuster to get their favorite movies...
>So does Emacs on Windows or X. It feels like Notepad with different key bindings, and even those can be remapped.
While it may seem nice at first glance, don't do that. Ctrl-C should be the command to kill a process, not the command to copy.
GNU Emacs is much more powerful that notepad. Notepad is nice because it is so lightweight, but I'd never want to give up the flexibility of arbitrary macros.
M-x load-lib
arbitrary_macro
M-x arbitrary_macro
And does notepad come with tetris and a web browser? I think not.
- Eighty Megs And COnstantly Swapping
In order to get certified, you have to turn over your source. The gov't will sign an NDA, but you are still required to turn over your source. Also, to get the higher level security ratings they require you to provide "assurances" that your code is secure, along with additional security features. For the highest level (A1) you have to submidt a formal proof that your system is secure, and have written your code in such a way that they can veriry your prood easily.
There's a good reason why there are no A1 rated OS's (commercial, at least).
>and I hope France's economy will collapse
Actually, they don't have to worry about that one.
The french economy is already collapsed, and you'd probably have to work pretty hard to make it any worse.
Actually, now that I think about it, another company does make connectors like this, except they don't have the little cosmetic indentation.
Actually, the Nintendo patent doens't appear to be all bad. From what I can tell, it is just a design patent. Therefore, an *almost* identical connecter with just the most superficial changes (say, make the 'handle' part of the plug squareish) would not fall under this patent.
It's just that Nintendo doesn't want other people making perfect duplicates of their connector. They aren't preventing compatable connectors, though.
It just goes to show you that most 'good guys' really aren't. I seriously doubt that he was ever in it for anything but the money.
Is it just me, or is the DNS system seriously messed up. What ever happened to a bit of common sense?
That makes an excellent poll question:
:)!!
What would you do with a free computer from Intel?
Definately the doorstop