Slashdot Mirror

An anonymous reader writes with a followup to last week's report that certain Xerox scanners and copiers could alter numbers as they scanned documents: "In the second Xerox press statement, Rick Dastin, Vice President at Xerox Corporation, stated: 'You will not see a character substitution issue when scanning with the factory default settings.' In contrast, David Kriesel, who brought up the issue in the first place, was able to replicate the issue with the very same factory settings. This might be a serious problem now. Not only does the problem occur using default settings and everyone may be affected, additionally, their press statements may have misled customers. Xerox replicated the issue by following Kriesel's instructions, later confirming it to Kriesel. Whole image segments seem to be copied around the scanned data. There is also a new Xerox statement out now." Swapping numbers while copying may seem like bizarre behavior for a copier, but In comments on the previous posting, several readers pointed out that Xerox was aware of the problem, and acknowledged it in the machine's documentation; the software updates promised should be welcome news to anyone who expects a copier to faithfully reproduce important numbers.

leighklotz writes "PARC, which a few years ago was said be be targeted for a spin-off from Xerox, has signed on its first major partner under its new life as a wholly-owned subsidiary of Xerox. Fujitsu has announced "Joint Research in Ubiquitous Computing," a three-year sponsored-research plan beginning in January 2005. 'Because we're not a product company, we need a partner like Fujitsu who can deliver our products into the marketplace,' said Teresa Lunt, according to InfoWorld."

GraWil asks: "Does anyone have advice on purchasing a color laser printer? I'm trying to decide between getting a new small 'personal' color laser or a used/refurbished workhorse. For the roughly the same money, I can either buy a Xerox 6100 or a refurbished Tektronix 740/750 or even a tabloid sized 790. I've had mixed luck with color HP and Lexmark printers but I'm open to any suggestions at this point. There are a fair number of reviews but none of them ever compare new with the old."

GraWil asks: "Does anyone have advice on purchasing a color laser printer? I'm trying to decide between getting a new small 'personal' color laser or a used/refurbished workhorse. For the roughly the same money, I can either buy a Xerox 6100 or a refurbished Tektronix 740/750 or even a tabloid sized 790. I've had mixed luck with color HP and Lexmark printers but I'm open to any suggestions at this point. There are a fair number of reviews but none of them ever compare new with the old."

GraWil asks: "Does anyone have advice on purchasing a color laser printer? I'm trying to decide between getting a new small 'personal' color laser or a used/refurbished workhorse. For the roughly the same money, I can either buy a Xerox 6100 or a refurbished Tektronix 740/750 or even a tabloid sized 790. I've had mixed luck with color HP and Lexmark printers but I'm open to any suggestions at this point. There are a fair number of reviews but none of them ever compare new with the old."

GraWil asks: "Does anyone have advice on purchasing a color laser printer? I'm trying to decide between getting a new small 'personal' color laser or a used/refurbished workhorse. For the roughly the same money, I can either buy a Xerox 6100 or a refurbished Tektronix 740/750 or even a tabloid sized 790. I've had mixed luck with color HP and Lexmark printers but I'm open to any suggestions at this point. There are a fair number of reviews but none of them ever compare new with the old."

Chirag Mehta writes "I just released a freeware service called BotBlock (barebones demo) that lets site owners copy/paste a few lines of PHP code and insert a CAPTCHA image-verification system into any web form. The amount of form spamming by bots is on a rise. While remedies exist for MT blogs, a more efficient solution is to use image-verification or text-identification. Used for a while by sites like Yahoo! (scroll to bottom), Hotmail and patented in 2001 by AltaVista, CAPTCHAs are now being used more widely. PARC also came up with two algorithms Baffletext and Pessimal Print. The technology always existed, but until now required the site owners to install image libraries and understand how to generate images that cannot be OCR'ed. With BotBlock it is like inserting a page counter."

An anonymous reader submits: "The Savannah site (the Free Software sequel of SourceForge) has just announced a much enhanced Bug Tracking System contributed by Xerox. From the news it sounds like Xerox has engaged into an internal source code sharing initiative based on the SourceForge platform and it has decided to contribute all their changes to the Savannah project ..."

levin writes "An article in the latest issue of IEEE spectrum discusses modular robots--robots made of small, identical components or modules. These robots can slither, roll like a tank tread, inchworm, or crawl like a spider. The idea is that modular robots will be not only cheaper to build because the modules are all the same, but will be more able to repair themselves (by shedding damaged modules). Even cooler, each of the 5cm cube modules in Xerox PARC's polybot sports its own PowerPC 555 and 1mb ram."

An reader writes "I was watching Discovery Channel Canada last night, and they had a story about modular robotics that is being researched at Xerox PARC. Rather than build a single, large robot, project leader Mark Yim is working on small, autonomous bots that can work together to achieve a desired goal. When many of this bots are linked together, they call the result a polybot. "

An reader writes "I was watching Discovery Channel Canada last night, and they had a story about modular robotics that is being researched at Xerox PARC. Rather than build a single, large robot, project leader Mark Yim is working on small, autonomous bots that can work together to achieve a desired goal. When many of this bots are linked together, they call the result a polybot. "

person writes: "The Stanford Social Web calculates social interactions of members of the Stanford University network, using links and text from home pages, as well as information about mailing list subscriptions. Though the site's analysis of user relationships and similarities is limited to those with Stanford accounts, it is of interest to those studying the formation of social networks. The java applet is especially nifty." Don't even try the java applet if you don't have a fast machine, PIII or higher.

addaon writes: "Every once and in while, it's nice to have a bold look at the future of computing. A recent article over at Discover Magazine shares James Martin's latest ruminations. While, on one level, this is just another discussion of ubiquitous computing, it's well-presented and insightful." Martin has some big ideas (though ones many people born after 1980 may think simply obvious). This piece also mentions the very interesting experiments in evolutionary computing carried out by Adrian Thompson of the University of Sussex.

n7lyg writes: "Xerox PARC has come up with a way to embed data in printed images that involves using something called DataGlyphs. A DataGlyph is essentially an oblong pixel that takes the value of zero or one depending on whether it is printed angled to the left or right. Printed at sufficiently fine resolution, this is no different from ordinary offset printing effects using circular pixels, but when scanned by a computer allows recovery of arbitrary data embedded in the images or text of the printed page. An article in this month's IEEE Computer contains a lot of interesting applications of this technology, including a system to allow teachers to create printed tests and lab assignments with embedded DataGlyphs to allow automatic generation of graded and annotated results." I think we've done an article on this before, but I don't see it in the archives...

Frog writes "The New York Times (reg. req'd) writes about a study by the Xerox PARC Internet Ecologies Area which shows that only a small percentage of Gnutella users actually share files -- the rest just take 'em. The researchers note it's 'hard to generate spontaneous cooperation in large anonymous groups.' As a consequence, the system has degraded performance, and is more vulnerable to censorship or legal action. Maybe the solution is to implement a market system for resource allocation, but how to prevent cheating?" Reminds me of the BBS days of file ratios - 'course then we'd just take an image, resize and upload it, so that idea didn't exactly work as intended.

Frog writes "The New York Times (reg. req'd) writes about a study by the Xerox PARC Internet Ecologies Area which shows that only a small percentage of Gnutella users actually share files -- the rest just take 'em. The researchers note it's 'hard to generate spontaneous cooperation in large anonymous groups.' As a consequence, the system has degraded performance, and is more vulnerable to censorship or legal action. Maybe the solution is to implement a market system for resource allocation, but how to prevent cheating?" Reminds me of the BBS days of file ratios - 'course then we'd just take an image, resize and upload it, so that idea didn't exactly work as intended.

neverever writes "I just saw a reference to a talk given today (Thursday) at MIT by Steve Potter from MIT who is doing work on growing neurons in a petri dish with electrodes so that the neural network can be hooked up to a virtual body running inside a simulation. They are also going to be using some fancy imaging techniques to watch the network in operation. Check out this for a story about it or this for their research site. "

Chris Worth has come to me (surprise!) with a review of one of the most definitive books on nanotechnology, Nanosystems. K. Eric Drexler's response to the technical issues raised by critics to nanotechnology, the book is a technical treatise Nanosystems author K Eric Drexler pages 556 publisher John Wiley & Sons rating 10/10 reviewer Chris Worth ISBN 0471575186 summary Dr Nano answers his critics with a technical treatise on nanotech.

About the reviewer

Chris Worth is a web creative director and nanotech junkie based in Paris. You'll find other ramblings on technology, literature, and red hot asian babes at chrisworth.com. He's looking for geeks to build a subversive website for fun and profit, supported by some of the world's top creatives and assorted rich bastards; email him at chris@chrisworth.com if you're interested.

The Scenario: bringing researchers together

So you think you know what nanotech is, huh? Maybe you read a book by Neal or Greg or William and dreamed of custom-built computing molecules blanketing cities a billion deep, of patterned flesh singing a song of networked biosentience, of hundred-storey polycarbon structures reaching skywards into the electric neon night. Maybe the concept seduced you into Unbounding the Future and its Lilliputian expeditions across molecular landscapes, or you notched up to Engines of Creation and its talk of assemblers and replicators in pages nude of math. I read them too. And they're good, believe me. But to really know nanotech, to bite through the soft pop-sci underbelly and champ down on its hard skeleton of applied physics, you've got to read Nanosystems .

Nanosystems: the first technical treatise on nanotechnology

Nanosystems, by K Eric Drexler, is the real deal: the first textbook on molecular nanotechnology. It's full of greek equations and exponential graphs and globular diagrams that'd scare your chemistry professor, walled in by dense paragraphs of dry prose that'll make your teeth itch. But somehow it's readable - because the book has a broader purpose that goes beyond Potential Energy Surfaces or spatial Fourier transforms or Born-Oppenheimer approximations. That purpose is to bring together researchers from different fields, to show them how their expertise fits into the broad patchwork of nanotechnology. And that means it's readable for any motivated geek, because Drexler assumes no in-depth knowledge of any one field; concepts are explained from first principles and many equations are derived step-by-step. In a nutshell: if you get C, you can get Nanosystems.

So that's the purpose of Nanosystems: to bring disparate researchers into a single conceptual framework and make nanotech a collaborative effort. But just what is nanotech? First, let's define what it isn't - because nanotech discussions often give out more heat than light. Like transgenic crops and human cloning, vast swaths of the argument would disappear if everyone understood the principles.

Nanotech: so what the hell is it?

First, it's not necessarily about small things; the nano prefix refers to precision at the molecular scale, not the size of the finished article. A rocket motor built bottom up from component atoms one by one is molecular nanotechnology; a train of tiny gears built top-down by hewing away at a silicon surface is not. Second, nanotechnology won't turn lead into gold; elements are defined by atomic nucleii, and nanotech isn't interested in the nuclear forces. Third, it isn't a cure for all the world's problems; hatred and bigotry are separate issues no technology can solve. Fourth, there won't be any day when sci.nanotech explodes with cries of "it's here!"; since it'll be the result of research across multiple disciplines, nanotech will arrive in fits and starts.

And finally, on the biggest misunderstanding of all: no, nanotech isn't impossible. The laws of physics don't prevent nanotech happening; in fact, they emphatically make it possible. (Mr Heisenberg isn't half the troublemaker you think he is.) Yes, there's a tad too much hero worship and holy rollerism surrounding the good-natured and approachable Dr Drexler. And that's given rise to some negative column inches by Scientific American's Gary Stix and Nature's David Jones (neither of whom backed up their assertions). But catcalls and hype don't change basic physical principles; nature doesn't give a damn how loud we shout. And since Nanosystems's first printing in 1992, even Drexler's most loudmouthed critics haven't found any showstopping fault with it.

But back to what matters: what is nanotech? Fundamentally, it's about that bottom-up capability: getting every atom where you want it. Once you can get every atom where you want it, you can build machine systems from the bottom up with atomic precision. Once you can build bottom up, you can build machine systems capable of making perfect copies of themselves, as ribosomes do with DNA. And once your machine's made a perfect copy of itself, you can tell those two to build another, and those four to build four more, and so on, meaning that in a day or two you've got enough to start doing serious work. That bottom up capability of "molecular manufacturing" - which Drexler defines as "the construction of objects to complex atomic specifications using sequences of chemical reactions directed by nonbiological molecular machinery" - would lead to a new world of wealth and abundance. And Nanosystems is about reaching it.

The book's structure

Inside the blue-white cover with tantalising schematics of a molecular sorting rotor, atomic-scale bearing, and a robot arm with the 50 nanometer legend, the book's 556 pages split into three parts: "Physical principles", "Components and systems", and "Implementation strategies". What it does, what to do it with, and how to get there, backed up by 450 equations. Resist the urge to skip chapters until you've skimmed the whole book once; it has a developing structure that rewards a bit of linearity. The preface - with its famous first line "Manufactured products are made from atoms, and their properties depend on how those atoms are arranged" - sets the scene, with notes on why it's reasonable to predict tomorrow's technology with today's. ("Our ability to model molecular machines has far outrun our ability to make them...") But the meat starts with the intro:

"The following devices and capabilities appear to be both physically possible and practically realizable:

Programmable positioning of reactive molecules with ~0.1nm precision
Mechanosynthesis at >10^6 operations/device.second
Mechanosynthetic assembly of 1kg objects in <10^4 s
Nanomechanical systems operating at ~10^9 Hz
Logic gates that occupy ~10^-26m (~10^8 micro^3)
Logic gates that switch in ~0.1ns and dissipate <10^-21J
Computers that perform 10^16 instructions per second per watt
Cooling of cubic-centimeter, ~10^5W systems at 300K
Compact 10^15 MIPS parallel computing systems
Mechanochemical power conversion at >10^9W/m^3
Electromechanical power conversion at >10^15W/m^3
Macroscopic components with tensile strengths >5*10^10GPa
Production systems that can double capital stocks in <10^4s"

Yeah, I was drooling too. And just a few pages further in Drexler whacks us with a nanomechanical product: a bearing with shaft and sleeve in 6- and 14-fold prime symmetry to keep it turning. It's made of carbon with the odd silicon and oxygen atom to round it out, dangling bonds capped with hydrogen, and is made of just 206 atoms. Of course it can't be built yet, but the mind boggles anyway. As it should: this diagram is a teaser for the whole book.

The rest of the intro is comparisons: how conventional solution-phase chemistry and mechanosynthetic chemistry are different, how characteristics of different approaches differ at the nanoscale, how the carbon structures described in Nanosystems are just a subset of all covalently-bonded structures, and the scope of the book. Read this: there's no sci-fi here, no what-ifs, no assuming-thats. Nanosystems is about what's possible given today's understanding of how molecules behave - as such, it's more conservative than many papers you'll see in Nature.

Chapter by chapter

Part I - Physical Principles - is the hardest, squashing a physics course into 230 pages. Ride the hump, guys; no pain, no gain. Chapter 1 takes you down into the molecular world, exploring where classical physics scales down and where it doesn't; chapters 2 and 3 get down and dirty with how molecules are shaped and how they behave when pushed. Chapter 5 is for Heisenberg fans, explaining how thermal uncertainty's a far bigger problem than quantum uncertainty at these scales, while 6 and 7 explore how nanomachine designs will be debugged, going into problems of error-checking and heat death. So far, so painful. Work with it.

It's not until chapter 8 that Drexler starts talking about "real" nanotech: mechanosynthesis. This is 1AM stuff when you know you should be putting the book down for the night but can't. You'll be reaching for the Jolt without caring about work tomorrow. There's still plenty of alkenes and alkynes and tensile bond cleavage and Pi-bond torsion talk here, but the graphs stop for a moment as Drexler deals with what later got called "fat finger" and "sticky finger" problems - how to make your reactive tool molecule slim enough to cause one reaction with a target molecule without it getting the wrong one, and how to make sure the reaction happens when you want it to. And this chapter introduces carbon, everyone's favourite element.

Carbon is one seriously cool atom. Tetrahedral covalent carbon - diamond - is a hundred or so times stronger than steel, and its components atoms are everywhere. They do have to be joined together in a precise pattern; that's why diamond is rare today, and why p.241 includes a diagram of adding two ethyne molecules to another hydrocarbon to model a step in diamondoid formation. Peppered with other common elements like oxygen, fluorine, chlorine, hydrogen, silicon, sulfur, phosphorus, and nitrogen, carbon can be assembled into tough, stiff structures with almost any mechanical or electronic property we want. And carbon molecules are surprisingly easy to model accurately on a computer. That's why Nanosystems devotes itself principally to carbon structures.

On to part II, Components and Systems. Chapter 9 kicks off with the difference between housings and moving parts, and answers one criticism levelled at Drexler: you can't extrapolate to the nanoscale from the macroscale. With a grab-bag of molecular rods and strained-shell carbon bearings, Drexler shows where we can and where we can't. Chapter 10 does the same for moving parts, salting in what happens when two structures start interacting with each other: there are some tasty diagrams of molecular gears, rollers, belts and cams here, but watch out for the graphs and equations.

By chapter 11 the components start coming together as complete systems instead of odd toys, worm gears inserted between tube sections and drive rings threaded onto toroidal housings. Some of the drawings look clunky and Victorian to our silicon-bred eyes, until you realise the transistors we know and love are huge rough-hewn logs at this scale and gravity and friction aren't problems in the same way. Nanosystems is about mechanics, not electronics, but a funky electrostatic motor on p.337 blurs the line: at these sizes both approaches are elegant.

It's at chapter 12 that Drexler gets around to computers. Shapes reminiscent of Babbage engines and Jacquard looms parade across the pages in diagrams of rod-logic gate and register apparatus. (Yes, this is the chapter that inspired a scene in The Diamond Age.) Neal Stephenson got it wrong: this is unlikely to be how we'll build tomorrow's PCs, because Nanosystems is an exploration of engineering techniques, not a recommendation to Intel. The chapter pivots on a finite-state machine built with nanomolecular AND/OR rod logic, with text stating a million-transistor CPU would fit inside a 400nm cube, run at 1GHz, and perform at 10^16 instructions per second. Nanoelectronic designs will be many orders of magnitude faster, but they're outside the scope of this book.

Chapter 13 starts the segue into part III, chunking up to how all these nanomachines can be linked into a complete machine system. A sorting rotor extracts the right molecules from a mix with precisely-shaped reactants attached to a cam; a set of them washes a mix progressively cleaner and cleaner (more feedstock for Neal Stephenson's Diamond Age.) Molecular conveyor belts grab molecules from a toothed gear and take them elsewhere. But the chapter's wow-factor (wow being a relative term in Nanosystems) is the nanomanipulator, a squat robot arm of four million atoms, over a hundred moving parts yet just a hundred nanometers tall. It can pitch, roll and yaw in all six degrees of freedom, snaking up and down and round and round with a train of drives and clutches spliced together with worm gears and intersegment bearings. Imagine this arm reaching out and bonding to a single atom with a reactive tip, rotating that atom away from its surface and depositing it elsewhere. Remember that image, because it's at the core of what nanotech is.

Building on this, chapter 14 describes an exemplar molecular manufacturing system: the holy grail. Another chunk up, it gloms together all the machines described already, into a complete factory for building nanomachines. From single atoms to different parts to convergent assembly to parallel construction, the factory masses less than a kilogram. With a few simple instructions, millions of interacting nanomachines will build products in minutes, blocks of molecular sorting rotors, conveyor belts, and assemblers individually unaware of the big picture but working in parallel like any anthill or beehive. Open another can of Jolt, because you're on the home stretch now.

Part III - on Implementation Strategies - tacks away from what we can build and talks about how to build the things that build them. It turns out there's more than one way to do it. In chapters 15 and 16 Drexler discusses a range of cool STM and AFM scopes for pushing and shoving atoms around, and suggests ways reactive tips on the scanning needle could play with them; since Nanosystem's publication this has started happening in several labs. Biomolecular selfassembly and protein folding are other possible paths to those first primitive tools that can bootstrap us up to covalent-carbon nanotech. Talk of cyclic backbones, crosslinking and rigidity will answer a lot of critics' questions, with a forward- and backward-chaining analysis (a la computer science) "indicates that feasible developmental pathways link our present technology base to the technology base described in Part II." And there, save for a couple of appendices on methodology and related research, the book ends.

So drop the Jolt and fall asleep, because then you can dream - dream of nanotech's infinity of possibilities. And then we can start talking about it. Talking about it the way we talk about Linux, informed by sound technical issues instead of hype and soundbites. Because Nanosystems is a subversive book, subversive the way strong crypto and open source are subversive: developing thanks to the hacker ethic, developing to liberate the masses instead of control them. Published anywhere else, this review'd probably scare people off. But to you, it probably sounds like a challenge. So read Nanosystems. Imagine how ten thousand hyperlinked Slashdotters with a strong understanding of nanotech could influence this technology... and have so much damn fun doing it.

So go on, geek: read Nanosystems . I dare you.

FOOTNOTE: About the Foresight Institute

After first reading Nanosystems in 1996 I became a member of the Foresight Institute, which Eric Drexler and Chris Peterson founded to spread information about nanotech. Foresight works quietly and cost-effectively to influence public policy towards safe, informed development of molecular nanotechnology. (As Gayle Pergamit, Drexler and Peterson's technical writing collaborator, says, it's amazing what two people and a letter to the right office can achieve.) At the conferences it runs for its members you can rub shoulders with writers like Greg Bear, David Brin and Gregory Benford, Valley legends like Doug Engelbart, hackers the stature of Raymond and Gilmore, Old Media types from the New York Times and San Jose Mercury, real nanotechies like Ralph Merkle of Zyvex and Josh Hall of IMM, and of course Drexler and Peterson themselves. And this would take you through one bagel at breakfast. Thanks to Foresight I've learned a lot, made some excellent contacts, and several strong friends. You can learn more at www.foresight.org.

Table of Contents

1. Introduction and Overview

• 1.1 Why molecular manufacturing?
• 1.2 What is molecular manufacturing?
• 1.3 Comparisons
• 1.4 The approach in this volume
• 1.5 Objectives of following chapters

Part I 2. Classical Magnitudes and Scaling Laws

• 2.1 Overview
• 2.2 Approximation and classical continuum models
• 2.3 Scaling of classical mechanical systems
• 2.4 Scaling of electromagnetic systems
• 2.5 Scaling of classical thermal systems
• 2.6 Beyond classical continuum models
• 2.7 Conclusions

3. Potential Energy Surfaces

• 3.1 Overview
• 3.2 Quantum theory and approximations
• 3.3 Molecular Mechanics
• 3.4 Potentials for chemical reactions
• 3.5 Continuum representations of surfaces
• 3.6 Conclusions
• 3.7 Further readings

4. Molecular Dynamics

• 4.1 Overview
• 4.2 Nonstatistical mechanics
• 4.3 Statistical mechanics
• 4.4 PES revisited: accuracy requirements
• 4.5 Conclusions
• 4.6 Further Reading

5. Positional Uncertainty

• 5.1 Overview
• 5.2 Positional uncertainty in engineering
• 5.3 Thermally excited harmonic oscillators
• 5.4 Elastic extension of thermally excited rods
• 5.5 Elastic bending of thermally excited rods
• 5.6 Piston displacement in a gas-filled cylinder
• 5.7 Longitudinal variance from transverse deformation
• 5.8 Elasticity, entropy, and vibrational modes
• 5.9 Conclusions

6. Transistions, Errors, and Damage

• 6.1 Overview
• 6.2 Transitions between potential wells
• 6.3 Placement errors
• 6.4 Thermomechanical damage
• 6.5 Photochemical damage
• 6.6 Radiation damage
• 6.7 Component and system lifetimes
• 6.8 Conclusions

7. Energy Dissipation

• 7.1 Overview
• 7.2 Radiation from forced oscillations
• 7.3 Phonons and phonon scattering
• 7.4 Thermoelastic damping and phonon viscosity
• 7.5 Compression of potential wells
• 7.6 Transitions among time-dependent wells
• 7.7 Conclusions

8. Mechanosynthesis

• 8.1 Overview
• 8.2 Perspectives on solution-phase organic synthesis
• 8.3 Solution-phase synthesis and mechanosynthesis
• 8.4 Reactive species
• 8.5 Forcible mechanochemical processes
• 8.6 Mechanosynthesis of diamondoid structures
• 8.7 Conclusions

Part II 9. Nanoscale Structural Components

• 9.1 Overview
• 9.2 Components in context
• 9.3 Materials and models for nanoscale components
• 9.4 Surface effects on component properties
• 9.5 Shape control in irregular structures
• 9.6 Components of high rotational symmetry
• 9.7 Adhesive interfaces
• 9.8 Conclusions

10. Mobile Interfaces and Moving Parts

• 10.1 Overview
• 10.2 Spatial Fourier transforms of nonbonded potentials
• 10.3 Sliding of irregular objects over regular surfaces
• 10.4 Symmetrical sleeve bearings
• 10.5 Further applications of sliding-interface bearings
• 10.6 Atomic-axle bearings
• 10.7 Gears, rollers, belts, and cams
• 10.8 Barriers in extended systems
• 10.9 Dampers, detents, clutches, and ratchets
• 10.10 Perspective: nanomachines and macromachines
• 10.11 Bounded continuum models revisited
• 10.12 Conclusions

11. Intermediate Subsystems

• 11.1 Overview
• 11.2 Mechanical measurment devices
• 11.3 Stiff, high gear-ratio mechanisms
• 11.4 Fluids, seals, and pumps
• 11.5 Convective cooling systems
• 11.6 Electromechanical devices
• 11.7 DC motors and generators
• 11.8 Conclusions

12. Nanomechanical Computational Systems

• 12.1 Overview
• 12.2 Digital signal transmission with mechanical rods
• 12.3 Gates and logic rods
• 12.4 Registers
• 12.5 Combinational logic and finite-state machines
• 12.6 Survey of other devices and subsystems
• 12.7 CPU-scale systems: clocking and power supply
• 12.8 Cooling and computational capacity
• 12.9 Conclusion

13. Molecular Sorting, Processing, and Assembly

• 13.1 Overview
• 13.2 Sorting and ordering molecules
• 13.3 Transformation and assembly with molecular mills
• 13.4 Assembly operations using molecular manipulators
• 13.5 Conclusions

14. Molecular Manufacturing Systems

• 14.1 Overview
• 14.2 Assembly operations at intermediate scales
• 14.3 Architectural issues
• 14.4 An examplar manufacturing-system architecture
• 14.5 Comparisons to conventional manufacturing
• 14.6 Design and complexity
• 14.7 Conclusions

Part III 15. Macromolecular Engineering

• 15.1 Overview
• 15.2 Macromolecular objects via biotechnology
• 15.3 Macromolecular objects via solution synthesis
• 15.4 Macromolecular objects via mechanosynthesis
• 15.5 Conclusions

16. Paths to Molecular Manufacturing

• 16.1 Overview
• 16.2 Backward chaining to identify strategies
• 16.3 Smaller, simpler systems (stages 3-4)
• 16.4 Softer, smaller, solution-phase systems (stages 2-3)
• 16.5 Development time: some considerations
• 16.6 Conclusions

Appendix A. Methodological Issues in Theoretical and Applied Science

• A.1 The role of theoretical applied science
• A.2 Basic issues
• A.3 Science, engineering, and theoretical applied science
• A.4 Issues in theoretical applied science
• A.5 A sketch of some epistemological issues
• A.6 Theoretical applied science as intellectual scaffolding
• A.7 Conclusions

Appendix B. Related Research

• B.1 Overview
• B.2 How related fields have been divided
• B.3 Mechanical engineering and microtechnology
• B.4 Chemistry
• B.5 Molecular biology
• B.6 Protein engineering
• B.7 Proximal probe technologies
• B.8 Feynman's 1959 talk
• B.9 Conclusions

Afterword Symbols, Units, and Constants Glossary References Index

Wiggly asks: "I would like to program distributed systems using the same code base on multiple platforms and multiple languages therefore I am asking around..." And he's asking Slashdot. You've only read the tip of the iceberg, however. There's much more to digest if you decide to click on thru.

"I will firstly say though that none of this is meant as flamebait, or to detract from what any of the projects/products mentioned here have achieved. I just have a wishlist and I am looking for answers and opinions, not a holy war. I am sure that people use many of the things mentioned here on a regular basis for heavy duty apps quite happily and with great results.

There are a whole bunch of distributed programming frameworks around. RPC, ILU, CORBA, DCE, Java RMI and DCOM to name but the most common. Many of these are available on multiple platforms and there are a whole slew of interoperability tools to get them to talk to each other with varying degrees of success. Right now I will focus on CORBA as it is getting much more press than any other recently, and because it is the system that I personally know more about than the others..

Commercially there are a few good ORBs but they are terribly expensive. Developer kits for 'a well known brand' with good CORBA compliance start around 1500 - 1900 UK Pounds, for developer kits. Redistribution costs are around 1700 UK Pounds per processor. These kinds of costs don't really let people play with systems before buying although I know that most comercial ORB vendors will give you trials if they think you are a good bet to buy. Additionally most of the commercial ORBS support as few platforms as they possibly can.

On the Open Source side of things there are many, many implementations of CORBA to choose from, with their own special focus. CORBA compliance, speed, interoperability or whatever else that project's maintainers view as the most important goal(s). There is some great code out there, and a load of people spending every waking hour making it better.

What I cannot find at the moment is a system that targets multiple platforms and multiple languages. Want to use Perl to talk to C++ back ends? Well MICO/COPE is coming along. Want to use the same code on Windows NT as well? Too bad, NT support is very flaky (I have spent too many hours trying to get it working). Want to use Java Applets to talk to C? You have problems. Pick your favourite front/back end language combination and platform then try to find a solution. Problematic at best, and probably not possible at the moment.

Are these very strange requirements/wishes or would other people be willing to sacrifice ratified standards compliance and possibly performance for orthogonality of language/platform availability? I would like to be able to write code for Linux/Unices/Windows in my languages of choice (for me this would be Perl, Java and C++) without having to use multiple implementations on the different platforms.

The way things are shaping up I am thinking hard about rolling my own, because right now I have a need that I cannot fulfill from outside sources. Yes, not Invented Here strikes again, but I can't find a solution. Am I alone in this? What do you think? Do you have any solutions?"

tomas writes "This is a very detailed/scientific article describing nanotechnology and the assemblers to build nanomachines. One use for said nanomachines would to replace the current lithography techniques used to make compter chips. This guy professes that nanotechnology will allow us to store a hundred billion billion bytes in the volume of a sugar cube. Else read an overview of how xerox is involved with nanotechnology "

tomas writes "This is a very detailed/scientific article describing nanotechnology and the assemblers to build nanomachines. One use for said nanomachines would to replace the current lithography techniques used to make compter chips. This guy professes that nanotechnology will allow us to store a hundred billion billion bytes in the volume of a sugar cube. Else read an overview of how xerox is involved with nanotechnology "

signal7 writes "Just saw press release over at Xerox's site for a 19" flat panel display. It's meant for medical applications and it's greyscale, but over 5 million pixels is a leap for flat panel technology. "

Joachim Achtzehnter writes "The next release of Xerox PARC's ILU system will have a modified license which clarifies that ILU is free software. Last year the GNOME project decided not to use ILU because of its ambiguous license. The old license already allowed unlimited use, the new license is more explicit by stating that derivative works are permitted as well. ILU is a CORBA compatible distributed object system supporting many programming languages and platforms. "