Slashdot Mirror


Spray-On Computers

Jack William Bell writes "Edinburgh University has funding for a program to create spray on computers. The basic idea is to make thousands of tiny 'silicon specks' or 'smart sand' (a step larger than smart dust) which work together via wireless networking to provide 'ubiquitous computing.' No, the idea itself isn't new. But it is interesting to see someone actually working on it. The initial application is a spray you apply to the chest of heart patients, creating a sensor array to report their health back to the hospital."

3 of 155 comments (clear)

  1. This could be dangerous by grug0 · · Score: 5, Informative
    Inhaling small particles of silicon dioxide, which is used as a coating on silicon chips, can lead to silicosis. Silicosis causes damage and scarring of the lungs, and possibly death.

    The idea of spraying silicon chips directly onto patients should be approached with caution.

  2. Re:They only forgot one thing - power by akedia · · Score: 4, Informative

    Ever build one of those crystal radio kits you got from RadioShack as a kid? Those had way larger components than we're talking here, and they were powered by small electric currents from the AM (Amplitude Modulation) radio waves.

    With these spray-on computers, you could easily add a small circuitry that could provide power just from stray radio waves. IIRC you would just need a magnetic coil, a diode and a transistor. That would provide plenty of power for the scale we're talking here.

  3. Re:I doubt that this ubiquious stuff will ever wor by hankaholic · · Score: 4, Informative
    XML not being "binary based" is a good thing -- you can view the file contents with anything from a program created specifically to work with that schema down to lowly "cat" or "less".

    XML's textual nature keeps XML documents "open". I did a Google search a while ago when trying to determine whether there was a standard scheme for putting binary data into XML, and came across somebody discussing parse times for XML. He'd written a program which parsed XML and saved the parsed version in a binary format, and found that it was actually faster to just parse the XML again than to reconstruct the information from his binary format.

    On one hand, sure, perhaps his coding wasn't up to the level of those who'd written the XML parser, which might account for the slower loading.

    On the other hand, there's a good chance that someone writing an XML parser intended for general inclusion within other programs is paying a lot more attention to doing things right (in terms of speed, security, etc.) than the person who writes a quick data-parsing routine.

    Computers don't care if humans can read their data, sure. But, humans do. Parsing a simple, well-defined text format isn't computationally expensive, and makes the job easier for those who might have cause to view the data.

    Finally, XML tags can and do carry important semantic information. It's much easier to write a program to parse an arbitrary unknown XML schema (say, GnuCash's file format) than to have to reverse-engineer an arbitrary unknown binary format (yes, I've done both). This is important because it helps to ensure that the data isn't quite as bound to the program -- parsing and conversion between schemas is generally much easier than, say, translating a WordPerfect document to MS Word format.

    Hans Reiser has even decided to use text in his transaction-control syscalls:

    To anyone who has worked in databases or any other aspect of language design, this design surely seems exceedingly simple and modest. To many filesystem and OS folks, this seems like something extraordinary; commands that are parsed, oh no! The complexity will be extraordinary, oh no! Sigh. Namesys, determined to bring radical new 1960's technology from other areas of computer science into the filesystems field no matter how crazy our competitors think we are! Sigh. Reiser4 will be smaller than XFS much less VxFS....
    Text parsing isn't as bad as people like to make it, as long as you aren't parsing a horribly ugly specification (like, say, C++ code).

    Besides, how is carrying something on top of HTTP going to introduce new security holes? I haven't been able to decide where you are implying the issues might arise.
    --
    Somebody get that guy an ambulance!