Realtime communication with a Martian node is physically impossible. It's simply too far away.
Realistically, we might see a proxy architecture as follows:
1) All traffic is "queued" at an earth-bound substation. Communication is TCP-reliable to this node; transport layer acknowledgements are degraded to "message received by retransmitter" (end-to-gateway) rather than "message received by Mars"(end-to-end). Since both Earth and Mars are in constant rotation, a "change gateway" message would need to exist to route interplanetary traffic to a different satellite node (think "global handoff").
2) Transmission rates from Earth to Mars are constant, no matter the amount of data to send. Extra link capacity is consumed by large-block forward error correction mechanisms. Conceivably, observed or predicted BER's could drive minimum FEC levels (i.e. the more traffic being dropped, due to the relative positions of the Earth and Mars, the less traffic you'd be willing to send in lieu of additional error correction data.
3) Applications would need to be rewritten towards a queue mentality, i.e. the interplanetary link is conceivably the ultimate "long fat pipe". Aggressively publishing content across the interplanetary gap would become much more popular. As much content has gone dynamic, one imagines it becoming possible to publish small virtual machines that emulate basic server side behavior within the various proxies.
You'd think all this was useless research, as there's no reason to go to Mars -- but TCP doesn't just fail when asked to go to Mars; it's actually remarkably poor at handling the multi-second lag inherent in Geosat bounces. Alot of the stuff above is just an extension of what we've been forced to do to deal with such contingencies.
Bah, that's right, I forgot Tiger Trees didn't just refer to the tree mechanism but also the fundamental hash in play.
Regarding the 'hook points' -- a 1GB file has 15M intermediate hashes; this is approximately 2^24. So a 128 bit hash ends up getting dropped down to a strength of 2^104 vs. second preimage. Not a problem.
Now, if you have truncated hashes, it's a different story. Against a 64 bit truncation, it would only take 2^40 tries to collide somewhere inside the file. However, each collision would indeed be vaguely painful to compute, due to the MD-hardening at the end of the file. You still need to end up with a correctly sized file for the final hash to come out the same! So you can't just hash something once and see if it matches a list of intermediate values...you need to hash your desired payload combined with enough extra data to get you to the intermediate hash point. If I'm thinking of this right...bleagh. It means you end up doing much more work than simply creating a "fixit" block after your malicious payload is complete.
kzhash isn't as nice as Tiger Tree, for the specific reason you mention (no leaf/node discriminant). I do think the "md5 stego" channel will eventually be ported to Tiger Trees, but not until we get MD5 collision discovery code.
MD5 won't be in panic stages until second preimage comes into play, thus the "someday". But we're learning so much, so quickly about mechanisms of hash destruction that I think it's going to happen, and soon. Did you see the paper that pointed out that the bigger a file, the more intermediate hashes are inside of it (for either MD5 or SHA-1), and thus the more points there are to collide against while maintaining a route to the correct final hash? Very cool work.
It's a couple pages in my paper here. Basically, the first 300Kb of Kazaa's files are hashed normally, then every 32Kb chunk of the file is hashed independently. This allows independent chunks to be downloaded out of order. These out of order chunks are recursively hashed against one another to create one final value, called a "kzhash", which is verified after the file is downloaded.
The attack is to use the recently released collision -- which creates two blocks that, when mixed against the default initial state of MD5, emit the same system state. Every 32K, you can embed one or the other in the file you're transmitting, and kzhash can't tell. What can you do with this? Morph a file as it traverses the network; have an installation executable describe the systems its being installed on as it propogates through a network. With a fairly large installer, you'd get quite a few bits in there.
You still don't get to do random noise, and while it's no Tiger Tree, kzhashing doesn't appear so exploitable that this group is likely to have anything. I could be wrong, but then, virtual algorithm? Right.
Whoa. Thanks for the info, it's quite appreciated. VR and AI have gone down similar roads, haven't they...
I wouldn't be too down on the Raytheon code; while the mocap guys have certainly been using high resolution, high frame rate cameras to get detailed positioning out of point clouds, they're focused on driving skeletons, not interfaces. From a programmatic point of view, your standard position tracking code wass probably so tied into mocap work that a scratch implementation, built for UI research, was probably preferable. Indeed, only the "live digital puppet" systems are build for realtime (or at least, minimal latency) operation, and they have that annoying dependancy of requiring people to be dressed up in black spandex.
Soldiers don't like black spandex.
In terms of "build your own", the TrackIR3-Pro (120fps in Infrared with existing HID, Directshow, and custom API) isn't bad. But it's not like the system differentiates between different points on the hand, so getting more than 2DOF becomes tricky.
You would have a hard time finding someone who wants autostereoscopy to look good than me. I've bought three different sets of LCD shutter glasses, installed and tweaked ungodly numbers of drivers, and partially went to SIGGRAPH simply to see the state of the art in the technology.
As of September, 2004, it's all awful. I've seen the Sharp Laptop. I've seen the X3D display. I've seen every attempt to create 3D without glasses, and they're all embarassingly bad. One inch of depth does not 3D make, especially not at the cost of visually hideous artifacts (half the horizontal resolution means you end up looking at these double width, very blocky pixels). There was one exception, which used several stacked layers to simulate 3D without attempting to use lensing. The depth was still awful but it didn't hurt at all to look at. Of course, you'd never notice any depth from a distance.
Of course, it's not just lensing that's problematic. I got strapped into not one but two HMD-based systems -- one, a swimming simulator, the other a fairly cool cockpit simulation with per-finger force feedback gloves. Both systems looked cool from the outside, but having played with this stuff off and on since the days of Amiga-based Arcade VR (what *was* the name of that system?) I can tell you it hasn't gotten much better. I wanted it to be immersive, but...no.
Really, the only display tech that really blew me away used dual rear projectors that fed back into one another to achieve alignment, then emitted polarized light onto a single screen. With very light and simple glasses, the effect was utterly seamless.
I vaguely remember the spinning display approach also worked.
In tech, we often find ourselves referring to the Hollywood Operating System. You know, the one where every key press makes a "click" sound, and passwords are cracked one character at a time (admittedly, something that actually worked against Windows 9x file shares).
I was actually impressed with the UI in Minority Report. I'm not saying it was necessarily perfect, but it wasn't obviously ridiculous either. There is a need to monitor information flows across many different sources, to simultaneously sense them, and to have the ability to integrate on demand. A large display with linkable data nodes is one approach that deserves further analysis.
It's much harder with networks. All you really know is that someone sent a message to someone sent a message to someone, and you received something because of it. How do you attack back in such an environment?
The best way is to prevent a counterattack from working against anyone who's innocent of attacking you in the first place. Embedding a counterattack in a TCP session started by your enemy is one approach; if the session was spoofed, your malicious return payload will not be parsed by the recipient of your packets and they'll be left unharmed. Of course, what if your target was made into a member of a botnet? Then things get tricky -- they're liable for the damage their system is doing, but they acted without intent. And intent matters.
Tricky scene, this strikeback. I hadn't looked into it that deeply until Grifter approached me...fascinating subject.
VLC's by far the least arcane of the MPlayer/Xine/VLC trinity. It's also the best way to get a DVD player on Windows (install, put in disc, right click on disc from my computer "play in vlc").
The problem is thus: You have a company that builds nothing, nor does it even research anything. All it does it buy patents on the open market, with an eye not for usefulness or ingenuity but applicability to other people's inventions.
Then they go around and say something very simple: Pay us, or lose your technology.
IBM's been able to fend off such threats for years with nothing but the size of its own portfolio. But Patent Mutually Assured Destruction implies both parties are dependent on actually using the technology embedded within the patents. Like a drug dealer who himself stays clean, pure IP plays avoid the technology and thus suffer no leverage from IBM.
If you don't think real money is involved -- Sony just got the right to sell Playstation taken away (suspended pending appeal), and RIM (of Blackberry) just paid a half-billion to get the right to keep their product on the market. In RIM's case, the patent was on wireless e-mail.
Business thrives on predictability. Patents have become an untenable threat to the markets ability to provide such predictability, and as such even the $1B IBM makes every year pales against the $81B of yearly revenue this patent uncertainty puts at risk.
Bailiwicks -- the idea that a given query can only trust names returned under that query -- weren't really part of the early DNS design process, and aren't at all implied by the underlying structure of the protocol. For example, to any query, you can return a CNAME -- a "canonical name" that should have been looked up. But, for efficiency's sake, you're required to *also* return the address for that canonical name. So I might look up "foo.com", get told "you should have looked up google.com, and oh, by the way Google's IP address is 1.2.3.4". You wouldn't just go to foo.com at 1.2.3.4, you'd cache Google at 1.2.3.4 as well.
What's supposed to happen, nowadays, is that the additional record is still mandatory -- but, it's not to be trusted; a second lookup for google.com (which doesn't match *foo.com) is called for.
What happened here is that someone thought that forwarding meant you trusted someone else implicitly anyway, so why run the bailiwick process? Well, some upstream daemons forward too much from the outside world, that's why. Never trust the network more than you have to.
It's worth noting from a historical perspective that COINTELPRO was the questionable result of the wildly successful program run by the FBI to finally break the back of the Klu Klux Klan in the South. From what I saw, it was a pretty brutal operation...recruited massive numbers of informants, had constant "friendly reminders" that remaining members were being watched, etc.
It you are doing advanced GUI development and prototyping, C++ is probably not the way to go ( since it is harder to write fast and correctly ).
You are incorrect.
It has become quite difficult to ignore the reality that for advanced GUI coding, C++ has established itself as one of the few languages that truly scales to operational use. From an operational standpoint -- meaning, roughly, that the output is actually something you want to run, only the following toolkits have responsive, shell-integrating output:
1) MFC (C++) 2) Qt (C++) 3) WxWindows (C++, and something I've only recently been convinced of by NessusWx. I haven't seen anything fairly mature out of Perl/Python Wx bindings yet. There's a reason everyone's waiting for Open Source Qt4.) 4) Delphi (Very noticably not C++, not exactly Pascal either.) 5) VB (Also not C++, but has an entirely different set of scalability problems)
That's pretty much it. However Swing is to code for, it's more painful to deploy and just a beast to use. (It's 2005 and, like PKI, Java on the Desktop is an expensive joke that's no longer funny.) I keep wanting to see good things from SWT, but however the system looks it's just not very responsive -- either in boot time or in actual use.
The only thing I actually vacillate on is GTK in C. Scite and GAIM provide acceptable, even very good output. It sure doesn't look very nice to code for though.
I reserve judgement on C#'s Windows.Forms for now.
Ultimately, surveying the field, C++ is really doing something right, and it's time people stop repeating the Alice-In-Wonderland myth that you wouldn't want to use it for GUI development. GUI's are one of the big reasons *to* use C++...everything else can hide its performance problems on a remote server, or by the lack of need for interactivity.
Incidentally, don't discount the problems introduced by interpreters. You know why Flash still fails as a GUI hosting platform, despite appearing to be a perfect choice? Event loop speed. Flash updates events only a couple times a second, meaning you're sitting there, waiting hundreds of milliseconds for your change to get noticed. Java has had similar problems.
More of the same, not that I've got any problem with that!
For instance, the Navy's Proteanforge is fantastic on so many levels it's not even funny. Besides being one of the few public Sourceforge deployements outside of sf.net, the code there is just wildly interesting, and has been for several years now.
(It's part of this series of Photoshop Phridays, and is a parody of a rather badly designed advertisement against poverty. Open question: Can there be a well designed advertisement against poverty?)
Side note, huge Trek fan, finally got into Enterprise this season.
"We seem to have a reputation for only making kiddie games." "I know, we'll add a pressure sensitive screen!" "So...like...we'll be touchy *and* kiddie?" "Yes! Who above the age of 16 could possibly be creeped out by that?" "But sir..." "Quiet! Now fetch me the heart of a gamer."
I kid, I kid. Though seriously, GBA games are pretty hard to stomach after, you know, facial hair. Final Fantasy Tactics Advance, with your lets-start-the-game-as-an-eight-year-old-throwing- snowballs-in-an-orphanage, I'm looking at you.
A couple fantastic Metroids, Zeldas, and Castlevanias (and the return of NES) just ain't enough.
Harry Potter, the book: One author, one year. Harry Potter, the movie: Much, much more.
My point is that text adventures are so aggressively different than the rest of the gaming industry that it begs the question how relevant his conclusions are to everyone else. I wouldn't say this except he makes a really big deal about "I'm successful, so who says you can't be?" It's a different world, and a few disclaimers ain't enough.
The fluorescent lamp at the back of every LCD screen flickers at 3000fps. Surely you are not suggesting that video played on my display outputs at 3000fps!
The flicker is not in the projection. The flicker is in the angular deviation against the eye resolving an object moving from one location to another. The lower the framerate, the bigger the jump. This framerate -- not flicker-rate, but framerate -- cannot be covered for by an analog projector. (Digital projectors could concievably interpolate motion vectors.)
Slashdot Mirror
Realtime communication with a Martian node is physically impossible. It's simply too far away.
Realistically, we might see a proxy architecture as follows:
1) All traffic is "queued" at an earth-bound substation. Communication is TCP-reliable to this node; transport layer acknowledgements are degraded to "message received by retransmitter" (end-to-gateway) rather than "message received by Mars"(end-to-end). Since both Earth and Mars are in constant rotation, a "change gateway" message would need to exist to route interplanetary traffic to a different satellite node (think "global handoff").
2) Transmission rates from Earth to Mars are constant, no matter the amount of data to send. Extra link capacity is consumed by large-block forward error correction mechanisms. Conceivably, observed or predicted BER's could drive minimum FEC levels (i.e. the more traffic being dropped, due to the relative positions of the Earth and Mars, the less traffic you'd be willing to send in lieu of additional error correction data.
3) Applications would need to be rewritten towards a queue mentality, i.e. the interplanetary link is conceivably the ultimate "long fat pipe". Aggressively publishing content across the interplanetary gap would become much more popular. As much content has gone dynamic, one imagines it becoming possible to publish small virtual machines that emulate basic server side behavior within the various proxies.
You'd think all this was useless research, as there's no reason to go to Mars -- but TCP doesn't just fail when asked to go to Mars; it's actually remarkably poor at handling the multi-second lag inherent in Geosat bounces. Alot of the stuff above is just an extension of what we've been forced to do to deal with such contingencies.
--Dan
Bah, that's right, I forgot Tiger Trees didn't just refer to the tree mechanism but also the fundamental hash in play.
Regarding the 'hook points' -- a 1GB file has 15M intermediate hashes; this is approximately 2^24. So a 128 bit hash ends up getting dropped down to a strength of 2^104 vs. second preimage. Not a problem.
Now, if you have truncated hashes, it's a different story. Against a 64 bit truncation, it would only take 2^40 tries to collide somewhere inside the file. However, each collision would indeed be vaguely painful to compute, due to the MD-hardening at the end of the file. You still need to end up with a correctly sized file for the final hash to come out the same! So you can't just hash something once and see if it matches a list of intermediate values...you need to hash your desired payload combined with enough extra data to get you to the intermediate hash point. If I'm thinking of this right...bleagh. It means you end up doing much more work than simply creating a "fixit" block after your malicious payload is complete.
Annoying.
Do Tiger Trees encode the final size of the file?
kzhash isn't as nice as Tiger Tree, for the specific reason you mention (no leaf/node discriminant). I do think the "md5 stego" channel will eventually be ported to Tiger Trees, but not until we get MD5 collision discovery code.
MD5 won't be in panic stages until second preimage comes into play, thus the "someday". But we're learning so much, so quickly about mechanisms of hash destruction that I think it's going to happen, and soon. Did you see the paper that pointed out that the bigger a file, the more intermediate hashes are inside of it (for either MD5 or SHA-1), and thus the more points there are to collide against while maintaining a route to the correct final hash? Very cool work.
It's a couple pages in my paper here. Basically, the first 300Kb of Kazaa's files are hashed normally, then every 32Kb chunk of the file is hashed independently. This allows independent chunks to be downloaded out of order. These out of order chunks are recursively hashed against one another to create one final value, called a "kzhash", which is verified after the file is downloaded.
The attack is to use the recently released collision -- which creates two blocks that, when mixed against the default initial state of MD5, emit the same system state. Every 32K, you can embed one or the other in the file you're transmitting, and kzhash can't tell. What can you do with this? Morph a file as it traverses the network; have an installation executable describe the systems its being installed on as it propogates through a network. With a fairly large installer, you'd get quite a few bits in there.
You still don't get to do random noise, and while it's no Tiger Tree, kzhashing doesn't appear so exploitable that this group is likely to have anything. I could be wrong, but then, virtual algorithm? Right.
Whoa. Thanks for the info, it's quite appreciated. VR and AI have gone down similar roads, haven't they...
I wouldn't be too down on the Raytheon code; while the mocap guys have certainly been using high resolution, high frame rate cameras to get detailed positioning out of point clouds, they're focused on driving skeletons, not interfaces. From a programmatic point of view, your standard position tracking code wass probably so tied into mocap work that a scratch implementation, built for UI research, was probably preferable. Indeed, only the "live digital puppet" systems are build for realtime (or at least, minimal latency) operation, and they have that annoying dependancy of requiring people to be dressed up in black spandex.
Soldiers don't like black spandex.
In terms of "build your own", the TrackIR3-Pro (120fps in Infrared with existing HID, Directshow, and custom API) isn't bad. But it's not like the system differentiates between different points on the hand, so getting more than 2DOF becomes tricky.
Johann,
Why don't you check out Actuality's products? The display isn't gigantic, but I remember it being pretty convincing.
Just go ahead and look at an LCD approach. You'll agree. Ew.
OK, I think I tracked down the polarized-light approach to 3D that was unambiguously fantastic. See here.
--Dan
You would have a hard time finding someone who wants autostereoscopy to look good than me. I've bought three different sets of LCD shutter glasses, installed and tweaked ungodly numbers of drivers, and partially went to SIGGRAPH simply to see the state of the art in the technology.
As of September, 2004, it's all awful. I've seen the Sharp Laptop. I've seen the X3D display. I've seen every attempt to create 3D without glasses, and they're all embarassingly bad. One inch of depth does not 3D make, especially not at the cost of visually hideous artifacts (half the horizontal resolution means you end up looking at these double width, very blocky pixels). There was one exception, which used several stacked layers to simulate 3D without attempting to use lensing. The depth was still awful but it didn't hurt at all to look at. Of course, you'd never notice any depth from a distance.
Of course, it's not just lensing that's problematic. I got strapped into not one but two HMD-based systems -- one, a swimming simulator, the other a fairly cool cockpit simulation with per-finger force feedback gloves. Both systems looked cool from the outside, but having played with this stuff off and on since the days of Amiga-based Arcade VR (what *was* the name of that system?) I can tell you it hasn't gotten much better. I wanted it to be immersive, but...no.
Really, the only display tech that really blew me away used dual rear projectors that fed back into one another to achieve alignment, then emitted polarized light onto a single screen. With very light and simple glasses, the effect was utterly seamless.
I vaguely remember the spinning display approach also worked.
--Dan
In tech, we often find ourselves referring to the Hollywood Operating System. You know, the one where every key press makes a "click" sound, and passwords are cracked one character at a time (admittedly, something that actually worked against Windows 9x file shares).
I was actually impressed with the UI in Minority Report. I'm not saying it was necessarily perfect, but it wasn't obviously ridiculous either. There is a need to monitor information flows across many different sources, to simultaneously sense them, and to have the ability to integrate on demand. A large display with linkable data nodes is one approach that deserves further analysis.
At least with guns, you know who you're shooting.
It's much harder with networks. All you really know is that someone sent a message to someone sent a message to someone, and you received something because of it. How do you attack back in such an environment?
The best way is to prevent a counterattack from working against anyone who's innocent of attacking you in the first place. Embedding a counterattack in a TCP session started by your enemy is one approach; if the session was spoofed, your malicious return payload will not be parsed by the recipient of your packets and they'll be left unharmed. Of course, what if your target was made into a member of a botnet? Then things get tricky -- they're liable for the damage their system is doing, but they acted without intent. And intent matters.
Tricky scene, this strikeback. I hadn't looked into it that deeply until Grifter approached me...fascinating subject.
--Dan
Heh, thanks :)
As long as we're discussing the MD5 stuff:
Slashdot
E-Print of the original paper
Vlastimil Kilma's research on the topic
The finally released paper by Xiaoyun Wang, the original discoverer of this attack
Enjoy!
--Dan
*whistles innocently*
Recent build? VLC's gotten *much* better.
VLC's by far the least arcane of the MPlayer/Xine/VLC trinity. It's also the best way to get a DVD player on Windows (install, put in disc, right click on disc from my computer "play in vlc").
--Dan
The point is, it's not enough to have a good idea. Build something, or make way for those who will.
The development of pure-IP plays is scaring IBM.
The problem is thus: You have a company that builds nothing, nor does it even research anything. All it does it buy patents on the open market, with an eye not for usefulness or ingenuity but applicability to other people's inventions.
Then they go around and say something very simple: Pay us, or lose your technology.
IBM's been able to fend off such threats for years with nothing but the size of its own portfolio. But Patent Mutually Assured Destruction implies both parties are dependent on actually using the technology embedded within the patents. Like a drug dealer who himself stays clean, pure IP plays avoid the technology and thus suffer no leverage from IBM.
If you don't think real money is involved -- Sony just got the right to sell Playstation taken away (suspended pending appeal), and RIM (of Blackberry) just paid a half-billion to get the right to keep their product on the market. In RIM's case, the patent was on wireless e-mail.
Business thrives on predictability. Patents have become an untenable threat to the markets ability to provide such predictability, and as such even the $1B IBM makes every year pales against the $81B of yearly revenue this patent uncertainty puts at risk.
--Dan
Bailiwicks -- the idea that a given query can only trust names returned under that query -- weren't really part of the early DNS design process, and aren't at all implied by the underlying structure of the protocol. For example, to any query, you can return a CNAME -- a "canonical name" that should have been looked up. But, for efficiency's sake, you're required to *also* return the address for that canonical name. So I might look up "foo.com", get told "you should have looked up google.com, and oh, by the way Google's IP address is 1.2.3.4". You wouldn't just go to foo.com at 1.2.3.4, you'd cache Google at 1.2.3.4 as well.
What's supposed to happen, nowadays, is that the additional record is still mandatory -- but, it's not to be trusted; a second lookup for google.com (which doesn't match *foo.com) is called for.
What happened here is that someone thought that forwarding meant you trusted someone else implicitly anyway, so why run the bailiwick process? Well, some upstream daemons forward too much from the outside world, that's why. Never trust the network more than you have to.
--Dan
It's worth noting from a historical perspective that COINTELPRO was the questionable result of the wildly successful program run by the FBI to finally break the back of the Klu Klux Klan in the South. From what I saw, it was a pretty brutal operation...recruited massive numbers of informants, had constant "friendly reminders" that remaining members were being watched, etc.
The real question is--
Can I run LinuxBios on this? If so, where can I buy one pre-loaded?
It you are doing advanced GUI development and prototyping, C++ is probably not the way to go ( since it is harder to write fast and correctly ).
You are incorrect.
It has become quite difficult to ignore the reality that for advanced GUI coding, C++ has established itself as one of the few languages that truly scales to operational use. From an operational standpoint -- meaning, roughly, that the output is actually something you want to run, only the following toolkits have responsive, shell-integrating output:
1) MFC (C++)
2) Qt (C++)
3) WxWindows (C++, and something I've only recently been convinced of by NessusWx. I haven't seen anything fairly mature out of Perl/Python Wx bindings yet. There's a reason everyone's waiting for Open Source Qt4.)
4) Delphi (Very noticably not C++, not exactly Pascal either.)
5) VB (Also not C++, but has an entirely different set of scalability problems)
That's pretty much it. However Swing is to code for, it's more painful to deploy and just a beast to use. (It's 2005 and, like PKI, Java on the Desktop is an expensive joke that's no longer funny.) I keep wanting to see good things from SWT, but however the system looks it's just not very responsive -- either in boot time or in actual use.
The only thing I actually vacillate on is GTK in C. Scite and GAIM provide acceptable, even very good output. It sure doesn't look very nice to code for though.
I reserve judgement on C#'s Windows.Forms for now.
Ultimately, surveying the field, C++ is really doing something right, and it's time people stop repeating the Alice-In-Wonderland myth that you wouldn't want to use it for GUI development. GUI's are one of the big reasons *to* use C++...everything else can hide its performance problems on a remote server, or by the lack of need for interactivity.
Incidentally, don't discount the problems introduced by interpreters. You know why Flash still fails as a GUI hosting platform, despite appearing to be a perfect choice? Event loop speed. Flash updates events only a couple times a second, meaning you're sitting there, waiting hundreds of milliseconds for your change to get noticed. Java has had similar problems.
More of the same, not that I've got any problem with that!
For instance, the Navy's Proteanforge is fantastic on so many levels it's not even funny. Besides being one of the few public Sourceforge deployements outside of sf.net, the code there is just wildly interesting, and has been for several years now.
Not to mention the funding the Navy put into Onion Routing Research and it's very popular implementation.
Make Trek History.
(It's part of this series of Photoshop Phridays, and is a parody of a rather badly designed advertisement against poverty. Open question: Can there be a well designed advertisement against poverty?)
Side note, huge Trek fan, finally got into Enterprise this season.
I wonder how that meeting went:
- snowballs-in-an-orphanage, I'm looking at you.
"We seem to have a reputation for only making kiddie games."
"I know, we'll add a pressure sensitive screen!"
"So...like...we'll be touchy *and* kiddie?"
"Yes! Who above the age of 16 could possibly be creeped out by that?"
"But sir..."
"Quiet! Now fetch me the heart of a gamer."
I kid, I kid. Though seriously, GBA games are pretty hard to stomach after, you know, facial hair. Final Fantasy Tactics Advance, with your lets-start-the-game-as-an-eight-year-old-throwing
A couple fantastic Metroids, Zeldas, and Castlevanias (and the return of NES) just ain't enough.
Harry Potter, the book: One author, one year.
Harry Potter, the movie: Much, much more.
My point is that text adventures are so aggressively different than the rest of the gaming industry that it begs the question how relevant his conclusions are to everyone else. I wouldn't say this except he makes a really big deal about "I'm successful, so who says you can't be?" It's a different world, and a few disclaimers ain't enough.
Iron realms makes text adventures.
Such games have not been published retail in approximately twenty years.
Players of such games are wildly at the fringes, and would probably happily admit it.
It would seem unwise to use Iron Realms' games, gamers, publication model, or general experiences as something that's generalizable in 2005.
Not that I disagree with all of his sentiments, of course.
EvilO--
The fluorescent lamp at the back of every LCD screen flickers at 3000fps. Surely you are not suggesting that video played on my display outputs at 3000fps!
The flicker is not in the projection. The flicker is in the angular deviation against the eye resolving an object moving from one location to another. The lower the framerate, the bigger the jump. This framerate -- not flicker-rate, but framerate -- cannot be covered for by an analog projector. (Digital projectors could concievably interpolate motion vectors.)
--Dan