My clients and I frequently work with confidential information of various sensitivities (e.g., research, legal, financial, government). Storing that information, in toto, abstract, or summary on a non-private facility is simply unacceptable. We would simply have to forgo use of these software products. Mandatory data storage would also seem to expose the companies to liability if there is a problem with data loss, miss-appropriation, or other damage. I am deeply surprised that this issue has not had a higher profile, it seems to be a significant financial exposure.

It is indeed simplistic and one-sided to assert that "using libraries exposes systems to bugs". The problem is far deeper, and affects both library and bespoke code bases. First, consider the somewhat psychological problem that often happens when using libraries. The various flavors of public code (e.g., Open, Free, etc.) have as an implicit or explicit basis the presumption that since the source is freely available, those using the libraries will peruse the source, either to fix shortcomings or to correct bugs. In effect, it is distributed vetting. Unfortunately, as the Heartbleed vulnerability with OpenSSL demonstrated, there are many who slipstream when using such packages. When the incident occurred, the list of major computer software enterprises using OpenSSL without internal vetting (or for that matter, externally funding the OpenSSL committee's audit functions) was long and distinguished. In essence, each responsible management said to itself "Everyone else is vetting, why should I?". Those who attended a basic Economics course should recognize this as a version of the "Commons" problem (although the examples invariably discuss the origin of the problem, English common sheep grazing pastures). There is a significant (> US$ 100,000/project) benefit to NOT vetting and relying on "someone else in the community". At least until it becomes obvious that almost everyone has been assuming that someone else was vetting the code. Internally-developed code is often limited in its specification, development, and testing. Since it is developed for a specific project, the effort to make it widely applicable is often lacking. Often, bespoke code developed for one project is appropriated, officially or unofficially, for other projects. Unofficially appropriated code is particularly problematic, as the connection between the original copy and the new copy is often the developer's recollection. When corrections are made, they do not propagate to all of the copies. In summary, the problem is less code-based than human-based. Shortcuts save money and time in the short run, but cutting corners leads to quality issues.

There are admittedly many technical problems with a robotic patient evacuation device. Some comments mentioned the importance of patient monitoring, and indeed that is a problem. However, being evacuated as a patient on a gurney is a far different experience than riding in a car or helicopter. Illness or injury provokes profound anxiety in many people. This is not merely emotional. It has physical effects. People can faint, have asthma attacks, develop heart rhythm abnormalities. Transporting even a simple injury (e.g., simple fracture) on an otherwise stable patient in such a way can trigger any of these. Airborne without a supporting attendant is likely far more complex. Admittedly, in a combat situation, it may be safer than a crewed vehicle, and combatant personnel are not average civilians. A complex problem that requires very serious examination in all aspects.

Actually, as I noted in the "EMail Architecture" chapter of the "Handbook of Information Security", to To/From/Subject(Re) structured headers are far older than Internet email, or for that matter, computer-based electronic messaging. The structure of these headers can be found at least as far back as the inter-war period in military telegraphy and so-called tear-tape messaging. Those familiar with telegraphy-based messaging, civilian, military, or HAM-radio would recognize the elements of the messaging formats and protocol issues in the original RFCs.

There are a few mis-understandings floating through this thread. They center around:

• Is OpenVMS running native on IA-64
• Is it translated or compiled
• What is performance on IA-64
• Is OpenVMS Alive and Well.

First, OpenVMS indeed runs native on IA-64, and reasonably well. It is compiled to native IA-64 code from sources in a variety of languages, including the MACRO-32.

MACRO-32 is the macro assembler language originally used on the VAX. When ALPHA was the new processor, a MACRO-32 compiler was written to translate MACRO-32 code directly to ALPHA. As everybody can plainly see, this approach was quite succcessful. A similar approach has been taken with IA-64, with a MACRO-32 compiler generating native IA-64 code.

Similarly, image translation was used ALPHA to allow VAX applications to run efficiently without the need to recompile the sources. This approach has been used successfully since ALPHA (indeed, the MONITOR utility was translated from a VAX-compiled set of sources until recently, some other programs are still binary translated). The same approach is being made available with IA-64, and it works.

Performance is a complex issue, no single number adequately expresses the complexities of the situation, and certainly your mileage will vary. I do not have the time to write a treatise on the subject, but will say that it dramatically depends on which compilers you use, which optimizations are enabled, and what your application does. Some applications will benefit immediately, and some may not.

I recently attended the OpenVMS track of the HP - Intel Developer forum, and OpenVMS 8.2 is very much ready for real use on both ALPHA and IA-64 (see my account at http://www.openvms.org/)

- Bob Gezelter (http://www.rlgsc.com/)