A separate, polarized projector? Provide polarized glasses for those who don't want the captioning. That's the cheap route.
A more expensive route would be to have a special screen surface with two sets of hundreds of reflection surfaces, at an acute angle to each other. One surface would be illuminated from a ceiling-mounted projector, the other, a floor-mounted projector.
Both projectors would show the picture, but one would include the captioning. Depending on where you sat in the theater, you'd see one set of surfaces or the other, but not both.
You'd need to angle the overall screen, though, to make the exclusive viewing of one set or the other possible.
Reminds me of something my bio-dad encountered while working at Radio Shack.
A guy walks in, and he's looking for an expensive piece of equipment for his home entertainment sytem. He tells my dad, "I don't want any of this 'Made in Mexico' crap. I want something American. Like Sony."
Allowing a small community of interested volunteers to tidy up the docs wiki-style would work, so long as there's someone in the company who can appropriately funnel questions. Heck, I bet most hardware manufacturers have several engineers who use, even advocate, Linux. These guys might even offer to take on the role of proxy in addition to their normal duties.
He probably meant "mindshare" isntead of "market share."
he more mindshare you have, be it by use of legally or illegally gained products, the larger your market becomes, as your [non]customer exposes his friends to his toy.
Considering the mass of your stereotypical geek, and that of your typical law enfocement agent, you should be prepared as the pirate leftovers from the originial event encounter the other anti-pirate bodies present.
(You are supplying an excess of anti-pirate, right? Your calculations won't come out right if you don't...)
Methinks the interviews are rather old. Consider when the new version of the PS2 was released and when the DS and PSP were released. How credible were the rumors of the new X-Box at the time?
The CDs were around, though I'm not sure they were official.
I didn't use the installer, though. I had a working system...I just copied the filesystem trees and fixed and merged the Packages.gz files. I've still got my own private Debian mirror, even if some of it is a little out of date.:)
I frequently email files to myself, or store info in drafts. And with 2.2GB of webmail mailbox space, it's very, very convenient.
It makes for an easy way to transport data from one locale to another without resorting to a USB pen drive, or other portable media. It also gives me a way to download a file once from a slow server, and store it on a faster one for when I need to retrieve it later.
The implementation of hardware doesn't have to have anything to do with the overall architecture it's attached to. As long as the device sits on a layer that sufficiently distances it from the nuts and bolts of the machine it's part of, there's no reason that, given the same layer in a different machine, that device can't be portable.
As an example, consider PCI devices. As long as the device doesn't have its own BIOS (Namely, video cards), there's no reason you couldn't put the same device in a Mac and in a PC. USB devices are even easier, as there's rarely code on the device that gets run by the host.
However, you still shouldn't see a variable power consumption with TTL as you see with CMOS. With TTL, you have significant current flow regardless of the switched state.
Companies put a lot of thought into their hardware implementations, the results of which would have to be shared after 20 years if they were to patent it. Instead, they choose to keep the details as trade secrets so they can attempt to hold onto them indefinitely, and require their competitors to reinvent the wheel.
The irony of it is, they'll never know if their competitors duplicated their research, so they'll never know where they have an advantage over their competitors, and where they don't.
. But when we move to a system mind setup we'll need to figure out how to handle the lightspeed propagation delays
I wouldn't think we would need to. The human brain operates at chemical speeds, and human perception is limited by lightspeed anyway. Even if we were to assume 1cm^3 per neuron, that's a cube 60m on a side. If a signal needs to go from one side to the other, lightspeed is no object.
(Assuming my math is correct. I'm exhausted...in the time it took me to write this comment, I've been asked for help six or seven times. And that rate has kept up all day.)
each partition would have to communicate with the others; meaning that the boundaries still have some sort of lightspeed propagation problem.
Hm. As long as we're talking about a GPU, and we're not delving into a realtime physics simulation, I don't think we have a problem. At this scale, there's nothing wrong with allowing duplication of effort. You could generate your data as many times as you care to, once for each subprocessor, so long as you can gaurantee a state sync between each one. You'd need your simulation data sent to each processor at the same time.
That suggests a sort of bicone structure. At one peak, you have your simulator. At the circle around the center, you have your GPU. At the other peak, you have your viewing device.
But then again a GPU the size of the solar system would have so many lightspeed delays that you couldn't get a decent framerate out of it.
The key is making the architecture sufficiently wide (superscalar) and sufficiently deep (pipelining) to handle all your pixels. Lightspeed delays don't need to enter into the calculations until the end, unless you intend to accurately simulate effects that travel at the speed of light, such as EM or (theoretically) gravity.
Equip each calculation unit of the GPU with its own projector, and aim them all at your screen. If you shaped the GPU in a circular fashion, the light from each frame will reach your screen at the same time, or near enough for it to be unnoticable.
You'll still need to deal with some awful latency, though. Press a button, and discover that you died before all the elements had a chance to render it.
Well-tested compatibility with the largest DEB repository around.
I'd be afraid to add the Debian repository to my sources list if I ran a different Debian-based distro. I'd be afraid of version incompatibilies. For example, they recently fractured xlib into its component libraries.
If something like that happened in one repository, but not the other, I could have a problem on my hands.
I don't understand what 'content' you're saying the will leak. The hardware specifications are public. Much of the Trusted Software Stack is actually going to be open source.
The only thing of value that the hardware makers could leak would be keys, and those keys will be generated INSIDE the Trust chips and never seen by human eyes. The chips are boobytrapped to self destruct if you attempt to read a key out.
You're a little short on imagination. They have to test the hardware, right? What law of sociology says the engineers aren't going to take DRM'd content they got from somewhere else and strip off the DRM? They control the hardware, don't they? And it's easy to find DRM'd content. Do a search for "wmv" on a P2P network.
Heck, I didn't think of it earlier, but there's even a financial incentive. They merely need to leak a few defective chips (for a decent price, mind you), and someone in China can start decrypting and reselling all the content they can pull down their pipe. And you can bet people will pay for it, so they can play it on their old, perfectly-functional-sans-content equipment.
As for who to sue...leave it to the class-action lawyers. They only get the good money if they win, and they'll do a pretty good job finding someone they'll at least have a chance winning against. And placing multiple parties on the defendants list is perfectly feasible.
The hardware won't work without a signature from the Trusted Computing Group. They will only give that signature to manufacturers contractually handcuffed to make only "secure" and compliant hardware. If some line of hardware is later found to have a "hole" in teh system then the Trusted Computing Group can toss that particular signature on a revokation list and all of that hardware DROPS DEAD. Compliant software will refuse to talk to that hardware or perhaps even refuse to talk to any machine containing that hardware.
My point was, the some of engineers working for the companies under contract will still leak content. Afterall, if a studio employees will leak a copy of something their company stands to benefit from, why wouldn't you expect hardware engineers to leak something their company stands no chance of selling?
Oh, and you can bet there'd be a class action lawsuit if thousands of PCs suddenly stopped playing media content. We're not just talking about the geek elite using OSS, we're talking about people who have no qualms using proprietary software on a proprietary OS...specifically, the vast majority of computer users.
Slashdot Mirror
Short of having live flesh-and-blood players of controllable skill level, there's nothing like bots to enhance an FPS's multiplayer experience.
That's my only gripe with the Battlefield 2 demo.
A separate, polarized projector? Provide polarized glasses for those who don't want the captioning. That's the cheap route.
A more expensive route would be to have a special screen surface with two sets of hundreds of reflection surfaces, at an acute angle to each other. One surface would be illuminated from a ceiling-mounted projector, the other, a floor-mounted projector.
Both projectors would show the picture, but one would include the captioning. Depending on where you sat in the theater, you'd see one set of surfaces or the other, but not both.
You'd need to angle the overall screen, though, to make the exclusive viewing of one set or the other possible.
Reminds me of something my bio-dad encountered while working at Radio Shack.
A guy walks in, and he's looking for an expensive piece of equipment for his home entertainment sytem. He tells my dad, "I don't want any of this 'Made in Mexico' crap. I want something American. Like Sony."
Allowing a small community of interested volunteers to tidy up the docs wiki-style would work, so long as there's someone in the company who can appropriately funnel questions. Heck, I bet most hardware manufacturers have several engineers who use, even advocate, Linux. These guys might even offer to take on the role of proxy in addition to their normal duties.
Ain't community great?
Suddenly it pays to have been a geek at an early age. :)
He probably meant "mindshare" isntead of "market share."
he more mindshare you have, be it by use of legally or illegally gained products, the larger your market becomes, as your [non]customer exposes his friends to his toy.
Considering the mass of your stereotypical geek, and that of your typical law enfocement agent, you should be prepared as the pirate leftovers from the originial event encounter the other anti-pirate bodies present.
(You are supplying an excess of anti-pirate, right? Your calculations won't come out right if you don't...)
All the works of Shakespeare consist of millions of letters. It is merely up to the reader to arrange those letters in the proper order.
(In other words: Read it, compare it, judge it, learn from the differences.)
Methinks the interviews are rather old. Consider when the new version of the PS2 was released and when the DS and PSP were released. How credible were the rumors of the new X-Box at the time?
I don't know...I'm not really a gamer.
Not unless he weighs over 1000 lbs, he isn't.
The CDs were around, though I'm not sure they were official.
:)
I didn't use the installer, though. I had a working system...I just copied the filesystem trees and fixed and merged the Packages.gz files. I've still got my own private Debian mirror, even if some of it is a little out of date.
That's why I look forward to the addition of the PPU.
For a number of years, I didn't have an Internet connection. Debian/testing CD sets were how I stayed up-to-date.
And here I was thinking the gamers are gonna love this. It's the ultimate in ragdoll physics!
I frequently email files to myself, or store info in drafts. And with 2.2GB of webmail mailbox space, it's very, very convenient.
It makes for an easy way to transport data from one locale to another without resorting to a USB pen drive, or other portable media. It also gives me a way to download a file once from a slow server, and store it on a faster one for when I need to retrieve it later.
The implementation of hardware doesn't have to have anything to do with the overall architecture it's attached to. As long as the device sits on a layer that sufficiently distances it from the nuts and bolts of the machine it's part of, there's no reason that, given the same layer in a different machine, that device can't be portable.
As an example, consider PCI devices. As long as the device doesn't have its own BIOS (Namely, video cards), there's no reason you couldn't put the same device in a Mac and in a PC. USB devices are even easier, as there's rarely code on the device that gets run by the host.
I stand corrected.
However, you still shouldn't see a variable power consumption with TTL as you see with CMOS. With TTL, you have significant current flow regardless of the switched state.
Here's how I see it:
Companies put a lot of thought into their hardware implementations, the results of which would have to be shared after 20 years if they were to patent it. Instead, they choose to keep the details as trade secrets so they can attempt to hold onto them indefinitely, and require their competitors to reinvent the wheel.
The irony of it is, they'll never know if their competitors duplicated their research, so they'll never know where they have an advantage over their competitors, and where they don't.
TTL uses power continuously, not just during switching states. So the load on the server should have no relation to the power usage.
. But when we move to a system mind setup we'll need to figure out how to handle the lightspeed propagation delays
I wouldn't think we would need to. The human brain operates at chemical speeds, and human perception is limited by lightspeed anyway. Even if we were to assume 1cm^3 per neuron, that's a cube 60m on a side. If a signal needs to go from one side to the other, lightspeed is no object.
(Assuming my math is correct. I'm exhausted...in the time it took me to write this comment, I've been asked for help six or seven times. And that rate has kept up all day.)
each partition would have to communicate with the others; meaning that the boundaries still have some sort of lightspeed propagation problem.
Hm. As long as we're talking about a GPU, and we're not delving into a realtime physics simulation, I don't think we have a problem. At this scale, there's nothing wrong with allowing duplication of effort. You could generate your data as many times as you care to, once for each subprocessor, so long as you can gaurantee a state sync between each one. You'd need your simulation data sent to each processor at the same time.
That suggests a sort of bicone structure. At one peak, you have your simulator. At the circle around the center, you have your GPU. At the other peak, you have your viewing device.
But then again a GPU the size of the solar system would have so many lightspeed delays that you couldn't get a decent framerate out of it.
The key is making the architecture sufficiently wide (superscalar) and sufficiently deep (pipelining) to handle all your pixels. Lightspeed delays don't need to enter into the calculations until the end, unless you intend to accurately simulate effects that travel at the speed of light, such as EM or (theoretically) gravity.
Equip each calculation unit of the GPU with its own projector, and aim them all at your screen. If you shaped the GPU in a circular fashion, the light from each frame will reach your screen at the same time, or near enough for it to be unnoticable.
You'll still need to deal with some awful latency, though. Press a button, and discover that you died before all the elements had a chance to render it.
I love technical speculation.
Well-tested compatibility with the largest DEB repository around.
I'd be afraid to add the Debian repository to my sources list if I ran a different Debian-based distro. I'd be afraid of version incompatibilies. For example, they recently fractured xlib into its component libraries.
If something like that happened in one repository, but not the other, I could have a problem on my hands.
I don't understand what 'content' you're saying the will leak. The hardware specifications are public. Much of the Trusted Software Stack is actually going to be open source.
The only thing of value that the hardware makers could leak would be keys, and those keys will be generated INSIDE the Trust chips and never seen by human eyes. The chips are boobytrapped to self destruct if you attempt to read a key out.
You're a little short on imagination. They have to test the hardware, right? What law of sociology says the engineers aren't going to take DRM'd content they got from somewhere else and strip off the DRM? They control the hardware, don't they? And it's easy to find DRM'd content. Do a search for "wmv" on a P2P network.
Heck, I didn't think of it earlier, but there's even a financial incentive. They merely need to leak a few defective chips (for a decent price, mind you), and someone in China can start decrypting and reselling all the content they can pull down their pipe. And you can bet people will pay for it, so they can play it on their old, perfectly-functional-sans-content equipment.
As for who to sue...leave it to the class-action lawyers. They only get the good money if they win, and they'll do a pretty good job finding someone they'll at least have a chance winning against. And placing multiple parties on the defendants list is perfectly feasible.
The hardware won't work without a signature from the Trusted Computing Group. They will only give that signature to manufacturers contractually handcuffed to make only "secure" and compliant hardware. If some line of hardware is later found to have a "hole" in teh system then the Trusted Computing Group can toss that particular signature on a revokation list and all of that hardware DROPS DEAD. Compliant software will refuse to talk to that hardware or perhaps even refuse to talk to any machine containing that hardware.
My point was, the some of engineers working for the companies under contract will still leak content. Afterall, if a studio employees will leak a copy of something their company stands to benefit from, why wouldn't you expect hardware engineers to leak something their company stands no chance of selling?
Oh, and you can bet there'd be a class action lawsuit if thousands of PCs suddenly stopped playing media content. We're not just talking about the geek elite using OSS, we're talking about people who have no qualms using proprietary software on a proprietary OS...specifically, the vast majority of computer users.