Unless, of course, the number of integer ops required is enough that its cheaper to use a slow float unit than a fast integer unit.
Note: I have not looked at the Ogg code at all, and have no idea what the relative speed requirements are between the two implementations. This is just a conception, saying that float is not always more expensive than fixed.
If you weren't smart enough to have the Windows machine firewalled away from the net when you were installing it, then you're not smart enough to run a Linux box.
I can learn perl in 24 hours, sure, but I won't be all that good at it.
You can't learn the math of control systems in 24 hours (this is what I do for a living), but you can get as good at it as I am in roughly the same amount of time it takes to become a competent programmer (not in perl, just a competent programmer).
Getting to the physicists level in quantum mechanics probably takes a bit longer, but then again, he probably has a PhD, so if you took that kind of time to study it, odds are you could get to it.
The point is that none of these are intrinsically hard to do - learning the qualitative theories of quantum mechanics is very easy, learning how to hack out perl is very easy, learning basic gate-level design is very easy; you just have to spend some time at each, and I don't like to blame people for choosing to spend their time elsewhere.
There is not a chance in hell the Russians would have let the US government get away with lying.
The only explanation is that they managed to con the entire Russian security/intelligence structure. It'd be easier to go to the moon, so I have to assume they did.
Also, I know people who worked on Apollo, and I tend to believe their word.
And yet, half the "geeks" out there can't tell me how CMOS works.
They can write Perl and PHP, but ask them what a transistor is and their faces go blank.
Then you ask the EE who designs low-level CMOS VLSI designs how the electrons move inside the transistors, and he probably gives a decent explanation, but if you ask him why, blank look.
So you go talk to the physicist. Who can probably explain why the electrons move around the way they do.
You know, I choose to view people who get viruses and pop-ups as equivalent to people who can't figure out how to check their oil and refill their washer fluid.
Actually, with a one way function hash, a collision free hash is always going to be superior as compared to a colliding hash.
Basically, the assumption is that the function you're one-waying with is strong. Generally, the functions used are in the same class as public-key cryptographic functions; i.e. the discrete log or elliptic curve problems. If computing power improves to the point where those become trivial to crack, there will be a lot bigger problems than whether your name is retrievable from a hashlist the credit card agency got fed.
Basically, since you have to assume that you can't reverse the hash function, the only benefit to a colliding hash is that you wind up with multiple sets of data that can create a single hash. However, since you have to exhaustively search anyway, you'll get to look at all of your colliding original pieces of data, and can select intelligently the one that makes sense. This is a little more difficult than in a collision-free hash, but the amount of work in searching the hashspace is many orders of magnitude higher than the work needed in selecting the correct value from a group of colliders in a colliding hash (assuming that the number of collisions is relatively small to minimize false positives).
Hashing is not one-way due to information loss; it's one way due to the functions used being computationally infeasible to reverse. This is what makes it difficult to directly extract the original data, not information loss.
Actually, a fully collision free hashing function should not involve information loss, given knowledge of the hash algorithm - in a collision free hashing scheme, a hash has a unique set of data that produces it. That set, and no other, can produce the given hash.
Given the hash and the algorithm, you can brute-force recover all information input into the hash.
Hashing doesn't always involve producing a shorter output, and this situation ('anonymizing') is a circumstance where you would most likely want a collision-free hash (unless you want that one in a billion chance that "Dick Cheney" and "Osama Bin Laden" hash out to the same value...). By definition, a collision free hash cannot produce an output with less informational content than the input.
You're thinking, if I'm understanding you properly, of what is called the time-space tradeoff principle. Basically, it says that for certain classes of problems, you can reduce runtime by increasing a pre-computed storage space (i.e. one long initial runtime, followed by very very short subsequent runtimes).
A proof-of-concept of an advanced version of this sort of attack can be found at phiral research by clicking on PPM on the sidebar.
Its a great attack, except that as the length of the data you're attacking goes up, the size of your database becomes enormous. For a DES hash with 4 characters (not bits, characters) of data and 4096 salt values (these are the values used in DES-style password encryption) the amount of disk space required for this sort of attack is roughly 4.5TB.
Its a simple attack, but the amount of storage required to do something like this makes it prohibitively expensive. Also, you need to run every possible value once, which corresponds to a single exhaustive brute-force attack on the keyspace. For a large keyspace, this is prohibitively expensive in terms of time.
Your simple attack is half-baked in the real world application.
The ONLY place a cameraphone is a threat in terms of corporate espionage is in places where you have a highly visual product which you show off in advance, but under NDAs.
I.E. Automotive body designs, print ad campaigns, etc.
Insiders won't use a cameraphone to take a picture of that blueprint or schematic. They'll take the netlist or the DWG or the PDF home on a CD and email it from home.
He had one good point - WEP does have weak keys. So use a keygen that at least checks to make sure you don't have one of the completely trivial weak keys.
It'll make it take longer... still not long enough, but longer.
Its called negative feedback, and there are quite a few ways where a negative feedback system can go into oscillation and start emitting sound.
Its possible. On the other hand, it remains unlikely.
However, having done something very similar, I'm skeptical about this. Generally you can only cancel for one point in space, which works fine for headphones, but isn't so useful for someone who moves around their cubicle or office all day.
Does the Genesis output a 240NI signal? Didn't know that.
I was under the impression that all early-gen consoles (anything prior to the Dreamcast, basically) could only output 480i, but I'll totally buy the idea that they run at 240ni.
OK. If you can get a *useful* pressure difference out of a PS2 button, I bow to you. I just hit them.
I can control the analog portion of the shoulder triggers on the GC/Xbox fairly precisely. I don't see how anyone can even remotely precisely control, beyond a hard/light tap, how hard they hit the buttons on a PS2.
That's odd, considering the fact that their business models mostly seem to come with Intel integrated graphics... are you *certain* you're not thinking of Intel?
I'm not sure where you're getting your "IBM has the desktop market" figure from; I wasn't aware that IBM had designed any graphics chips at all. Back it up, please?
My parents are reasonably intelligent people. If they want to use a computer, I expect them to take care of it themselves. I'll answer intelligent questions, and when I'm home I'll occasionally sit down and help with major things (doing an upgrade to XP, Linux is not an option when your COGO solution is windows-only - and ironically, won't run under XP - back to 98...)
It works pretty well. I say "Smart people run AV software, Ad-Aware, install updates, and don't run programs sent to them in email."
They think "We're smart people" and do what I said in the first place, which saves me much aggravation.
The nice thing about offline console games is that the word "leet" is never heard. Or if it is, you can reach over and punch the loser who's pretending to be your friend.
Slashdot Mirror
Portable recording.
When I got my MD recorder, portable HDD recording was expensive. I bought it because a portable MD was cheaper than a portable DAT deck.
And for the record - USABLE portable HDD recording is still expensive. Cheap ones that I've seen are all a pain to work with.
Unless, of course, the number of integer ops required is enough that its cheaper to use a slow float unit than a fast integer unit.
Note: I have not looked at the Ogg code at all, and have no idea what the relative speed requirements are between the two implementations. This is just a conception, saying that float is not always more expensive than fixed.
Anyone who encodes their digital masters with a lossy codec should be beaten with a sharp stick.
If you weren't smart enough to have the Windows machine firewalled away from the net when you were installing it, then you're not smart enough to run a Linux box.
I can learn perl in 24 hours, sure, but I won't be all that good at it.
You can't learn the math of control systems in 24 hours (this is what I do for a living), but you can get as good at it as I am in roughly the same amount of time it takes to become a competent programmer (not in perl, just a competent programmer).
Getting to the physicists level in quantum mechanics probably takes a bit longer, but then again, he probably has a PhD, so if you took that kind of time to study it, odds are you could get to it.
The point is that none of these are intrinsically hard to do - learning the qualitative theories of quantum mechanics is very easy, learning how to hack out perl is very easy, learning basic gate-level design is very easy; you just have to spend some time at each, and I don't like to blame people for choosing to spend their time elsewhere.
There is not a chance in hell the Russians would have let the US government get away with lying.
The only explanation is that they managed to con the entire Russian security/intelligence structure. It'd be easier to go to the moon, so I have to assume they did.
Also, I know people who worked on Apollo, and I tend to believe their word.
And yet, half the "geeks" out there can't tell me how CMOS works.
They can write Perl and PHP, but ask them what a transistor is and their faces go blank.
Then you ask the EE who designs low-level CMOS VLSI designs how the electrons move inside the transistors, and he probably gives a decent explanation, but if you ask him why, blank look.
So you go talk to the physicist. Who can probably explain why the electrons move around the way they do.
But I bet he can't write perl scripts.
You know, I choose to view people who get viruses and pop-ups as equivalent to people who can't figure out how to check their oil and refill their washer fluid.
Actually, with a one way function hash, a collision free hash is always going to be superior as compared to a colliding hash.
Basically, the assumption is that the function you're one-waying with is strong. Generally, the functions used are in the same class as public-key cryptographic functions; i.e. the discrete log or elliptic curve problems. If computing power improves to the point where those become trivial to crack, there will be a lot bigger problems than whether your name is retrievable from a hashlist the credit card agency got fed.
Basically, since you have to assume that you can't reverse the hash function, the only benefit to a colliding hash is that you wind up with multiple sets of data that can create a single hash. However, since you have to exhaustively search anyway, you'll get to look at all of your colliding original pieces of data, and can select intelligently the one that makes sense. This is a little more difficult than in a collision-free hash, but the amount of work in searching the hashspace is many orders of magnitude higher than the work needed in selecting the correct value from a group of colliders in a colliding hash (assuming that the number of collisions is relatively small to minimize false positives).
Hashing is not one-way due to information loss; it's one way due to the functions used being computationally infeasible to reverse. This is what makes it difficult to directly extract the original data, not information loss.
Actually, a fully collision free hashing function should not involve information loss, given knowledge of the hash algorithm - in a collision free hashing scheme, a hash has a unique set of data that produces it. That set, and no other, can produce the given hash.
Given the hash and the algorithm, you can brute-force recover all information input into the hash.
Hashing doesn't always involve producing a shorter output, and this situation ('anonymizing') is a circumstance where you would most likely want a collision-free hash (unless you want that one in a billion chance that "Dick Cheney" and "Osama Bin Laden" hash out to the same value...). By definition, a collision free hash cannot produce an output with less informational content than the input.
You're thinking, if I'm understanding you properly, of what is called the time-space tradeoff principle. Basically, it says that for certain classes of problems, you can reduce runtime by increasing a pre-computed storage space (i.e. one long initial runtime, followed by very very short subsequent runtimes).
A proof-of-concept of an advanced version of this sort of attack can be found at phiral research by clicking on PPM on the sidebar.
Its a great attack, except that as the length of the data you're attacking goes up, the size of your database becomes enormous. For a DES hash with 4 characters (not bits, characters) of data and 4096 salt values (these are the values used in DES-style password encryption) the amount of disk space required for this sort of attack is roughly 4.5TB.
Its a simple attack, but the amount of storage required to do something like this makes it prohibitively expensive. Also, you need to run every possible value once, which corresponds to a single exhaustive brute-force attack on the keyspace. For a large keyspace, this is prohibitively expensive in terms of time.
Your simple attack is half-baked in the real world application.
The ONLY place a cameraphone is a threat in terms of corporate espionage is in places where you have a highly visual product which you show off in advance, but under NDAs.
I.E. Automotive body designs, print ad campaigns, etc.
Insiders won't use a cameraphone to take a picture of that blueprint or schematic. They'll take the netlist or the DWG or the PDF home on a CD and email it from home.
He had one good point - WEP does have weak keys. So use a keygen that at least checks to make sure you don't have one of the completely trivial weak keys.
It'll make it take longer... still not long enough, but longer.
Its called negative feedback, and there are quite a few ways where a negative feedback system can go into oscillation and start emitting sound.
Its possible. On the other hand, it remains unlikely.
However, having done something very similar, I'm skeptical about this. Generally you can only cancel for one point in space, which works fine for headphones, but isn't so useful for someone who moves around their cubicle or office all day.
Does the Genesis output a 240NI signal? Didn't know that.
I was under the impression that all early-gen consoles (anything prior to the Dreamcast, basically) could only output 480i, but I'll totally buy the idea that they run at 240ni.
Bah, I can beat that.
"Florida... that's America's wang!"
(all credit to Homer J.)
NTSC does 60 fields per second. A field is half of the scan lines on the screen. So, in effect, NTSC is a 30 full frames per second.
This is why getting good TVout to non-HDTV (480i) TVs is such a bitch.
I honestly can't stand pure racing games, so no, I haven't.
Have you used the analog shoulder triggers on the GC or Xbox? How do they compare to the buttons on the ps2 in terms of ease of accurate control?
timothy.
OK. If you can get a *useful* pressure difference out of a PS2 button, I bow to you. I just hit them.
I can control the analog portion of the shoulder triggers on the GC/Xbox fairly precisely. I don't see how anyone can even remotely precisely control, beyond a hard/light tap, how hard they hit the buttons on a PS2.
That's odd, considering the fact that their business models mostly seem to come with Intel integrated graphics... are you *certain* you're not thinking of Intel?
I'm not sure where you're getting your "IBM has the desktop market" figure from; I wasn't aware that IBM had designed any graphics chips at all. Back it up, please?
My parents are reasonably intelligent people. If they want to use a computer, I expect them to take care of it themselves. I'll answer intelligent questions, and when I'm home I'll occasionally sit down and help with major things (doing an upgrade to XP, Linux is not an option when your COGO solution is windows-only - and ironically, won't run under XP - back to 98...)
It works pretty well. I say "Smart people run AV software, Ad-Aware, install updates, and don't run programs sent to them in email."
They think "We're smart people" and do what I said in the first place, which saves me much aggravation.
If I want to play online, I sit down at my PC.
The nice thing about offline console games is that the word "leet" is never heard. Or if it is, you can reach over and punch the loser who's pretending to be your friend.
Nah. They'll just get NVIDIA and ATI to let them fab their chips. IBM doesn't seem to have a lot of interest in designing GPUs.