but there's also others with my name and their own trails.
For fun, I Googled myself and my wife. Turns out my wife's a basketball player, a corporate credit services clerk, principal of some elementary school, a movie actress and all sorts of other things, since her name is rather common. No one's going to succeed in performing a background check on her via Google. Maybe 2-5% of the links turned up on Google had anything to do with her. She simply doesn't have a web presence that stands out.
I, on the other hand, have a comparitively significant web presence and a unique name. I get over 9,000 hits on Google, and at least most of the links on the first 20-30 pages are something to do with me personally. I've always been aware that anything I did on USENET or mailing lists was essentially "in public," though, and I have no worries that my web presence will have anything other than a positive impact on any future job search I might have. Not that I intend to leave my employer any time soon.
Uh, hello? This is NOT off topic. The tagline of Firesign Theatre's imaginary entity, US Plus, is "We own the idea of America," and later that gets extended to "We own the idea of the idea of America." That's humor aimed directly at the heart of the case going to the SCOTUS. How is that off topic? The Firesigns were dead on, IMHO.
''The privilege afforded not only extends to answers that would in themselves support a conviction . . . but likewise embraces those which would furnish a link in the chain of evidence needed to prosecute . . . . [I]f the witness, upon interposing his claim, were required to prove the hazard . . . he would be compelled to surrender the very protection which the privilege is designed to guarantee. To sustain the privilege, it need only be evident from the implications of the question, in the setting in which it is asked, that a responsive answer to the question or an explanation of why it cannot be answered might be dangerous because injurious disclosure could result.'' Thus, a judge who would deny a claim of the privilege must be '''perfectly clear, from a careful consideration of all the circumstances in the case, that the witness is mistaken, and that the answer[s] cannot possibly have such tendency' to incriminate.''
...and then later... (again, emphasis mine.)
What the privilege protects against is compulsion of ''testimonial'' disclosures; requiring a person in custody to stand or walk in a police lineup, to speak prescribed words, to model particular clothing, or to give samples of handwriting, fingerprints, or blood does not compel him to incriminate himself within the meaning of the clause, although compelling him to produce private papers may.
I don't think so. I'd imagine neither your encrypted email nor the key that locks it are considered testimony. Thus, being compelled to decrypt an encrypted email would not be considered "being a witness against himself," though I could be wrong. Just like 99.44% of the folk on here, IANAL.
You see, email is a physical artifact whose information content is fixed ahead of time. It is cold, hard evidence which exists regardless of the legal procedings. Witnesses provide testimony to the court from their memories at the prompting of the court, which is rather different. The fact that anyone (given sufficient time) could produce the contents of the email should make that clear. No one but you can provide your testimony, in contrast.
When will data-as-code die already? SQL injection, shell escaping vulerabilities, buffer-overflow attacks leading to arbitrary code execution, etc... All of these reflect ignorance of one common security principle: SEPARATE DATA FROM CODE.
We can eliminate all of these if the structure of the code is immutable with respect to the data it manipulates.
That's not to say that buffer overruns or corrupt data couldn't cause other mischief. But, at the very least, you could actually prove the mathematical correctness of your program if you can guarantee that the code you see in the source (and the libraries it links) is the only code that can execute. If a data input could become part of the code, all bets are off.
The fact that SQL queries are held in strings and look like data to the host programming environment is bad design from a security standpoint. A similar statement can be made for shell scripts. The fact that the semantics of a shell statement (such as "what commands are present") aren't known until after variable expansion has lead to how much havoc?
Now, I suppose some of you might read this as "Well, you can't write provably correct interpreters then!" Not true. The interpreter itself must treat all of the interpreted program as data and keep it separate from the interpreter's code. e.g. I shouldn't be able to subvert bash's internal programming with a shell script. In the interpreted language, none of the data manipulated by the interpreted language should ever be able to become part of the interpreted program—e.g. no input to a shell script should ever become part of the shell script's programming. As long as you construct those barriers—that the data manipulated by one layer of programming is never considered code at that same layer of programming—you eliminate these data-as-code attacks at that layer.
Actually it is, kinda. Isn't Firefox offered under three licenses? NPL, MPL and GPL? If you want your code to make it back into mainline Firefox, you have to agree to license it three ways. But if you want to fork Firefox and make a GPL-only version, nothing stops you.
... Ok, I dug it up. They're attempting to get it all under the tri-license. Check it out. There are some portions that aren't GPL yet.
Just to throw my two cents in, that's exactly how I read it as well.
The thing is, if we really do get "Linux everywhere," enough people are going to want to start hacking that it'll create an economic incentive to cater to the hackers. Witness the Linux variant of the WRT54G.
IMHO, DRM will only die by collapsing under its own weight, and by heightening consumers' awareness of the issues. Fighting DRM head on by denying access to its underlying technologies (when, as Linus states, those technologies themselves aren't inherently evil) isn't going to work.
It's actually pretty simple. Portions of code licensed as "GPL v2 or later" can be incorporated into a GPL v2 program or a GPL v3 program. Portions of code licensed as GPL v2 only can only be incorporated with GPL v2 programs (or other licenses compatible with GPL v2, of which I believe there are precious few). GPL v3 is not strictly compatible with GPL v2, because it "adds additional restrictions." When you integrate GPL v2-or-later code into a GPL v3 program, the result is GPL v3.
This is sorta like how BSD-minus-advertising-clause is "compatible" with GPL, in that such BSD code can be integrated into a GPL v2 program without violating the BSD license. The result is a GPL v2 program, though. You can't take GPL v2 code and integrate it into a BSD-licensed program and end up with something BSD-licensed, because of the requirements GPL places on requiring source with redistribution. Relicensing as BSD removes that requirement and thus violates the license on the GPL v2 code.
As a user, the only impact of the "GPL v2 or later" clause is that I can pick which ever one suits my fancy. As it stands, GPL v3 places more restrictions on what I can do with the code than GPL v2, so as a user I'll probably pick GPL v2. If GPL v4 were to come along and say "Do whatever you like, you may as well consider this code public domain," then I as a user could go hog wild with it.
As far as migrating the Linux kernel or any other GPL v2 app to GPL v3.... If the license on a bit of code is "GPL v2 or later," then it's trivial to make future versions "GPL v3 only." You can't "take back" the GPL v2-or-later versions, but you can make future versions GPL v3, removing the support for GPL v2. In Linux, portions of the kernel are GPL v2-or-later, so those portions can become parts of GPL v3 apps easily. The bulk of the kernel is GPL v2-only (w/ binary kernel module exception). So to bring the kernel into GPL v3 land, Linus would have to talk nearly everyone into either relicensing the kernel as GPL v2-or-later or GPL v3.
It also doesn't help that the new binary prefixes make the speaker sound like an imbecile if you try to say the units aloud, at least to my American ears.
Well, the computed number is worthless, but the workload is well defined and CPU bound. It's not a comprehensive benchmark, but it's probably better than the old Norton SI, since it's likely to not actually fit in cache.
I'm not against the filtering, though I can't say I'm thrilled either. The troops have a job to do, and the most important information they need comes from their compatriots, their superiors, and in letters from home. The unilateral nature of the filtering (filter out Al Franken and Wonkette but leave in Bill O'Reilly and Rush Limbaugh?) is what really bothers me. If you're going to filter, filter them all!
You might be great at math and algorithms, but I don't think you did so well at reading and comprehension. Did you miss this little detail in the original post? (The parent of the "big list of scores".)
put windows calculator in scientific mode (yes, mathmatica or maple will do factorials in a fraction of the time, but try to post windows scores for comparison purposes....)
The algorithm or the fact that he computed a factorial doesn't matter. Rather, the GP was defining a specific, fixed workload that anyone running Windows can generate for themselves easily.
There's only one plugin I use regularly, and I think it's quite useful: Off-The-Record Messaging. Great when you don't want a pesky, bored sysadmin reading about your private life.
Well, you have to be a bit more careful than that, since CPUID's a lot shorter, opcode wise, than what you're replacing it with. The key here is to hack something in-place. (CPUID is only 2 bytes long.)
Slashdot Mirror
For fun, I Googled myself and my wife. Turns out my wife's a basketball player, a corporate credit services clerk, principal of some elementary school, a movie actress and all sorts of other things, since her name is rather common. No one's going to succeed in performing a background check on her via Google. Maybe 2-5% of the links turned up on Google had anything to do with her. She simply doesn't have a web presence that stands out.
I, on the other hand, have a comparitively significant web presence and a unique name. I get over 9,000 hits on Google, and at least most of the links on the first 20-30 pages are something to do with me personally. I've always been aware that anything I did on USENET or mailing lists was essentially "in public," though, and I have no worries that my web presence will have anything other than a positive impact on any future job search I might have. Not that I intend to leave my employer any time soon.
--JoeUh, hello? This is NOT off topic. The tagline of Firesign Theatre's imaginary entity, US Plus, is "We own the idea of America," and later that gets extended to "We own the idea of the idea of America." That's humor aimed directly at the heart of the case going to the SCOTUS. How is that off topic? The Firesigns were dead on, IMHO.
"Mmmm! Is that real pork?"
--JoeUS-Plus: We own the idea of the idea of America!
Good thing IANAL: FindLaw agrees more with you than with me. A quote from the page: (emphasis mine)
...and then later... (again, emphasis mine.)
--JoeI don't think so. I'd imagine neither your encrypted email nor the key that locks it are considered testimony. Thus, being compelled to decrypt an encrypted email would not be considered "being a witness against himself," though I could be wrong. Just like 99.44% of the folk on here, IANAL.
You see, email is a physical artifact whose information content is fixed ahead of time. It is cold, hard evidence which exists regardless of the legal procedings. Witnesses provide testimony to the court from their memories at the prompting of the court, which is rather different. The fact that anyone (given sufficient time) could produce the contents of the email should make that clear. No one but you can provide your testimony, in contrast.
--Joe
When will data-as-code die already? SQL injection, shell escaping vulerabilities, buffer-overflow attacks leading to arbitrary code execution, etc... All of these reflect ignorance of one common security principle: SEPARATE DATA FROM CODE.
We can eliminate all of these if the structure of the code is immutable with respect to the data it manipulates.
That's not to say that buffer overruns or corrupt data couldn't cause other mischief. But, at the very least, you could actually prove the mathematical correctness of your program if you can guarantee that the code you see in the source (and the libraries it links) is the only code that can execute. If a data input could become part of the code, all bets are off.
The fact that SQL queries are held in strings and look like data to the host programming environment is bad design from a security standpoint. A similar statement can be made for shell scripts. The fact that the semantics of a shell statement (such as "what commands are present") aren't known until after variable expansion has lead to how much havoc?
Now, I suppose some of you might read this as "Well, you can't write provably correct interpreters then!" Not true. The interpreter itself must treat all of the interpreted program as data and keep it separate from the interpreter's code. e.g. I shouldn't be able to subvert bash's internal programming with a shell script. In the interpreted language, none of the data manipulated by the interpreted language should ever be able to become part of the interpreted program—e.g. no input to a shell script should ever become part of the shell script's programming. As long as you construct those barriers—that the data manipulated by one layer of programming is never considered code at that same layer of programming—you eliminate these data-as-code attacks at that layer.
--JoeDo you have a scroll bar at the right? If so, then you did not pass.
Actually it is, kinda. Isn't Firefox offered under three licenses? NPL, MPL and GPL? If you want your code to make it back into mainline Firefox, you have to agree to license it three ways. But if you want to fork Firefox and make a GPL-only version, nothing stops you.
... Ok, I dug it up. They're attempting to get it all under the tri-license. Check it out. There are some portions that aren't GPL yet.
--JoeJust to throw my two cents in, that's exactly how I read it as well.
The thing is, if we really do get "Linux everywhere," enough people are going to want to start hacking that it'll create an economic incentive to cater to the hackers. Witness the Linux variant of the WRT54G.
IMHO, DRM will only die by collapsing under its own weight, and by heightening consumers' awareness of the issues. Fighting DRM head on by denying access to its underlying technologies (when, as Linus states, those technologies themselves aren't inherently evil) isn't going to work.
--JoeIt's actually pretty simple. Portions of code licensed as "GPL v2 or later" can be incorporated into a GPL v2 program or a GPL v3 program. Portions of code licensed as GPL v2 only can only be incorporated with GPL v2 programs (or other licenses compatible with GPL v2, of which I believe there are precious few). GPL v3 is not strictly compatible with GPL v2, because it "adds additional restrictions." When you integrate GPL v2-or-later code into a GPL v3 program, the result is GPL v3.
This is sorta like how BSD-minus-advertising-clause is "compatible" with GPL, in that such BSD code can be integrated into a GPL v2 program without violating the BSD license. The result is a GPL v2 program, though. You can't take GPL v2 code and integrate it into a BSD-licensed program and end up with something BSD-licensed, because of the requirements GPL places on requiring source with redistribution. Relicensing as BSD removes that requirement and thus violates the license on the GPL v2 code.
As a user, the only impact of the "GPL v2 or later" clause is that I can pick which ever one suits my fancy. As it stands, GPL v3 places more restrictions on what I can do with the code than GPL v2, so as a user I'll probably pick GPL v2. If GPL v4 were to come along and say "Do whatever you like, you may as well consider this code public domain," then I as a user could go hog wild with it.
As far as migrating the Linux kernel or any other GPL v2 app to GPL v3.... If the license on a bit of code is "GPL v2 or later," then it's trivial to make future versions "GPL v3 only." You can't "take back" the GPL v2-or-later versions, but you can make future versions GPL v3, removing the support for GPL v2. In Linux, portions of the kernel are GPL v2-or-later, so those portions can become parts of GPL v3 apps easily. The bulk of the kernel is GPL v2-only (w/ binary kernel module exception). So to bring the kernel into GPL v3 land, Linus would have to talk nearly everyone into either relicensing the kernel as GPL v2-or-later or GPL v3.
--JoeIt also doesn't help that the new binary prefixes make the speaker sound like an imbecile if you try to say the units aloud, at least to my American ears.
Stop it. You're making me hungry for Mediterranian food.
And then there's GFS!
You stupid, stupid people! We then have no alternative but to destroy you before you destroy us. With your ancient juvenile minds, you have developed explosives too fast for your minds to conceive what you are doing. You are on the verge of destroying the entire universe.
Well, the computed number is worthless, but the workload is well defined and CPU bound. It's not a comprehensive benchmark, but it's probably better than the old Norton SI, since it's likely to not actually fit in cache.
Oh yeah!
I'm not against the filtering, though I can't say I'm thrilled either. The troops have a job to do, and the most important information they need comes from their compatriots, their superiors, and in letters from home. The unilateral nature of the filtering (filter out Al Franken and Wonkette but leave in Bill O'Reilly and Rush Limbaugh?) is what really bothers me. If you're going to filter, filter them all!
Oh, wait, then those gift subscriptions to Limbaugh's show that us liberals are supposed to buy for our favorite troops will be worthless. Oh darn. I guess if they filter Rush, I won't be able to Support Our Troops the Limbaugh way.
--Joe
You might be great at math and algorithms, but I don't think you did so well at reading and comprehension. Did you miss this little detail in the original post? (The parent of the "big list of scores".)
The algorithm or the fact that he computed a factorial doesn't matter. Rather, the GP was defining a specific, fixed workload that anyone running Windows can generate for themselves easily.
--Joe
There's only one plugin I use regularly, and I think it's quite useful: Off-The-Record Messaging. Great when you don't want a pesky, bored sysadmin reading about your private life.
...or Springfield, IL, which is much closer.
Judging by the code, I would've replaced the "add esi, 0ah" with "mov esi, 0ah" at location 007CCCF1.
Well, you have to be a bit more careful than that, since CPUID's a lot shorter, opcode wise, than what you're replacing it with. The key here is to hack something in-place. (CPUID is only 2 bytes long.)
Ok, fine, but what about on the laptop itself? What if I truly am holding it in my lap and have no surface to mouse on?
Of course, Strange Brew did borrow heavily from Hamlet...
Ah, is this that famous Windows "easier to use" I keep hearing about?