The moment tech people accept that taking risk of system failure to save cost is an acceptable business decision sometimes. I agree that this story proves that you need reasonable risk assessment to do that.

Yes we do. Too.

Wow, this is really bad: Most comments completely ignore the possibility (fact that is) that there actually is a need for such a software.
A simple software for inventory (including location), simple order gathering (multi-account so group orders are possible), order processing, tracking and delivery checking with superb usability (we actually want to build something - not massage data into a half-assed DB frontend) is really missing from the landscape! At least in the open source area where I looked.

So please, think twice before you turn down the question!

Ah you are right, thanks for looking that up. I just saw AVR and jumped to an incorrect conclusion.

Or try PyMite a.k.a. Python-on-a-chip or p14p if you really must... Also features threads and is a little more mainstream than Occam. And people do actually care about the amount of mental capacity goes to their tools while making the cat door open and close.

That's what I thought too but I am still not sure. What got me thinking was the "Excalibur" machine mentioned in a story about a tour through WD's premises and the comment in the text:

They (the bits you write to your typical /dev/sd* device) would still be wrapped up in sectors, the sectors be enhanced with error correction, then encoded (NRZ, Manchester or whatever is appropriate to the magnetic storage) and then written out. What OP wanted is to manipulate the bit that comes out of encoding. Given the usual stack of SCSI-like commands (and not direct access to the write head signal as early HDD controllers had) this does not seem feasible.

You would need to replace the firmware inside the drive or use an undocumented manufacturer mode. Whatever they use to write the servo tracks would be interesting to you. You will be in the situation of the firmware writer: There will be problems all the way. Be prepared to find a way to position the heads (ever tried to find a servo track?). Most likely you also need to at least parametrize the amplifiers in the DSP part of the firmware that does the analog-to-something-to-digital so you can have direct influence on the "bits". Good luck

That is exactly what I am talking about: Iff(!) they are actually and usably making it free and open, it will be a success almost immediately. If not, it will be another Google App. Though a great one. Hold your thumbs and pray for less email attachments with exponential distribution numbers.

Wave will be the killer app by itself if (and only if) there will be free and open source versions of the Wave frontend and server they use to present you their own Wave system. In that case you and your company can each have their own server, data silo and therefore enforcable data security without the *need* to be a silo - just drag in an external user to share and the federation magic will open up the silo for just this wave or wavelet (that is, a sub-wave).

Not being able to decide what data stays with me and what may be seen by public (=Google) servers is the one key reason that "cloud advocates" have no chance in any data-conscious company. Wave (the protocol) makes it possible to have your own data silo that is optionally able to exchange the data with any(!) other Wave server and their users. Add a policy to that decision and there you go with an email-killer in corporations.

Writing your own POP3-client is reasonably possible - replicating the Wave software as is in beta now requires a complete Google-team to do. Read as: It's not easy at all. And anything less usable than the Google Wave frontend will be ditched by all people but techies.