Singularity: Dependability Really Does MatterSingularity: Dependability Really Does Matter
In a recent (well, today's in fact) <a href="http://www.ddj.com/newsletters/">Dr. Dobb's Report</a> I took a quick look at <a href="href=">Singularity</a>, an interesting project coming out of <a href="http://research.microsoft.com">Microsoft Research</a>. I heard back from readers Ray Rathburn, Donald Bertke, and Brian Gladish, whose follow-ups where, to my mind, more interesting than my original overview. So what follows is my original note, followed by their response.
March 22, 2008
In a recent (well, today's in fact) Dr. Dobb's Report I took a quick look at Singularity, an interesting project coming out of Microsoft Research. I heard back from readers Ray Rathburn, Donald Bertke, and Brian Gladish, whose follow-ups where, to my mind, more interesting than my original overview. So what follows is my original note, followed by their response.
If you had to guess (and you do), who would you credit the following rhetorical question to?
What would software look like if it were designed from scratch with dependability and trustworthiness as the primary goal?
Give up? Well, would you believe "Microsoft"? Of course, asking the question is one thing, answering it is quite another. Yet answering it was the goal of a Microsoft Research team led by Galen Hunt and Jim Larus. And the recently released results of their research is Singularity, a system-architecture and operating system built on advances in programming languages and tools.
In what seems a very non-Microsoft way, Singularity was intended from the outset to be a minimalist system. It differs fundamentally from other operating systems in that it is written almost entirely in an extension of C# and leverages built-in C# security features, thereby avoiding things like buffer overruns.
Key to Singularity is the concept of software-isolated processes (SIPs), which provide the strong isolation guarantees of OS processes without the overhead of hardware-enforced protection domains. Because SIPs are cheap to create, Singularity runs each program, device driver, or system extension in its own SIP. SIPs can't share memory or modify their own code, leading to strong reliability guarantees about the code running in a SIP.
The Singularity Research Development Kit (RDK) 1.1 is freely available for academic noncommercial use.
Here's what Ray Rathburn had to say:
Several years ago, probably 10-15, there was an article about how NASA developed software for various spacecraft-related projects. It was very interesting in that they used peer code reviews and a very involved process of testing and reviews at multiple stages of development. The end result was extremely reliable software with zero errors, but the article also pointed out that the cost per line of code, even then was 6+ figures. Zero error code is possible if you have enough money. To determine what to spend on testing and development, you have to ask the question "what is the cost if the software fails in use". There was a satellite launch (by a European consortium, I believe) that aborted. The rocket and satellite was destroyed costing 100's of millions. It aborted because two navigation software modules weren't tested together. Several seconds after launch when one module sent the other a position as long integer and the other expected a short integer, it didn't compute and so since it didn't know where it was at the safety fail safe set off the self destruct. Skimping on testing is not the best place to save money. The real question when determining how much to spend in development and testing is "what is the cost of failure?". (How much testing does the FDA require of medical devices?)
Donald Bertke added:
I just looked over you synopsis of the Singularity Research at Microsoft. I am glad that someone is finally looking at software as a dependable process. In my younger days, I was programming embedded systems as a contractor for the USAF and we had to make the software work first time, everytime, before they would let us even test the software in a real system. The current generation of programmers have no conception of how well and tight we wrote software in those days. It sounds like the Singularity research has hit upon what we considered the golden rule of embedded software:
Keep the software simple and focussed.
Don't let other software mess with your data or program space.
Don't let your program mess with its own program space.
Verify that all data coming into the data space is within specified limits.
Don't let your software mess with anyone elses data of program space.
If you follow these simple rules, your software will run quickly, reliably, and be easy to maintain. I hope the Singularity project takes off and gets people to write better software.
And then Brian Gladish said:
In the 1960s a company named Burroughs (now Unisys after the purchase of Sperry) built systems (the B5000/B5500) that, through hardware, precluded modification of code (this feature was called "re-entrancy") and ran user programs that were guaranteed not to touch memory outside their domains. In the 1970s the B1700 implemented interpretively in small systems what large systems had implemented in hardware, effectively creating what MS calls a "managed" environment through software (vertical microprogramming in this case). Burroughs large systems' operating system was written in extended ALGOL, while the small systems' O/S was written in SDL (Software Development Language), an internal, proprietary language. It is unfortunate that these advances seem to have been lost and must be rediscovered after so many years of coding in unprotected, C-based environments.
Thanks Ray, Donald, and Brian. Anyone have anything to add?
About the Author(s)
You May Also Like
Ultimate Guide to Building a Data Governance Program
Implementing Privacy by Design into Information Systems
7 Steps to Build Quantum Resilience
Checklist: Top 6 Considerations to Optimize Your Digital Acceleration Security Spend
Top Six Recommendations to Improve User Productivity with a Hybrid Architecture