That's all good stuff, except for the 4-MHz ISA bus bit - IIRC, EISA can also slurp data from the DMA channel at 8MHz. Not that it makes any difference compared to PCI...
But what you're describing sounds suspiciously much like symmetric encryption, with some trickery to make sure that a certain program (who knows the token, aka key) can only access the data once before it's overwritten.
This means that at some point the computer that decrypts the file (i.e. the user's computer) knows what the required decryption key is. Which in turn means that if the main program of the content control system (whereever it may be) is analyzed to find out where the "last tokens" are stored and how (which gives us a decryption key to the token database at the very least), the system will become breakable.
The main problem of this type of systems is, of course, that you really really can't expect to keep a file secret when you give both the decryption key (i.e. the first token) and the data to the user.
So, you're saying that InTether cannot be traced using a PC emulator? That a piece of software (in this case, "driver-type code", which isn't really any different from normal application programs apart from running on a different ring) can decrypt something pseudo-automatically and not have the decryption key (or algorithm state, which is pretty much the same thing) somewhere in RAM where an interested party can trivially snarf it out?
Listen, "dude", there have been countless attempts at binary program security (disassembly thwarting), of which exactly 0 have worked. Remember, code == data, software == hardware.
Oh yeah, your semantic trickery (that "it's not security, it's content control" bit there) is a fucking smokescreen. Get real.
The SSH stock is about to tank. So he needs a convenient scapegoat so that he can show to the stockholders that it wasn't his fault. ("it" what? dunno.)
He has a gigantic second thought about his releasing an early version of SSH1 under the BSD license (fork-and-forget, remember?).
As proof, I'll direct your attention to the "OpenSSH is causing us damage" bit in his e-mail.
Do you mean RC4 with a 128-bit key? RC4 has a 256-byte internal state, so you could theoretically speaking use a 256-byte key for 2048 bits of key entropy.
You obviously haven't used cdparanoia combined with LAME. At the highest-quality setting, LAME produces mp3 files that are completely indistinguishable to human ears from the original, while getting a compression ratio of 5 or 6 to 1, for industrial music (I've seen some ambient music [tangerine dream - alpha centauri, to be precise] compress at the highest-quality VBR setting to 11-to-one).
Saying that "mp3's sound like crap" makes you look like a fool with a record+play sync program (i.e. a bad ripper) and the worst version of the Xing mp3 encoder.
Actually, that's pretty much what the Pentium Pro (ergo p2, p3, celeron, celeron2 and the p4) do - only there it's done using "virtual registers" which means that the register "eax" can map to a completely different physical register if the instruction scheduler needs it to.
(now I'm pretty sure that's not the best way to do it - it's just an example, ok?)
Now, if you have another multi-instruction operation after this and it's going to use any of the registers used above, the CPU will see in the decoding phase that "a-ha! eax has received a value that doesn't depend on itself (i.e. a completely new value)" and will assign a different physical register to "eax" until it's overwritten again. (this is also the reason who xor reg,reg is not the preferred way of clearing a register on the ppro and up.)
Same for ebx and ecx and the other regs. By the time the CPU is finished decoding these instructions (this would take 1 and 1/3 cycles for ppro through p3 and 1 cycle for the p4 (due to the 4-1-1-1 decoders)), the reorder buffer (that receives the decoded instructions, also called micro-ops or uops) will have been filled up with previously decoded instructions and will be able to put as many uops into the execution "ports" as possible (3 per cycle in ppro through p3, not sure about the p4).
This, of course, assumes that the code is organised so that the decoders can feed the reorder buffer with more than 3 micro-ops per decoding cycle, so that there's something to reorder. But this will, for the most part, take care of that data-dependency problem.
Personally, I prefer explicit register setting (a'la PowerPC, 32 int regs + 32 fp regs) so that the CPU won't have to schedule instructions for me...
(all this information, except for the p4 decoder uop-max series, comes from the excellent pentopt.txt file.)
Since I know you're smart enough to read a license and understand it, I can only assume you're lying in a cynical attempt to
manipulate the Free Software community
The BSD license without the advertising clause qualifies as non-copyleft free software, according to this page here. I'm not entirely sure if BSD-with-advertising-clause qualifies too. Anyhow, in this document the fsf states that the XFree86 license is the preferred non-copyleft free license out there.
Psst. Software SDMI player + wine/{free,v}mware + a competent cracker (like they were in the 1980s and early 1990s) + a case of jolt -> SDMI format decoder that spits out the actual encoding instead of either the encrypted crap or the raw PCM output.
I think these guys are going to have a shit fit once someone hacks the "digital rights management" stuff in the console, like they did with the MOD-chip for the Playstation2.
Mark my words, the hackers will prove that TANSTACP (There Ain't No Such Thing As Copy Protection).
Not to mention that some companies (SGI comes to mind, also the company that did the Permedia {1,2,3} product line) have shipped products that have implemented most of the OpenGL pipeline (1.0 or 1.1) in silicon. Now, if that doesn't count as a GPU then I'm sure that "GPU" must be a registered trademark, like "Twinview" is.
Ugh. Not to mention the fact that the G200 and G400 chips from Matrox also have a kind of geometry processing unit, called a "warp engine" that's programmable using some sort of proprietary microcode (the utah-glx project used pieces of binary-only microcode received from Matrox, and I'm pretty sure the XF86 4.0 DRIver does too).
As far as I can tell from lurking on the utah-glx list back when John C. was working on the driver, the g200 has one warp pipe while the g400 has two.
It looks like the current drivers for the g200 and g400 use the warp pipes for triangle setup acceleration (they only seem to use one microcode routine for triangle setup, which I think is a shame...).
Based on my interpretation, that also counts as a GPU, programmable no less!
Re:nVidia's high end vs. low end
on
Nvidia's NV20
·
· Score: 1
This may also be the real explanation for the drivers' closed-sourceness - a part of their business model is to have manufacturers ship boards that facilitate crippling of the chip's capabilities by the driver. Imagine what would happen if some open-source hacker could modify the driver to ignore the model ID and enable the Quadro-specific features anyway?
Re:About the 2-7x faster...
on
Nvidia's NV20
·
· Score: 1
The word you're looking for is "hierarchical Z-buffers". "Hidden surface removal" is a blanket phrase that covers such things as z-sorting (used in early software 3d engines), BSP rendering without a depth buffer, S-buffers, the "active edge list" algorithm used in the software renderers in Quake 1 (and prolly 2 too) and the good old z-buffer.
Please, don't let some corporation smudge the terminology.
Re:3D Realism is becoming dangerous.
on
Nvidia's NV20
·
· Score: 1
Psst, you're still looking at the damn computer screen while playing. Psst, the game doesn't hurt like discovering the foot of a stool in the dark with one of those small toes on your foot does. Psst, you don't play "real life" with a mouse and the WSAD keys.
Token-symbol-ish enough for you?
The next thing you're going to do is start claiming that each time you die "in the game", you die a little inside. Furrfu!
You know, "hidden surface removal" really doesn't mean that they have any special magic tricks up their sleeve. You can do pretty much correct HSR with a 16-bpp z-buffer, as long as you are careful with your near and far clipping planes. 32 bits per depth pixel is better, of course.
What I'd like to see is a hardware implementation of hierarchical z-buffering for occlusion culling. That'd be neat.
Slashdot Mirror
That's all good stuff, except for the 4-MHz ISA bus bit - IIRC, EISA can also slurp data from the DMA channel at 8MHz. Not that it makes any difference compared to PCI...
But what you're describing sounds suspiciously much like symmetric encryption, with some trickery to make sure that a certain program (who knows the token, aka key) can only access the data once before it's overwritten.
This means that at some point the computer that decrypts the file (i.e. the user's computer) knows what the required decryption key is. Which in turn means that if the main program of the content control system (whereever it may be) is analyzed to find out where the "last tokens" are stored and how (which gives us a decryption key to the token database at the very least), the system will become breakable.
The main problem of this type of systems is, of course, that you really really can't expect to keep a file secret when you give both the decryption key (i.e. the first token) and the data to the user.
So, you're saying that InTether cannot be traced using a PC emulator? That a piece of software (in this case, "driver-type code", which isn't really any different from normal application programs apart from running on a different ring) can decrypt something pseudo-automatically and not have the decryption key (or algorithm state, which is pretty much the same thing) somewhere in RAM where an interested party can trivially snarf it out?
Listen, "dude", there have been countless attempts at binary program security (disassembly thwarting), of which exactly 0 have worked. Remember, code == data, software == hardware.
Oh yeah, your semantic trickery (that "it's not security, it's content control" bit there) is a fucking smokescreen. Get real.
Nope, you're thinking about unlambda.
You know, without the "none of those canonical fantasy creatures" bit, nethack would qualify.
From what I can tell, Tatu is pissed off because
As proof, I'll direct your attention to the "OpenSSH is causing us damage" bit in his e-mail.
Mail fraud?
Do you mean RC4 with a 128-bit key? RC4 has a 256-byte internal state, so you could theoretically speaking use a 256-byte key for 2048 bits of key entropy.
IANACryptologist, of course :-)
You obviously haven't used cdparanoia combined with LAME. At the highest-quality setting, LAME produces mp3 files that are completely indistinguishable to human ears from the original, while getting a compression ratio of 5 or 6 to 1, for industrial music (I've seen some ambient music [tangerine dream - alpha centauri, to be precise] compress at the highest-quality VBR setting to 11-to-one).
Saying that "mp3's sound like crap" makes you look like a fool with a record+play sync program (i.e. a bad ripper) and the worst version of the Xing mp3 encoder.
I wouldn't worry - it looks like the ".net initiative" will render itself irrelevant soon enough.
True, although register renaming eliminates some of the "data-dependency" problem he mentioned.
Actually, that's pretty much what the Pentium Pro (ergo p2, p3, celeron, celeron2 and the p4) do - only there it's done using "virtual registers" which means that the register "eax" can map to a completely different physical register if the instruction scheduler needs it to.
For example, you could write your code like this:
mov ebx, Pointer
mov cx, [ebx]
mov eax, [ebx+cx]
mov Pointer2, eax
(now I'm pretty sure that's not the best way to do it - it's just an example, ok?)
Now, if you have another multi-instruction operation after this and it's going to use any of the registers used above, the CPU will see in the decoding phase that "a-ha! eax has received a value that doesn't depend on itself (i.e. a completely new value)" and will assign a different physical register to "eax" until it's overwritten again. (this is also the reason who xor reg,reg is not the preferred way of clearing a register on the ppro and up.) Same for ebx and ecx and the other regs. By the time the CPU is finished decoding these instructions (this would take 1 and 1/3 cycles for ppro through p3 and 1 cycle for the p4 (due to the 4-1-1-1 decoders)), the reorder buffer (that receives the decoded instructions, also called micro-ops or uops) will have been filled up with previously decoded instructions and will be able to put as many uops into the execution "ports" as possible (3 per cycle in ppro through p3, not sure about the p4).
This, of course, assumes that the code is organised so that the decoders can feed the reorder buffer with more than 3 micro-ops per decoding cycle, so that there's something to reorder. But this will, for the most part, take care of that data-dependency problem.
Personally, I prefer explicit register setting (a'la PowerPC, 32 int regs + 32 fp regs) so that the CPU won't have to schedule instructions for me...
(all this information, except for the p4 decoder uop-max series, comes from the excellent pentopt.txt file.)
Dude! Occam's razor!
Oh yeah, this is just fucking great. Some dickhead merkin with too much time on his slimy twitching little paws vaguely downmoderates me. Asshole.
Or, you could disassemble the original C compiler and look for suspicious sections. Although I won't believe that they've actually done that.
The BSD license without the advertising clause qualifies as non-copyleft free software, according to this page here. I'm not entirely sure if BSD-with-advertising-clause qualifies too. Anyhow, in this document the fsf states that the XFree86 license is the preferred non-copyleft free license out there.
Psst. Software SDMI player + wine/{free,v}mware + a competent cracker (like they were in the 1980s and early 1990s) + a case of jolt -> SDMI format decoder that spits out the actual encoding instead of either the encrypted crap or the raw PCM output.
Just you wait.
I think these guys are going to have a shit fit once someone hacks the "digital rights management" stuff in the console, like they did with the MOD-chip for the Playstation2.
Mark my words, the hackers will prove that TANSTACP (There Ain't No Such Thing As Copy Protection).
... short of increasing the pay? Pray, pray hard.
Not to mention that some companies (SGI comes to mind, also the company that did the Permedia {1,2,3} product line) have shipped products that have implemented most of the OpenGL pipeline (1.0 or 1.1) in silicon. Now, if that doesn't count as a GPU then I'm sure that "GPU" must be a registered trademark, like "Twinview" is.
Ugh. Not to mention the fact that the G200 and G400 chips from Matrox also have a kind of geometry processing unit, called a "warp engine" that's programmable using some sort of proprietary microcode (the utah-glx project used pieces of binary-only microcode received from Matrox, and I'm pretty sure the XF86 4.0 DRIver does too). As far as I can tell from lurking on the utah-glx list back when John C. was working on the driver, the g200 has one warp pipe while the g400 has two. It looks like the current drivers for the g200 and g400 use the warp pipes for triangle setup acceleration (they only seem to use one microcode routine for triangle setup, which I think is a shame...).
Based on my interpretation, that also counts as a GPU, programmable no less!
This may also be the real explanation for the drivers' closed-sourceness - a part of their business model is to have manufacturers ship boards that facilitate crippling of the chip's capabilities by the driver. Imagine what would happen if some open-source hacker could modify the driver to ignore the model ID and enable the Quadro-specific features anyway?
The word you're looking for is "hierarchical Z-buffers". "Hidden surface removal" is a blanket phrase that covers such things as z-sorting (used in early software 3d engines), BSP rendering without a depth buffer, S-buffers, the "active edge list" algorithm used in the software renderers in Quake 1 (and prolly 2 too) and the good old z-buffer.
Please, don't let some corporation smudge the terminology.
Psst, you're still looking at the damn computer screen while playing. Psst, the game doesn't hurt like discovering the foot of a stool in the dark with one of those small toes on your foot does. Psst, you don't play "real life" with a mouse and the WSAD keys.
Token-symbol-ish enough for you?
The next thing you're going to do is start claiming that each time you die "in the game", you die a little inside. Furrfu!
You know, "hidden surface removal" really doesn't mean that they have any special magic tricks up their sleeve. You can do pretty much correct HSR with a 16-bpp z-buffer, as long as you are careful with your near and far clipping planes. 32 bits per depth pixel is better, of course.
What I'd like to see is a hardware implementation of hierarchical z-buffering for occlusion culling. That'd be neat.
The key phrase here is "mandatory core hours from 9-3". Which, in my book, pretty much makes it as un-flex-time-y as can be.
Ahh, internal corporate marketing. Gotta love it.