When GreenHills launched their anti-Linux offensive, they crossed a line – and I doubt they even knew it. To cast doubt on the value of Linux in critical applications, GreenHills tried to create a scare about the nationality and “loyalty” of engineers working on Linux. This is stupid on three levels. First, software security is an engineering property, not something passed on like a, a, well, a virus. There are established methods for vetting security, by test, by inspection of the design, and by inspection of the design process – none of these involves the visa status of the developers. Second, software is the flagship international product and has been since that Hungarian fellow von Neumann was working in Princeton. Maybe things look different in Santa Barbara, but in the rest of the world, software development is something that discriminates on the basis of talent and work and not anything else. 
Finally, it’s absurd to think that software companies can vett their employees better than government security agencies and we know that those agencies can employ people who work for the other side for years. Does Dan O’Dowd stalk around the GreenHills office looking for subtle signs of disloyalty and contraband? I tried to do that here, but other than Matt’s bag of gummi-bears, I saw nothing life threatening. Xenophobia is a poor substitute for solid engineering and it is a more real danger than hypothetical undercover programmers putting trojan horses into unsuspecting software.
Category: operating systems
FSMLabs is making its way through the DO178 requirements and we’ve given a lot of thought to Common Criteria over the last couple years. One of the advantages of DO178 is that it does not accept the totally untested and frankly unlikely premises of “formal methods”.
The reason mathematics has advanced so much was not because of the Euclidean axioms-lemma-theorem straitjacket, but in spite of it. Luckily, when we actually discover mathematics, we do it the Babylonian way, empirically and algorithmically. It is only when it is time to present it, that we put on the stifling Greek formal attire.
so says Doron Zeilberger
And the mystery quote. Who said this?
“That mathematics reduces in principle to formal proofs is a shaky idea” peculiar to this [20th] century. In practice, mathematicians prove theorems in a social context. […] It is a socially conditioned body of knowledge and techniques.”
In the early 1980s, I worked for a start-up called Auragen Computers based in Fort Lee, New Jersey. We were making a 68K based fault tolerant UNIX based on a smart idea by Sam Glazer. Most of the software engineers lived in New York City and commuted out. Start-ups with New Yorkers have a different “culture” than start-ups with Californians. One of the senior technical staff was once asked to meet with investors to talk about why development was taking so long. After some fruitless attempts at discussion he explained, kindly, “I don’t think I can make this clear in 5 minutes. It took me 10 years to understand this stuff and I’m a lot smarter than you.” Auragen did some good work, but failed to get the product out to market in time. A good lesson to learn.
Auragen gave me my first job in the computer industry and a great education in operating systems. I still remember sitting in a room with Jim Baumbach, Anita Borg, David Arnow, and Sam Glazer soon after I started there, and confronting the reality that everyone in the room was a lot smarter, better educated, and more witty than me (my only consolation was that, in their early 30s, they seemed pretty damn old).
See this paper: A message system supporting fault tolerance
and this post: The replicated state machine model of fault tolerance from the 1980s
The subject of priority inheritance has come up again on the Linux kernel mailing list and Torvalds correctly notes
“Friends don’t let friends use priority inheritance”. Just don’t do it. If you really need it, your system is broken anyway.
“Priority inheritance” is similar to “soft real-time” in that both are efforts to avoid building software to specification. I put together a detailed critique in “Against Priority Inheritance”. There are two basic problems with priority inheritance (1) the algorithms are inefficient, complex, and inherently buggy and (2) any claimed benefits can be obtained in a more durable and efficient manner via good design.
The RTLinux core does not support priority inheritance for a simple reason: priority inheritance is incompatible with reliable real-time system design. Priority inheritance is neither efficient nor reliable. Implementations are either incomplete (and unreliable) or surprisingly complex and intrusive.
Doug Locke’s response to “Against Priority Inheritance” seems to me to have to evade the issue in the standard way: read his response and see for yourself. It’s not enough to say “yes, of course you need a proper implementation” since one of the points of the paper is that proper implementations are fragile, expensive, and unreliable.
Update: If you want technical details on the can-o-worms PI opens – read the great description by Bryan Crantril at Sun.
Categories
Synchronization blues
Synchronization is hard in real-time applications, but not as hard as people imagine. If you follow a few simple rules you can make it manageable.
- Never force priority and mutual exclusion to fight each other. You can’t mean “Task A is more important than TaskB” and “TaskB should be able to lock TaskA out of some data structure as long as it want” at the same time.
- Long critical sections are sure signals of bad design. Use a simpler data structure or a client/server architecture or something.
- Stick to two or three mechanisms. If semaphores and RT-Fifos don’t do the trick, then maybe you should simplify your design.
See my paper for more details.