Ok, I just had a thought. However, it depends on the ECC bits being used internally even for digital audio extraction. My understanding is that the whole point of macrovision for CDs was to write occasional bogus ECC codes, forcing the low-level read circuitry to always misread certain packets. The internal DAC knows which these are, and thus interpolates, but there is no way of signalling this on the digital output channel. My sheme relies on the digital output still getting the ECC treatment. Can you confirm whether this is the case?
If it is, then this might work:
ECC codes work (in the most abstact terms) by taking a (I'll pick some representative numbers) 40 bit raw word, and mapping it to a 32 bit data word. Using Grey codes you can (I'm making these numbers up) correct up to 8 incorrectly read bits per raw word, while detecting up to 18 raw bit errors.
Thus, the ECC can often reconstruct the data from the redundant bits. But these packets that the macrovision people write have bad ECC. So hopefully (more speculation) they would not ECC to the same value. Ie a bogus packet will consistently be misread, but will not be consistently ECCed to the same data for different read errors. However, the good packets will consistently be ECCed to the same value (that's what ECC is for, after all).
So my scheme is to induce a slightly higher raw error rate in reads (wiping with a dirty rag?), and to re-rip the disk seveal times (with a randomizing wipe between each rip). This will hopefully be low enough to allow good packets to be consistently reconstructed by ECC, while allowing bogus packets to be identified as such as they will ECC to different values for each read.
The reason you can't do error correction in software is that in general, the software does not have access to the ECC bits, so it doesn't know what is error and what is data.
You get something like this (In reality, i suspect they don't use 32/8 bit words, but you get the idea):
(erm. There was going to be ascii art here, but apparently it was lame)
Anyways, from the disk, you get xx raw bits of data, and yy bits of ECC information. From these, you try to create xx bits of good data. I'll call the xx+yy a packet, for lack of a better term.
The copy prevention works by writing bogus packets where the ECC codes don't correspond to the read data.
The thing is that this all happens in the CRROM's hardware. The ripper never gets to see the ECC bits, so it doesn't know which bits come from real packets, and which are bogus. So it doesn't know which to interpolate and which to trust. Of course the CD-ROM's dac knows which to interpolate. To make things worse, if the CD is of high quality, the scrambled words will repeatedly be read the same, so rereadign the sector/track won't indicate where the error is.
A suggested circumvention
Conceivably, a slightly degraded disc might rip better, because this would excersize the ECC circuitry. My thinking is that a if you insert intentional and random read errors in the raw read of a packet (by breathing on it or wiping it with a greasy rag), a good packet will tend to be ECCed to the same ideal data for various rereads (perhaps after a re-wipe to randomise the errors), while the bogus packet, by virtue of having BAD ECC data, will tend to be ECCed to different values.
The main difficulty will be getting the degradation to be bad enough to cause REAL read errors so that most packets will require ECC but not so many errors as to overwhelm the error correcting codes.
remember when netscape inventing the tag was the height of distraction? Heck, even webmonkey (ah! old hotwired of yore) had diatribes against that one tag. And now we have flashy popups that... well, blink.
The more they change, there's nothing new under the sun.
wha?
When did this happen? As of yesterday, when I last checked out the state of the world, yahoo had no such shenanigans. Yahoo news has long been my news source of choice, so I am VERY suprised at your allegations.
You misunderstood. To continue with your sexual example: you go to europe, screw some 16 year old, no one arrests you. But as soon as you go to the US, you'd promptly get arrested as a sex offender. This without having broken any laws in the US.
1) It seems a fall onto carpet from a desk would be a lot less than 3400Gs, esp as the microdrive is light, so the carpet will be "springy".
2) It's all cubes vs squares: the mass of the moving parts, and hence the force they exert under accelleration, varies with the cube of the size, while the cross section of the parts, and hence their rigidity, varies with the square. So every halving in feature size doubles the Gs it can withstand.
When you realize that this applies to the head going back and forth over the platter, it explains why drives got smaller (physically) before they got larger (capacity): smaller drives have better reliability.
Re:Appliances have always been in trouble....
on
Death of a Rebel
·
· Score: 2
Rebels were never competing for the $500 bracket. Try three times that. The problem with netwinders is that they were overpriced, underpowered, and too loud (!) for the home hobbyist market.
I seriously looked into getting one, but the 275 Mhz strongarm, single-digit GB HD and double digit MB RAM just couldn't justify the ~ $1500 pricetag, esp as lower end AMDs easily outclassed them in pretty much all regards other than form factor.
The form factor would have been cool (as would the second eth port) if it weren't for the fact that the fan by accounts was quite loud, meaning that the lack of a power switch became a liability.
For the same price as a rebel, I could (and did) just as well buy a nonname laptop, be generous with RAM+HD, get more processor power, silent operation, and get an LCD and a battery (albeit a crap battery life, but more than adequate as a 30 min UPS) for free. AND the ability to dual boot into windows for the occasional game.
Rebel going under isn't a shame, it's just plain common sense. They had pretty much ZERO advantage with which to compete. And I DID try hard to justify getting one, as they were so damn cool, but just couldn't.
I thought color separation was just a matter of decomposing the picture to another color space, so that instead of R/G/B or Y/Cr/Cb (erm may be wrong on the Cx) you went to C/M/Y/K. That seems unpatentable.
Or does the separation process involve some sort of screening as well? That I thought was also somewhat folk-lorish, with error diffusion being commonly taught in schools (I know I experimented with a somewhat ad-hoc monte-carlo technique for one project).
Could you expand on where the patent encumberance comes in?
Jiazzi (java version of Units)
Subject Oriented Programming and its successor HyperJ, at IBM.
JADE and PIROL
Java modules by Ancona and Zucca (possibly unimplemented)
AspectJ isn't quite as pluggable as you are looking for, I don't think, but is very mature.
I have a project under construction that should be added to the list, but it isn't quite ready for limelight yet.
For just papers, see recent work by Lieberherr and Mezini (various papers also with Seiter and Lorenz), Ian Holland's Ph.D. thesis on contracts.
Actually, with a few mirrors, some lasers to determine distance, and decent station keeping software for the thrusters, I suspect NASA should be able to conjure up a Long Baseline Array out of these satelites.
IIRC (and it was a long time ago) to do this for visible wavelengths, you'd need to measure the distance between the satelites down to (making this up) 150nm.
Still, it would be pretty nifty. Not that you could ever resolve a licence plate, even if you had the resolution, without correcting for atmospheric effects, but cool all the same.
Re:Best reply to Mundie yet.
on
GPL FAQ
·
· Score: 2
This isn't van eck-ing, as the keyboard is BROADCASTING a signal that is MEANT to be picked up. This makes it orders of magnitude easier to pick up, as it is designed to stand out from the noise.
On the other hand, completely passive van eck setups need to do alot of work separating the signal they are interested in from the background noise.
On a completely different note: those concerned about password security can move to a face-recognition login setup, which would require the attacker to capture the screen in order to compromise security,
Re:Best reply to Mundie yet.
on
GPL FAQ
·
· Score: 2
Unfortunately, the GPL also has the crappy restriction that I (as the non-copyright holder) can't add my closed source plugin to it.
This would seem to me to be completely valid thing to do: Say I write a great plugin for the GIMP that requires a slightly enhanced pluging API. I release my changes to the source code (people can merge or fork), and then allow people to buy the plugin if they want it. Others can recreate my plugin in an open manner, if they care enough, and everyone can use the better API.
However, the GPL would seem to make it nigh impossible to get a third-party plugin market started for the GIMP in the same way that Bryce et. al. sell plugins for Photoshop.
I see how you could argue that closed software should not be allowed to depend on open, as this would only enable closed source people to piggy-back on open software, but I just can't understand the converse situation.
What is the GIMP and open source in general gaining from not having commercial plugins? Absolutely nothing. Instead, professionals are locked into using closed source. Great! good one FSF! That worked really well, now didn't it?
This just seems like a stupid argument, so I'm probably missing something.
I tried to manually upgrade libc (or whatever). So I rm-ed the symlink, and then tried to ln -s to the upgraded.x library. Unfortunately, ln (and a whole slew of other commands) are dynamically linked...
That one took some juggling to solve. I now have a staticically linked ldconf.
Most stand alone LCD I've seen have been fuzzy, every laptop LCD razor sharp. I suspect it has to do with laptops having digital connections to the LCD, while many standalones go digital-analog-digital. Obviously, apple's new offerings will be all digital, and the few apple 15" LCDs I've seen have been gorgeous.
you're thinking that an increase in speed of merely a billion times (or ANY physically possible multiplier) is going to help you brute force 256 bit keys?
</flame>
I suggest you go check up on the properties of exponents. A billion times faster is the same as reducing the keyspace by 30 bits: leaving you with a task equivalent to bruteforcing a 226 bit key on current hardware. If you make it a billion billion times faster, I need merely add 60 bits to my key to regain the previous level of security.
The thing about quantuum computers is that they are good at reducing the order of complexity of certain computations -- in this case factorisation. You only need to start worrying about symmetric keys when a quantum computer can solve NP problems in P time. But then you REALLY have to start worrying, because ALL symmetric ciphers are in NP.
The several people argument is based on the fact that instead of having only two images interleaved and redirected by the lens as I described above, they have several. So if you display four pixels per lenticular stripe, you get three sweet spots -> three people (or one person who can move his head).
However, each additional pixel you allocate per lens implies a corresponding decrease in horizontal resolution. One workaround is to keep it monochrome: this effectively multiplies the horizontal resolution of [formerly color] LCD panel by three. Otherwise, the lenses become so wide that you'll end up noticing the horisontal banding. Another workaround would be to stagger the lenticular lenses (more of a hassle to manufacture, tho), so that the pixels no longer get alligned in one vertical line.
That is indeed the most promising option open for real 3d. The idea is stunningly simple: if you decrease the angel of dispersion of the lenses, you can engineer it so that one eye sees one frame of the "animation" while the other eye sees the next.
Not great if they are two successive frames in time, but if instead each frame shows a picture from a slightly different viewpoint, you get 3d. Instead of a fixed picture, you put that cracker jack lens (a fresnel lens, in effect) infront of a display with the resolution set to show two pixels per ridge -- one per eye.
The only problem is that it will be pretty sensitive to keeping your head in the "sweet spot". And the positioning of the lens wrt the pixels on the screen is tricky, but that is all ok, because this sucker is cheap. the only hardware you need is a massproduced piece of plastic. The rest is software, interleaving the stripes from each eye's view.
Not as nice as a hologram, true, but in terms of bag for buck, really hard to beat.
Metro-Goldwyn-Moskva buys movie rights for six million rubles, changing title to "The Eternal Triangle", with Ingrid Bergman playing part of hypotenuse
does it still only do the crappy multiple windows only inside the mother window? I mean, even MS Word, which I think was the initial reason why MS introduced that misfeature, eventually came to its senses and put all the windows on the desktop.
Slashdot Mirror
Ok, I just had a thought. However, it depends on the ECC bits being used internally even for digital audio extraction. My understanding is that the whole point of macrovision for CDs was to write occasional bogus ECC codes, forcing the low-level read circuitry to always misread certain packets. The internal DAC knows which these are, and thus interpolates, but there is no way of signalling this on the digital output channel. My sheme relies on the digital output still getting the ECC treatment. Can you confirm whether this is the case?
If it is, then this might work:
ECC codes work (in the most abstact terms) by taking a (I'll pick some representative numbers) 40 bit raw word, and mapping it to a 32 bit data word. Using Grey codes you can (I'm making these numbers up) correct up to 8 incorrectly read bits per raw word, while detecting up to 18 raw bit errors.
Thus, the ECC can often reconstruct the data from the redundant bits. But these packets that the macrovision people write have bad ECC. So hopefully (more speculation) they would not ECC to the same value. Ie a bogus packet will consistently be misread, but will not be consistently ECCed to the same data for different read errors. However, the good packets will consistently be ECCed to the same value (that's what ECC is for, after all).
So my scheme is to induce a slightly higher raw error rate in reads (wiping with a dirty rag?), and to re-rip the disk seveal times (with a randomizing wipe between each rip). This will hopefully be low enough to allow good packets to be consistently reconstructed by ECC, while allowing bogus packets to be identified as such as they will ECC to different values for each read.
Comments solicited
You get something like this (In reality, i suspect they don't use 32/8 bit words, but you get the idea):
(erm. There was going to be ascii art here, but apparently it was lame)
Anyways, from the disk, you get xx raw bits of data, and yy bits of ECC information. From these, you try to create xx bits of good data. I'll call the xx+yy a packet, for lack of a better term.
The copy prevention works by writing bogus packets where the ECC codes don't correspond to the read data.
The thing is that this all happens in the CRROM's hardware. The ripper never gets to see the ECC bits, so it doesn't know which bits come from real packets, and which are bogus. So it doesn't know which to interpolate and which to trust. Of course the CD-ROM's dac knows which to interpolate. To make things worse, if the CD is of high quality, the scrambled words will repeatedly be read the same, so rereadign the sector/track won't indicate where the error is.
A suggested circumvention
Conceivably, a slightly degraded disc might rip better, because this would excersize the ECC circuitry. My thinking is that a if you insert intentional and random read errors in the raw read of a packet (by breathing on it or wiping it with a greasy rag), a good packet will tend to be ECCed to the same ideal data for various rereads (perhaps after a re-wipe to randomise the errors), while the bogus packet, by virtue of having BAD ECC data, will tend to be ECCed to different values.
The main difficulty will be getting the degradation to be bad enough to cause REAL read errors so that most packets will require ECC but not so many errors as to overwhelm the error correcting codes.
I think. I've never actually ripped a cd myself.
remember when netscape inventing the tag was the height of distraction? Heck, even webmonkey (ah! old hotwired of yore) had diatribes against that one tag. And now we have flashy popups that... well, blink.
The more they change, there's nothing new under the sun.
wha?
When did this happen? As of yesterday, when I last checked out the state of the world, yahoo had no such shenanigans. Yahoo news has long been my news source of choice, so I am VERY suprised at your allegations.
You misunderstood. To continue with your sexual example: you go to europe, screw some 16 year old, no one arrests you. But as soon as you go to the US, you'd promptly get arrested as a sex offender. This without having broken any laws in the US.
can they?
Don't they have to inform patent infringers formally before they start charging for it?
As an infringer I have to have a choice whether to pay up or to change technology, no?
1) It seems a fall onto carpet from a desk would be a lot less than 3400Gs, esp as the microdrive is light, so the carpet will be "springy".
2) It's all cubes vs squares: the mass of the moving parts, and hence the force they exert under accelleration, varies with the cube of the size, while the cross section of the parts, and hence their rigidity, varies with the square. So every halving in feature size doubles the Gs it can withstand.
When you realize that this applies to the head going back and forth over the platter, it explains why drives got smaller (physically) before they got larger (capacity): smaller drives have better reliability.
Rebels were never competing for the $500 bracket. Try three times that. The problem with netwinders is that they were overpriced, underpowered, and too loud (!) for the home hobbyist market.
I seriously looked into getting one, but the 275 Mhz strongarm, single-digit GB HD and double digit MB RAM just couldn't justify the ~ $1500 pricetag, esp as lower end AMDs easily outclassed them in pretty much all regards other than form factor.
The form factor would have been cool (as would the second eth port) if it weren't for the fact that the fan by accounts was quite loud, meaning that the lack of a power switch became a liability.
For the same price as a rebel, I could (and did) just as well buy a nonname laptop, be generous with RAM+HD, get more processor power, silent operation, and get an LCD and a battery (albeit a crap battery life, but more than adequate as a 30 min UPS) for free. AND the ability to dual boot into windows for the occasional game.
Rebel going under isn't a shame, it's just plain common sense. They had pretty much ZERO advantage with which to compete. And I DID try hard to justify getting one, as they were so damn cool, but just couldn't.
?
I thought color separation was just a matter of decomposing the picture to another color space, so that instead of R/G/B or Y/Cr/Cb (erm may be wrong on the Cx) you went to C/M/Y/K. That seems unpatentable.
Or does the separation process involve some sort of screening as well? That I thought was also somewhat folk-lorish, with error diffusion being commonly taught in schools (I know I experimented with a somewhat ad-hoc monte-carlo technique for one project).
Could you expand on where the patent encumberance comes in?
ta.
I dunno. Maybe I'm just getting crabby, but these automatic "hey maybe the RIAA will outlaw this " don't even rate a smile.
Likewise all the "I'll patent breathing!" posts.
I can't figure out whether the posters really think they're original, or just cynically fishing for mod points.
Various reseach projects with implementations:
Jiazzi (java version of Units)
Subject Oriented Programming and its successor HyperJ, at IBM.
JADE and PIROL
Java modules by Ancona and Zucca (possibly unimplemented)
AspectJ isn't quite as pluggable as you are looking for, I don't think, but is very mature.
I have a project under construction that should be added to the list, but it isn't quite ready for limelight yet.
For just papers, see recent work by Lieberherr and Mezini (various papers also with Seiter and Lorenz), Ian Holland's Ph.D. thesis on contracts.
Of course you want to swap. Swapping unused apps out alows the OS to reuse that RAM as filesystem cache, which is almost always a good idea.
No mod points (I'm sure someone will do me the favor), but I wanted to thank you for a clear and concise explanation.
Have a good weekend.
Actually, with a few mirrors, some lasers to determine distance, and decent station keeping software for the thrusters, I suspect NASA should be able to conjure up a Long Baseline Array out of these satelites.
IIRC (and it was a long time ago) to do this for visible wavelengths, you'd need to measure the distance between the satelites down to (making this up) 150nm.
Still, it would be pretty nifty. Not that you could ever resolve a licence plate, even if you had the resolution, without correcting for atmospheric effects, but cool all the same.
http://www.gnu.org/copyleft/gpl-faq.html#GPLAndPlu gins
This isn't van eck-ing, as the keyboard is BROADCASTING a signal that is MEANT to be picked up. This makes it orders of magnitude easier to pick up, as it is designed to stand out from the noise.
On the other hand, completely passive van eck setups need to do alot of work separating the signal they are interested in from the background noise.
On a completely different note: those concerned about password security can move to a face-recognition login setup, which would require the attacker to capture the screen in order to compromise security,
Unfortunately, the GPL also has the crappy restriction that I (as the non-copyright holder) can't add my closed source plugin to it.
This would seem to me to be completely valid thing to do: Say I write a great plugin for the GIMP that requires a slightly enhanced pluging API. I release my changes to the source code (people can merge or fork), and then allow people to buy the plugin if they want it. Others can recreate my plugin in an open manner, if they care enough, and everyone can use the better API.
However, the GPL would seem to make it nigh impossible to get a third-party plugin market started for the GIMP in the same way that Bryce et. al. sell plugins for Photoshop.
I see how you could argue that closed software should not be allowed to depend on open, as this would only enable closed source people to piggy-back on open software, but I just can't understand the converse situation.
What is the GIMP and open source in general gaining from not having commercial plugins? Absolutely nothing. Instead, professionals are locked into using closed source. Great! good one FSF! That worked really well, now didn't it?
This just seems like a stupid argument, so I'm probably missing something.
What?
the pedant notes that when going whoring, getting screwed and getting out ok are not mutually exclusive.
I tried to manually upgrade libc (or whatever). So I rm-ed the symlink, and then tried to ln -s to the upgraded .x library. Unfortunately, ln (and a whole slew of other commands) are dynamically linked...
That one took some juggling to solve. I now have a staticically linked ldconf.
I concurr.
Most stand alone LCD I've seen have been fuzzy, every laptop LCD razor sharp. I suspect it has to do with laptops having digital connections to the LCD, while many standalones go digital-analog-digital. Obviously, apple's new offerings will be all digital, and the few apple 15" LCDs I've seen have been gorgeous.
Does your SGI have a digital cable? IIRC it does.
you're thinking that an increase in speed of merely a billion times (or ANY physically possible multiplier) is going to help you brute force 256 bit keys?
</flame>
I suggest you go check up on the properties of exponents. A billion times faster is the same as reducing the keyspace by 30 bits: leaving you with a task equivalent to bruteforcing a 226 bit key on current hardware. If you make it a billion billion times faster, I need merely add 60 bits to my key to regain the previous level of security.
The thing about quantuum computers is that they are good at reducing the order of complexity of certain computations -- in this case factorisation. You only need to start worrying about symmetric keys when a quantum computer can solve NP problems in P time. But then you REALLY have to start worrying, because ALL symmetric ciphers are in NP.
The several people argument is based on the fact that instead of having only two images interleaved and redirected by the lens as I described above, they have several. So if you display four pixels per lenticular stripe, you get three sweet spots -> three people (or one person who can move his head).
However, each additional pixel you allocate per lens implies a corresponding decrease in horizontal resolution. One workaround is to keep it monochrome: this effectively multiplies the horizontal resolution of [formerly color] LCD panel by three. Otherwise, the lenses become so wide that you'll end up noticing the horisontal banding. Another workaround would be to stagger the lenticular lenses (more of a hassle to manufacture, tho), so that the pixels no longer get alligned in one vertical line.
ah, you mock.
That is indeed the most promising option open for real 3d. The idea is stunningly simple: if you decrease the angel of dispersion of the lenses, you can engineer it so that one eye sees one frame of the "animation" while the other eye sees the next.
Not great if they are two successive frames in time, but if instead each frame shows a picture from a slightly different viewpoint, you get 3d. Instead of a fixed picture, you put that cracker jack lens (a fresnel lens, in effect) infront of a display with the resolution set to show two pixels per ridge -- one per eye.
The only problem is that it will be pretty sensitive to keeping your head in the "sweet spot". And the positioning of the lens wrt the pixels on the screen is tricky, but that is all ok, because this sucker is cheap. the only hardware you need is a massproduced piece of plastic. The rest is software, interleaving the stripes from each eye's view.
Not as nice as a hologram, true, but in terms of bag for buck, really hard to beat.
does it still only do the crappy multiple windows only inside the mother window? I mean, even MS Word, which I think was the initial reason why MS introduced that misfeature, eventually came to its senses and put all the windows on the desktop.