Right, but when you light up, and you're looking at or near the flame to align it with the cigarette tip, I imagine that would throw your eyes off for a little bit.
When Doom came out, there was very little like it out there in the market. FPSs were a pale comparison at best, the FPS concept wasn't all that well known among the general populus, and Doom was unknown (much less a household name). They needed the demo to get exposure.
Doom 3, on the other hand, is building off the well-respected Doom name, which most everyone already knows. Doom 3, furthermore, has garnered enough praised and reverent press that they already have their sell pretty much locked in through other channels. They don't need a demo.
I doubt it would be too hard to rig up a better reader than that... some motors (even a crank might work), some photocells, a few electronics, then rig it all up to a serial interface.
I'm not saying I personally have the skills, but I can't see it being much harder than things like homebrew barcode readers I've read about.
This is true, but the fact of the matter is that content and presentation still have not been peeled apart in XHTML, and it doesn't look like they will be.
The problem is that the WWW is not purely, nor even primarily, a raw information feed. At one time, sure, it could be said that the Internet was primarily for moving raw information-- facts, figures, and the like-- around. Today, however, the information on much of the Web isn't the only thing that's important. The presentation, the additional rich-media, and the user-experience are also just as important. In many cases, presentation is content.
Hence, I don't see "totally divorced content" becoming part of the mainstream Web. Just like RSS newsfeeds and SOAP interfaces, it will probably end up being a seperate protocol (apart from HTML derivatives), not the evolution of the everyday Web.
If that's the case, a number of very good technologies (XML, RDF, and RSS for information, SOAP and XMLRPC for instructions) already exist, and will probably end up being the foundation for future content-centric design.
Although steps might be taken to try to make XHTML a "contextual markup only" language, I don't think it will ever evolve into something that all-purpose. XHTML will always be used, to some degree, as a content-and-presentation markup.
I'm not totally sure what this IR-to-audio device is, but couldn't you just line-in it to a regular PC (or a tape deck, even) and sound-record with that?
You're not at a disadvantage because you don't know Word, you're at a disadvantage because you don't know how to sell your skills.
For example: Q: Have you worked with Microsoft Word?
A: Actually, I use (OpenOffice, WordPerfect, etc.). (Explain further as necessary...) It has a similar set of features to Microsoft Word, and I use it often. With my general software skills, as well as those in word-processing software, using Microsoft Word at the office should be no problem at all.
Well, I imagine someone good at voice imitations could have a field day with this and your answering machine. They could also imitate the police, an employer, or many other interesting callers.
IIRC, MD5 was based on the idea that even if two or more things had the same MD5 sum, there wouldn't be more than one *intelligible* or *usable* thing with the same MD5.
That's why MD5 works well for error or tampering verification. You might be able to get a big pile of garbage to have the same MD5 as the real message, but you'd be hard-pressed to create any other legible/interpretable data, or wind up with corrupted (slightly different) data with the same hash.
Slashdot Mirror
(looking at product brochure)
Yeah, but how'd you break the "invisible quadruple-ROT13 encryption mechanism"?
Right, but when you light up, and you're looking at or near the flame to align it with the cigarette tip, I imagine that would throw your eyes off for a little bit.
Saying that saying that being... Oh, never mind...
On Deibold letterhead, no less!
You know, I thought of that point just after I hit "post". Even a "torture test demo level" would suffice.
When Doom came out, there was very little like it out there in the market. FPSs were a pale comparison at best, the FPS concept wasn't all that well known among the general populus, and Doom was unknown (much less a household name). They needed the demo to get exposure.
Doom 3, on the other hand, is building off the well-respected Doom name, which most everyone already knows. Doom 3, furthermore, has garnered enough praised and reverent press that they already have their sell pretty much locked in through other channels. They don't need a demo.
I doubt it would be too hard to rig up a better reader than that... some motors (even a crank might work), some photocells, a few electronics, then rig it all up to a serial interface.
I'm not saying I personally have the skills, but I can't see it being much harder than things like homebrew barcode readers I've read about.
This is true, but the fact of the matter is that content and presentation still have not been peeled apart in XHTML, and it doesn't look like they will be.
The problem is that the WWW is not purely, nor even primarily, a raw information feed. At one time, sure, it could be said that the Internet was primarily for moving raw information-- facts, figures, and the like-- around. Today, however, the information on much of the Web isn't the only thing that's important. The presentation, the additional rich-media, and the user-experience are also just as important. In many cases, presentation is content.
Hence, I don't see "totally divorced content" becoming part of the mainstream Web. Just like RSS newsfeeds and SOAP interfaces, it will probably end up being a seperate protocol (apart from HTML derivatives), not the evolution of the everyday Web.
If that's the case, a number of very good technologies (XML, RDF, and RSS for information, SOAP and XMLRPC for instructions) already exist, and will probably end up being the foundation for future content-centric design.
Although steps might be taken to try to make XHTML a "contextual markup only" language, I don't think it will ever evolve into something that all-purpose. XHTML will always be used, to some degree, as a content-and-presentation markup.
Dates: I've always been a fan of "2004-07JY-30". The other ones won't sort alphanumerically.
You could still work this with those time-lapse film surveillence cameras. I imagine they have... well... better... fidelity.
Cause it's not fuuuuturistic enough!
I'm not totally sure what this IR-to-audio device is, but couldn't you just line-in it to a regular PC (or a tape deck, even) and sound-record with that?
Fr-----s? Fr'dashs?
Actually, I imagine both would do a good job of preventing pregnancy.
Reciept comes up in a little window, you hit "OK", it dumps it into the safety-sealed bin.
Until it jams, I guess.
You're not at a disadvantage because you don't know Word, you're at a disadvantage because you don't know how to sell your skills.
For example:
Q: Have you worked with Microsoft Word?
A: Actually, I use (OpenOffice, WordPerfect, etc.). (Explain further as necessary...) It has a similar set of features to Microsoft Word, and I use it often. With my general software skills, as well as those in word-processing software, using Microsoft Word at the office should be no problem at all.
Step 3: Get fired and think it was their fault.
I would imagine a domestic object would work just as well.
Someone correct me if I'm wrong, but wouldn't that component-video monitor be useful as a hi-res/hi-quality DVD-player hookup?
I know what you mean. They're equivalent, but not the same type... shoulda' used !==.
Okay, let's compromise... dead baby corpse.
Well, I imagine someone good at voice imitations could have a field day with this and your answering machine. They could also imitate the police, an employer, or many other interesting callers.
You're right. Technology experts and telecom-legal experts should be out there doing what they do best. Stopping war and disease.
(note sarcasm)
Or perhaps something in the highly-tolled nine-zero-zero area code?
IIRC, MD5 was based on the idea that even if two or more things had the same MD5 sum, there wouldn't be more than one *intelligible* or *usable* thing with the same MD5.
That's why MD5 works well for error or tampering verification. You might be able to get a big pile of garbage to have the same MD5 as the real message, but you'd be hard-pressed to create any other legible/interpretable data, or wind up with corrupted (slightly different) data with the same hash.