If you check the BSA e-mail, they logged into the anonymous FTP resource with the address "guest@nowhere.com", which is obviously fake.
Ok, I agree, but let's think here. I generally use the address "-a@" when logging into anonymous FTP. This is because (shock) I believe that anonymous FTP should be, well, anonymous. If someone really wants to track me down, he can get my IP address easily.
Is it "OK" for normal folks to do this, yet "not OK" for the BSA? Or is it "not OK" for anyone?
In my (what, 9? 10?) years of using FTP this way, I've never been tracked down and reprimanded by an FTP admin for trying to remain anonymous. Are you actually suggesting that, over all this time, I've been doing something wrong?
However, they've apparently decided that any publiclity is good publicity.
Have you seen their recent TV ad, with the guy at the dinner table who turns to the camera, puts on the funniest shit-eating grin you can imagine, and screams "MORE SPAM!!!!" Then a truck carrying Spam(TM) crashes through the wall into the dining room.
Kind of like spam mail crashing into your inbox, interrupting whatever you were currently in the middle of doing... It's a brilliant ad.
This sounds just like the case with the free PCI device list. The fundamental problem is not the USAGE of the trademark, rather the fact that it is not clearly marked AS SUCH.
Rather than throwing a hissy fit, I suspect the problem can be resolved by simply placing a small note next to the "Googling" entry reminding the reader that "Google" is a registered trademark.
I am now being forced to document my code to a level at which a non-programmer could figure out what's going on and stumble through it.
Sounds like they are afraid of getting screwed if you quit. But I think they're actually screwing themselves.
Suppose you do quit. They now have to hire someone else to maintain this Perl code (probably being paid a comparable amount to your current pay). This person will need a certain amount of time to get up to speed with your code, but this is a ONE TIME cost.
However, the productivity cost incurred by forcing you to over-document your work is a RECURRING cost which accrues each and every day.
If I were your employer I'd be more interested in increasing your productivity, and taking on a finite amount of risk if you decide to quit, rather than decreasing your productivity (and increasing your cost per line of code).
150 billion pounds... Is that "American" billions? Because in Britain (and I think other places) a "billion" commonly means 10^12, which is what the Americans call a trillion. So Blair could actually be talking about 150 *trillion* pounds.
Or do the Brits typically use American units in their international press statements?
Re:Misleading title... it's NOT about HACKING
on
Hacker's Challenge 2
·
· Score: 2, Funny
I suppose trying to get writers and the general public to distinguish between hacking and cracking is a lost cause, but we need to keep trying.
Sigh... I know how you feel. But I think we should just let them have the term. It's wasted effort to keep trying to correct people.
Let them refer to crackers as "hackers." We'll just switch to referring to hackers as "gods.";-)
You can't blame someone for wanting to look down at the people who ridiculed them for some of the most impressionable years of their life.
Just like you can't blame the Israelis for wanting to retaliate against Palestinian terror attacks. And just like you can't blame the Palestinians for wanting to retaliate against the Israelis who bulldoze their houses.
Right?
On the other hand, maybe the "He hit me first" excuse is bullshit.
Re:What is an example that can't run in parallel?
on
Forget Moore's Law?
·
· Score: 2, Interesting
There is only part of the algorithm that can be done in "parallel." For reference see md5.c
An example round from MD5 (line 198):
MD5STEP (F1, a, b, c, d, in[0] + 0xd76aa478, 7);
This expands to:
( w += (d ^ (b & (c ^ d))) + in[0] + 0xd76aa478, w = w<<7 | w>>(32-7), w += b )
Notice that there are two additions in the first subexpression. The addition (in[0] + 0xd76aa478) can be computed simultaneously with (d ^ (b & (c ^ d))).
This is the only spot where anything could be parallelized. Assuming that all the principle operations can be performed in the same amount of time, then you could potentially go 25% faster by computing the addition in parallel.
But that's the furthest you can go.
Re:What is an example that can't run in parallel?
on
Forget Moore's Law?
·
· Score: 4, Informative
Can someone please give an example of a computing task that CANNOT be subdivided into smaller tasks and run in parallel on many processing elements? The kind of task that requires an ever faster single processor.
Computing the MD5 sum of 1TB of data.:-) MD5 depends on (among other things) being non-parallelizable for its security.
Re:Is this the first signs of a turnaround?
on
Forget Moore's Law?
·
· Score: 1
I personally still believe that programmers should be forced to run and program on systems that are 1/2 to 1/3rd of what is typically used. this will force the programmers to optimize or find better ways to make that app or feature work.
Funny you say that. Right now at work, I use a dual Celeron-500 box running RH7, 256 megs of RAM. However, I develop on Win2K running inside a VMWare session on the RH box. The VMWare session has only 48 megs of RAM.
It reminds me (with a little nostalgia, I might add) of my old Pentium 233 box. And if my code doesn't run on that puppy, then I need to rework my code.
Too bad they are giving me dual MP 2400s this week! I actually like seeing my code run on a slower box. I feel ashamed when things can't work on a slow machine.
My point? It is one thing to teleport a photon, which is a massless boson. It is quite another thing to teleport a massive fermion, let alone a collection of them as would be found in any massive object of appreciable size. The physics of teleportation would most likely be very different, since the quantum mechanics and statistics of bosons are quite different from those of fermions. So don't get your hopes up yet regarding teleportation a la Star Trek.
I don't follow you. How does ANY of that show that it would be harder for fermions? You just listed a bunch of ways it would work differently. DIFFERENTLY. That doesn't imply "more difficult." Unless you have something you wish to elaborate on...
Also. Not all bosons are force-carriers. Atomic nuclei can be bosons (think Rubidium-80). But we don't view atomic nuclei as the quanta of any particular field. Unless you want to believe in the "Rubidium-80 field":-)
There's a rule in QM called "no cloning" which means you cannot make an exact copy of a quantum state without destroying that state. In other words, the Heisenberg uncertainty principle prevents you from duplicating a photon precisely. It does not stop you from teleporting that photon to a new location, thereby destroying the "original" photon.
This is done through a dual process. Part of the photon state is transmitted "classically," by measuring the photon and sending the information along a wire. The other part of the photon state is not measured, but "travels" to the new location via entanglement. The two pieces of information are put back together at the other side to recreate the photon. The process of making the classical measurement is what destroys the original photon. This destruction is unavoidable -- you can't end up with an identical copy of the photon, while still keeping the first photon.
Star Trek transporters could be a theoretical possiblity. But replicators cannot exist, because that would involve exact cloning of quantum states, which is impossible.
A movie is art. Offensive or not it is art and it is the vision of the director. Just like real art can not be sensored either should movies.
What if I buy a nice painting, then carve a big "X" in it with a knife, because I can appreciate the art better with a big "X" carved in it? Are you saying that's wrong too?
This is no different than forbidding people from modifying, say, a painting they own. It's my painting, and I'll carve a big freaking "X" in it if I want.
This still sounds lossy to me... 'quite close' is still not 'exactly right', which means a loss of definition, even if it is very tiny.
The predicted value isn't what gets sent. They send the difference between the prediction and the actual. On the decoding side, they make the same prediction, then add the "delta" back in, to recover the original sample. The procedure is entirely lossless.
The high level of compression comes from the fact that the deltas are distributed geometrically (because audio is highly correlated in time). Golomb-Rice codes are the optimal way to encode geometric distributions, so that's what they chose.
Yeah, there are plenty of pedants on/. just waiting to pounce on your slightest mis-wording or mistake...
You freak, you just described EXACTLY what FLAC does.
Except that they go even further than your naive scheme, and use a predictor to get even smaller deltas than your scheme (e.g., assume waveform is locally quadratic/cubic/quartic then extrapolate the next sample). A signal can be varying rapidly and yet still be highly predictable. Your simplistic scheme wouldn't handle it.
Then they use Rice-Golomb coding to encode the deltas. This does FAR better than gzip ever could, because it is designed SPECIFICALLY to handle the geometric distribution of the deltas, whereas gzip is a generic dictionary algorithm.
I really doubt you've even tried what you are suggesting. You're on the right track, but the FLAC team beat you to the punch. Sorry.
Yeah, I got Ogg and Vorbis confused. My bad. What I meant is there is no simple way to integrate FLAC data with Vorbis data. Obviously there should be no difficulty embedding FLAC data in an Ogg stream.
What the original poster was suggesting would be to encode the file losslessly, and then FLAC encode the residual produced by subtracting the encoded waveform from the unencoded one. This is a very cool idea, but it won't work. The residual signal is going to be very noise-like, so it would be resistant to FLAC compression (FLAC uses a "verbatim" mode when it sees noise -- the verbatim mode does no compression at all). It isn't that you couldn't do it, but I very highly doubt you'd gain anything by it.
So what sort of compression algorithm does FLAC use?
For the most part, linear prediction. This uses a linear combination of past sample values to predict the next sample value. The difference between the prediction and the actual is Golomb-Rice encoded. Golomb-Rice codes are used when the probability of an integer occurring is geometric (i.e., the value N+1 is 1/R times as likely as the value N, for some R > 1). This is a pretty good assumption for audio, since the predicted values tend to be quite close to the real ones. Some other lossy compression algorithms also use linear prediction, but they quantize the predicted values to reduce the bitrate even further. The quantization is the lossy step.
MP3 and OGG, on the other hand, work differently. They first transform a block of audio using the MDCT, and apply a psychoacoustic model to the resulting spectral envelope. This eliminates a lot of subbands that are "inaudible." At that point the remaining subband energies are quantized and entropy-coded. To decode, the encoded energies are decoded and the spectral envelope is reconstructed, then transformed back into the time domain to become "audio" again.
It would be a serious feat to integrate FLAC and OGG. They are totally different systems.
According to thei creator's website, they are planning on creating Deep Flight II, which they hope to pilot to the bottom of the Mariana Trench, some 38,000 feet down. But wouldn't the intense pressure and high viscosity of the water at that depth make it nearly impossible to operate on the flight principle?
The pressure would pose a problem, but, contrary to what you might expect, the viscosity of water actually decreases with pressure, until around 150 MPa of pressure. After that, viscosity starts increasing with pressure.
That pressure corresponds to about 50,000 feet of seawater. Since (as far as I know) there is no trench this deep on Earth, we probably won't be having problems with viscosity anytime soon.
Water is definitely one of the most unique substances we have on this planet.
You're one of those guys who thinks that anyone who doesn't grasp precisely all the different technical fields you do, must be an fool.
These researchers obviously have a good hold on compiler technology, since they implemented their checkers with xgcc. They also seem to understand logic quite well, since their code uses and extends on gcc's control-flow analysis algorithms. And they do, actually, understand what's going on here.
As for your particular example, the check really is redundant, but it was almost definitely intentional. It's true that another processor could change the cam variable between the first check and the lock -- but taking the first check out would have no impact on the functionality or correctness of the code. It's just a performance enhancement so that the routine can exit early in the error case, without the overhead of locking the lock. Removing the bit of redundant code would just add a little overhead to the error case.
In short, their checker found a true redundancy. They may have not realized its purpose since they don't have specific experience with this kind of parallel programming, but it's a redundancy. If you had actually read the paper instead of merely glancing over it, you would have seen that their checker respects the volatile nature of variables declared as such -- the checker is fully aware that a second thread can change the value between one operation and the other -- and it still figures out that the check is redundant.
Here's a hint: don't go around claiming people are fools unless you've got some evidence. These guys had hundreds and hundreds of bugs to go through, and expecting them to perfectly analyze every last one of them is unfair.
Assuming that only 1/5 (100,000,000) spams reached human recipients, and assuming each person wasted 15 seconds recognizing it as spam, cursing, and deleting it, we have a total waste of time:
15*100000000/3600/24/365 = 47 years.
Maybe he should have 47 years of his time wasted.
(No, I'm not actually serious. But that's a lot of wasted time.)
>There is also some work on hinting, etc, to finish up.
It's good to know we'll be getting a set of manually hinted fonts. But what about those of us (possibly the majority?) who have TrueType bytecode hinting disabled in our FreeType builds? Do these glyphs render well when hinted with FreeType's autohinter?
It would be a shame for the fonts to work well only when the patented bytecode interpretter is enabled in FreeType...
So if CVS is in CVS, maybe somebody rooted CVS's CVS to apply a patch to backdoor CVS, even with new CVS patches to CVS?;)
You're making a joke, but the problem you mention is actually a serious one. Ken Thompson who we all know and love from UNIX lore has written Reflections on Trusting Trust which describes just this problem.
Imagine that you insert a backdoor into a compiler, so that everything the compiler compiles is trojaned. If the compiler detects that it is recompiling itself, it quietly reinserts the trojan code. The actual source code to the trojan might be wiped out, but as long as you are running infected binaries, it will keep popping up again and again.
From the paper: "First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."
Hmmm...that works for the patch repository, but I'm not sure it's perfect for the legal situation. Let's say Alice wants to get out of a digital contract with Bob, she merely has to state that her key was compromised _before_ the notary's time stamp. But I'll bet that someone has already come up with a better contract signing algorithm.
Yes, they are called confirmation/disavowal algorithms. There are several methods by which you can securely "disavow" (disclaim authorship of) a signed document.
Slashdot Mirror
Ok, I agree, but let's think here. I generally use the address "-a@" when logging into anonymous FTP. This is because (shock) I believe that anonymous FTP should be, well, anonymous. If someone really wants to track me down, he can get my IP address easily.
Is it "OK" for normal folks to do this, yet "not OK" for the BSA? Or is it "not OK" for anyone?
In my (what, 9? 10?) years of using FTP this way, I've never been tracked down and reprimanded by an FTP admin for trying to remain anonymous. Are you actually suggesting that, over all this time, I've been doing something wrong?
Have you seen their recent TV ad, with the guy at the dinner table who turns to the camera, puts on the funniest shit-eating grin you can imagine, and screams "MORE SPAM!!!!" Then a truck carrying Spam(TM) crashes through the wall into the dining room.
Kind of like spam mail crashing into your inbox, interrupting whatever you were currently in the middle of doing... It's a brilliant ad.
Rather than throwing a hissy fit, I suspect the problem can be resolved by simply placing a small note next to the "Googling" entry reminding the reader that "Google" is a registered trademark.
Sounds like they are afraid of getting screwed if you quit. But I think they're actually screwing themselves.
Suppose you do quit. They now have to hire someone else to maintain this Perl code (probably being paid a comparable amount to your current pay). This person will need a certain amount of time to get up to speed with your code, but this is a ONE TIME cost.
However, the productivity cost incurred by forcing you to over-document your work is a RECURRING cost which accrues each and every day.
If I were your employer I'd be more interested in increasing your productivity, and taking on a finite amount of risk if you decide to quit, rather than decreasing your productivity (and increasing your cost per line of code).
Or do the Brits typically use American units in their international press statements?
Sigh... I know how you feel. But I think we should just let them have the term. It's wasted effort to keep trying to correct people.
Let them refer to crackers as "hackers." We'll just switch to referring to hackers as "gods." ;-)
Just like you can't blame the Israelis for wanting to retaliate against Palestinian terror attacks. And just like you can't blame the Palestinians for wanting to retaliate against the Israelis who bulldoze their houses.
Right?
On the other hand, maybe the "He hit me first" excuse is bullshit.
An example round from MD5 (line 198):
MD5STEP (F1, a, b, c, d, in[0] + 0xd76aa478, 7);
This expands to:
( w += (d ^ (b & (c ^ d))) + in[0] + 0xd76aa478, w = w<<7 | w>>(32-7), w += b )
Notice that there are two additions in the first subexpression. The addition (in[0] + 0xd76aa478) can be computed simultaneously with (d ^ (b & (c ^ d))).
This is the only spot where anything could be parallelized. Assuming that all the principle operations can be performed in the same amount of time, then you could potentially go 25% faster by computing the addition in parallel.
But that's the furthest you can go.
Computing the MD5 sum of 1TB of data. :-) MD5 depends on (among other things) being non-parallelizable for its security.
Funny you say that. Right now at work, I use a dual Celeron-500 box running RH7, 256 megs of RAM. However, I develop on Win2K running inside a VMWare session on the RH box. The VMWare session has only 48 megs of RAM.
It reminds me (with a little nostalgia, I might add) of my old Pentium 233 box. And if my code doesn't run on that puppy, then I need to rework my code.
Too bad they are giving me dual MP 2400s this week! I actually like seeing my code run on a slower box. I feel ashamed when things can't work on a slow machine.
I don't follow you. How does ANY of that show that it would be harder for fermions? You just listed a bunch of ways it would work differently. DIFFERENTLY. That doesn't imply "more difficult." Unless you have something you wish to elaborate on...
Also. Not all bosons are force-carriers. Atomic nuclei can be bosons (think Rubidium-80). But we don't view atomic nuclei as the quanta of any particular field. Unless you want to believe in the "Rubidium-80 field" :-)
There's a rule in QM called "no cloning" which means you cannot make an exact copy of a quantum state without destroying that state. In other words, the Heisenberg uncertainty principle prevents you from duplicating a photon precisely. It does not stop you from teleporting that photon to a new location, thereby destroying the "original" photon.
This is done through a dual process. Part of the photon state is transmitted "classically," by measuring the photon and sending the information along a wire. The other part of the photon state is not measured, but "travels" to the new location via entanglement. The two pieces of information are put back together at the other side to recreate the photon. The process of making the classical measurement is what destroys the original photon. This destruction is unavoidable -- you can't end up with an identical copy of the photon, while still keeping the first photon.
Star Trek transporters could be a theoretical possiblity. But replicators cannot exist, because that would involve exact cloning of quantum states, which is impossible.
What if I buy a nice painting, then carve a big "X" in it with a knife, because I can appreciate the art better with a big "X" carved in it? Are you saying that's wrong too?
This is no different than forbidding people from modifying, say, a painting they own. It's my painting, and I'll carve a big freaking "X" in it if I want.
The predicted value isn't what gets sent. They send the difference between the prediction and the actual. On the decoding side, they make the same prediction, then add the "delta" back in, to recover the original sample. The procedure is entirely lossless.
The high level of compression comes from the fact that the deltas are distributed geometrically (because audio is highly correlated in time). Golomb-Rice codes are the optimal way to encode geometric distributions, so that's what they chose.
Yeah, there are plenty of pedants on /. just waiting to pounce on your slightest mis-wording or mistake...
Except that they go even further than your naive scheme, and use a predictor to get even smaller deltas than your scheme (e.g., assume waveform is locally quadratic/cubic/quartic then extrapolate the next sample). A signal can be varying rapidly and yet still be highly predictable. Your simplistic scheme wouldn't handle it.
Then they use Rice-Golomb coding to encode the deltas. This does FAR better than gzip ever could, because it is designed SPECIFICALLY to handle the geometric distribution of the deltas, whereas gzip is a generic dictionary algorithm.
I really doubt you've even tried what you are suggesting. You're on the right track, but the FLAC team beat you to the punch. Sorry.
What the original poster was suggesting would be to encode the file losslessly, and then FLAC encode the residual produced by subtracting the encoded waveform from the unencoded one. This is a very cool idea, but it won't work. The residual signal is going to be very noise-like, so it would be resistant to FLAC compression (FLAC uses a "verbatim" mode when it sees noise -- the verbatim mode does no compression at all). It isn't that you couldn't do it, but I very highly doubt you'd gain anything by it.
For the most part, linear prediction. This uses a linear combination of past sample values to predict the next sample value. The difference between the prediction and the actual is Golomb-Rice encoded. Golomb-Rice codes are used when the probability of an integer occurring is geometric (i.e., the value N+1 is 1/R times as likely as the value N, for some R > 1). This is a pretty good assumption for audio, since the predicted values tend to be quite close to the real ones. Some other lossy compression algorithms also use linear prediction, but they quantize the predicted values to reduce the bitrate even further. The quantization is the lossy step.
MP3 and OGG, on the other hand, work differently. They first transform a block of audio using the MDCT, and apply a psychoacoustic model to the resulting spectral envelope. This eliminates a lot of subbands that are "inaudible." At that point the remaining subband energies are quantized and entropy-coded. To decode, the encoded energies are decoded and the spectral envelope is reconstructed, then transformed back into the time domain to become "audio" again.
It would be a serious feat to integrate FLAC and OGG. They are totally different systems.
No need to be rude...
The pressure would pose a problem, but, contrary to what you might expect, the viscosity of water actually decreases with pressure, until around 150 MPa of pressure. After that, viscosity starts increasing with pressure.
That pressure corresponds to about 50,000 feet of seawater. Since (as far as I know) there is no trench this deep on Earth, we probably won't be having problems with viscosity anytime soon.
Water is definitely one of the most unique substances we have on this planet.
These researchers obviously have a good hold on compiler technology, since they implemented their checkers with xgcc. They also seem to understand logic quite well, since their code uses and extends on gcc's control-flow analysis algorithms. And they do, actually, understand what's going on here.
As for your particular example, the check really is redundant, but it was almost definitely intentional. It's true that another processor could change the cam variable between the first check and the lock -- but taking the first check out would have no impact on the functionality or correctness of the code. It's just a performance enhancement so that the routine can exit early in the error case, without the overhead of locking the lock. Removing the bit of redundant code would just add a little overhead to the error case.
In short, their checker found a true redundancy. They may have not realized its purpose since they don't have specific experience with this kind of parallel programming, but it's a redundancy. If you had actually read the paper instead of merely glancing over it, you would have seen that their checker respects the volatile nature of variables declared as such -- the checker is fully aware that a second thread can change the value between one operation and the other -- and it still figures out that the check is redundant.
Here's a hint: don't go around claiming people are fools unless you've got some evidence. These guys had hundreds and hundreds of bugs to go through, and expecting them to perfectly analyze every last one of them is unfair.
Oh, and -10 points for using "BZZZZZZT".
15*100000000/3600/24/365 = 47 years.
Maybe he should have 47 years of his time wasted.
(No, I'm not actually serious. But that's a lot of wasted time.)
>There is also some work on hinting, etc, to finish up.
It's good to know we'll be getting a set of manually hinted fonts. But what about those of us (possibly the majority?) who have TrueType bytecode hinting disabled in our FreeType builds? Do these glyphs render well when hinted with FreeType's autohinter?
It would be a shame for the fonts to work well only when the patented bytecode interpretter is enabled in FreeType...
You're making a joke, but the problem you mention is actually a serious one. Ken Thompson who we all know and love from UNIX lore has written Reflections on Trusting Trust which describes just this problem.
Imagine that you insert a backdoor into a compiler, so that everything the compiler compiles is trojaned. If the compiler detects that it is recompiling itself, it quietly reinserts the trojan code. The actual source code to the trojan might be wiped out, but as long as you are running infected binaries, it will keep popping up again and again.
From the paper: "First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."
A very interesting read.
Yes, they are called confirmation/disavowal algorithms. There are several methods by which you can securely "disavow" (disclaim authorship of) a signed document.
Search Google for the term "cryptographic disavowal."
The VMS operating system had (still has?) a configurable boot-time delay which is specified in microfortnights.