...and then the folks can remove the poisons and drink on. Many ways are in use, from bubbling air through the mixture (when the denaturing agens has higher vapor tension than ethanol), to absorbing the agens in fat (a coagulated milk is excellent for this purpose) when the agens is fat-soluble (maybe a multi-stage extraction to vegetable oil could work too, if the oil wouldn't contain compounds that would dissolve in the alcohol phase and ruin its taste). Then the finishing touch with column distillation or activated carbon to remove the last traces of the denaturating agens, adding some herbal essences, and - cheers!
EXT3 support is irrelevant when you have a rescue boot CD in your hand and are approaching a crashed NT machine with disks full of NTFS, or when somebody comes with a removable disk in NTFS format. DirectX support is important for running non-native code under emulators. If nobody would have any compatibility requirements, you'd be correct, though.
Not necessarily. According to some reports, good chunks of the code are pretty lousy. Such pieces can be used as powerful argument to convince openness-sceptical managers that proprietary code is not necessarily less crappy than the open one.
...and at the end you end with something that can be fooled by even a single-character difference in the checksummed block. A fuzzy matching algorithm would be much better than comparison of hashes, but I have no clue how to prevent contact with the code then.
What about technical manuals and science books then? Are they art, or not? If not, are their writers tainted if they happen to read other, related manuals and science books? If yes, why are they considered to be art and code isn't?
Can the single-cell organisms be turned into nanofactories, very similar to the way GM bacteria now produce eg. insulin? Why they couldn't produce the proteins that would self-assembly, like viral capsidas, into engines and even complete microdevices? Inject DNA or RNA into the cells the way viruses do, let the cells produce the desired nanodevices or nanoparticles as a "byproduct" of their life, while reproducing themselves? Can the nanodevices then carry their own blueprint in the form of a packed strand of nucleic acid, destined to be reproduced when a suitable host cell is found, again in a viral fashion?
Not exactly a safe thing to do, but amusing to ponder.
The contemporary printers are a handful of building blocks; the head assembly, the head drivers, the stepper motors, some sensors, interface circuits, printing language interpreters for page rendering (which can be outsourced to the host computer). Some parameters vary by brand and model, but the principle is all the same. Can't we design a board with a suitably big FPGA and motor drivers, that then could be put into a "shell" of a printer, replacing its original electronics? Giving the host computer direct control over the printer's motors and head? The design could be generic enough to allow use of most of lower-cost inkjets, with only relatively minimal reconfiguration of the control firmware.
It would eliminate all the firmware-introduced problems and limitations, from unwanted image artefact detection to the Lexmark-DMCA cartridge issues.
As added value, such controller board could have many many more various uses, to control everything with sensors and stepper motors.
If you allow sharing generic binary files, and then do acoustic fingerprinting of MP3s and match them against a database of "offending" ones, you effectively did nothing. Any kind of reversible encoding your software isn't designed to - including but not limited to simple XORing with a constant - will break the fingerprint matching. People *will* use it then, if they won't move to other networks without such hassle. You *CAN NOT* be effectively responsible for the content of the network you create; there are WAY too many workarounds around any possible built-in limitation. Last but not least, designing such limitations - if they have to be at least remotely effective - rivals in complexity the P2P problematics itself (no, simple MD5 won't work).
Get some analog voltmeters. Get an I2C DAC chip, eg. a TDA8444 (which is a set of 8 6-bit DACs). Connect the SCL and SDA lines to the serial (after voltage-limiting to TTL levels, eg. with resistor and a Zener diode) or parallel port. Send output voltages of the DACs by bit-banging the I2C lines. Optionally put output drivers on the outputs, if the voltmeters eat too much, or if you want to drive eg. banks of red, green, and blue LEDs. You can stack several TDA8444s together on the same bus, and drive not only the voltmeters, but also the LEDs that backlight them, so the dial can show the actual stock market value, while the backlight hue is red for fall, green for rise, and yellow for stagnant. Or you can just switch the LEDs on-off, and use a suitable I2C-to-8bit expander.
With a microcontroller and eg. a Radiotronix Wi.232 wireless module you can even have it wirelessly connected to the computer that feeds it with the data.
If you want to be really Ambient, you may improvise the swappable faceplates with some kind of encoding what ones are placed on (which may be as simple as a set of microswitches against pins or holes in the back of the faceplates, with the number of the plate BCD-encoded; many other options possible).
Little problem with this. If I understand the issue correctly, cable behaves quite like old 10Base2 Ethernet; what's sent into it is sent to everybody on the segment. The total bandwidth of the segment is limited, not only the upstream connectivity.
The fundamental difference between Windows and unixes that mitigates the impact of user-opened worms lies in the file permissions. If the mail client doesn't allow executing of the received binary or script, the worm won't run. The attachments aren't sent with file permission informations (except maybe when uuencoded, and masking away the executable flags is trivial), they are assigned client-side. If the attachment doesn't have executable flag, it won't run. If it won't run, it won't infect, it won't spread. It HAS a lot to do with the OS.
Control fairly impossible to enforce. They could lock the copiers, but there are other copies around. Furthermore, a 3-megapixel photograph of an open book is pretty much legible - you can borrow both the book and the camera, or a friend - even from another university - can do a service for you and then mail or ftp you the PDF or a set of JPGs. (Which, as added advantage, is much easier to keep as reference for years later.)
32-bit depth, 192 kHz samplerate... Too much for audio, but think beyond it. Think about all the signal processing applications - various sensors you can connect to the computer and let it process the incoming data. Think about all the scientific applications.
Think also about the intelligence applications. This depth/samplerate provides lots of redundancy, which is interesting for steganography applications. Think about trusted moderate-speed random number generators for cryptographic applications - just add a white noise generator and cryptographic whitening.
This is a GOOD thing, with many more uses than it may look, regardless of what the detractors say about overkill specs.
As a mad scientist, I can attest that the sharks-with-lasers are a myth. Sharks are too dumb for any practical purpose. Much better results were achieved with laser-equipped specially trained neurally augmented dolphins.
Slashdot Mirror
...and then the folks can remove the poisons and drink on. Many ways are in use, from bubbling air through the mixture (when the denaturing agens has higher vapor tension than ethanol), to absorbing the agens in fat (a coagulated milk is excellent for this purpose) when the agens is fat-soluble (maybe a multi-stage extraction to vegetable oil could work too, if the oil wouldn't contain compounds that would dissolve in the alcohol phase and ruin its taste). Then the finishing touch with column distillation or activated carbon to remove the last traces of the denaturating agens, adding some herbal essences, and - cheers!
EXT3 support is irrelevant when you have a rescue boot CD in your hand and are approaching a crashed NT machine with disks full of NTFS, or when somebody comes with a removable disk in NTFS format. DirectX support is important for running non-native code under emulators. If nobody would have any compatibility requirements, you'd be correct, though.
Not necessarily. According to some reports, good chunks of the code are pretty lousy. Such pieces can be used as powerful argument to convince openness-sceptical managers that proprietary code is not necessarily less crappy than the open one.
...and at the end you end with something that can be fooled by even a single-character difference in the checksummed block. A fuzzy matching algorithm would be much better than comparison of hashes, but I have no clue how to prevent contact with the code then.
This can happen to you regardless if you actually saw the code. You can't reliably prove you didn't ever see $whatever.
Isn't it EXACTLY what anonymity/pseudonymity was designed for?
What about technical manuals and science books then? Are they art, or not? If not, are their writers tainted if they happen to read other, related manuals and science books? If yes, why are they considered to be art and code isn't?
Some of them shoot back.
Not exactly a safe thing to do, but amusing to ponder.
It would eliminate all the firmware-introduced problems and limitations, from unwanted image artefact detection to the Lexmark-DMCA cartridge issues.
As added value, such controller board could have many many more various uses, to control everything with sensors and stepper motors.
In other news: Feds win rights to war protesters records
Of course, if you don't plan to ever disagree with your government, you don't have anything to fear...
One word: Stalkers.
If you allow sharing generic binary files, and then do acoustic fingerprinting of MP3s and match them against a database of "offending" ones, you effectively did nothing. Any kind of reversible encoding your software isn't designed to - including but not limited to simple XORing with a constant - will break the fingerprint matching. People *will* use it then, if they won't move to other networks without such hassle. You *CAN NOT* be effectively responsible for the content of the network you create; there are WAY too many workarounds around any possible built-in limitation. Last but not least, designing such limitations - if they have to be at least remotely effective - rivals in complexity the P2P problematics itself (no, simple MD5 won't work).
The correct link to the developer pages is http://www.ambientdevices.com/developer/
Get some analog voltmeters. Get an I2C DAC chip, eg. a TDA8444 (which is a set of 8 6-bit DACs). Connect the SCL and SDA lines to the serial (after voltage-limiting to TTL levels, eg. with resistor and a Zener diode) or parallel port. Send output voltages of the DACs by bit-banging the I2C lines. Optionally put output drivers on the outputs, if the voltmeters eat too much, or if you want to drive eg. banks of red, green, and blue LEDs. You can stack several TDA8444s together on the same bus, and drive not only the voltmeters, but also the LEDs that backlight them, so the dial can show the actual stock market value, while the backlight hue is red for fall, green for rise, and yellow for stagnant. Or you can just switch the LEDs on-off, and use a suitable I2C-to-8bit expander.
With a microcontroller and eg. a Radiotronix Wi.232 wireless module you can even have it wirelessly connected to the computer that feeds it with the data.
If you want to be really Ambient, you may improvise the swappable faceplates with some kind of encoding what ones are placed on (which may be as simple as a set of microswitches against pins or holes in the back of the faceplates, with the number of the plate BCD-encoded; many other options possible).
Little problem with this. If I understand the issue correctly, cable behaves quite like old 10Base2 Ethernet; what's sent into it is sent to everybody on the segment. The total bandwidth of the segment is limited, not only the upstream connectivity.
The fundamental difference between Windows and unixes that mitigates the impact of user-opened worms lies in the file permissions. If the mail client doesn't allow executing of the received binary or script, the worm won't run. The attachments aren't sent with file permission informations (except maybe when uuencoded, and masking away the executable flags is trivial), they are assigned client-side. If the attachment doesn't have executable flag, it won't run. If it won't run, it won't infect, it won't spread. It HAS a lot to do with the OS.
Control fairly impossible to enforce. They could lock the copiers, but there are other copies around. Furthermore, a 3-megapixel photograph of an open book is pretty much legible - you can borrow both the book and the camera, or a friend - even from another university - can do a service for you and then mail or ftp you the PDF or a set of JPGs. (Which, as added advantage, is much easier to keep as reference for years later.)
Easier way: Clone the downloaded data between the units. Then both units have the downloads, and there is only one call to the server per diem.
32-bit depth, 192 kHz samplerate... Too much for audio, but think beyond it. Think about all the signal processing applications - various sensors you can connect to the computer and let it process the incoming data. Think about all the scientific applications.
Think also about the intelligence applications. This depth/samplerate provides lots of redundancy, which is interesting for steganography applications. Think about trusted moderate-speed random number generators for cryptographic applications - just add a white noise generator and cryptographic whitening.
This is a GOOD thing, with many more uses than it may look, regardless of what the detractors say about overkill specs.
Cheese plasma? Couldn't that be a way to produce REALLY thin culinary-grade cheese slices by epitaxial growth from vaporized cheese? :)
They already make cheesy semiconductors.
What about to try it the other way? Mount it on a track on the side of the lawn, press a button, and THEN have a really flat lawn! :)
It can turn any cheese into Emmental.
As a mad scientist, I can attest that the sharks-with-lasers are a myth. Sharks are too dumb for any practical purpose. Much better results were achieved with laser-equipped specially trained neurally augmented dolphins.