I'm not sure how they could even measure the goal here. The synopsis from FBO implies this is a broad program:<p>----
<i>DARPA is soliciting innovative research proposals in the areas of formal methods, program analysis, compiler design, and runtime and virtual machine implementation to realize tools for the construction of long-lived, survivable, and scalable adaptive software systems.</i>
----<p>Skimming over the PDF, they seem to be brainstorming all over the place without much of a clear direction.<p>There's nothing I can gauge that is theoretically stopping us from having century-long running software systems. It's already fully possible. All this talk about formal verification, replacing protocols, defining API/ABI subsets sounds over the top, when more fundamental issues are providing language runtimes that allow for high concurrent units of execution with resource and failure isolation, restart strategies, preemptive scheduling, live upgrade mechanisms and so forth. The VM is your platform.<p>And it's not like even that is strictly necessary. COBOL systems running on old iron chugs along merrily, though then again I've heard that mainframes have some rather elaborate fault tolerance mechanisms that haven't really leaked much into the rest of the mainstream.
You could compare this to a 100 year old car. But that's not accurate. There are 100 year old automobiles in use, and likewise I expect some 40 year old software to still be in use in 60 years. Launch a space probe and its software will run as long as there is power.<p>But that's not interesting.<p>Here we are taking not about software not as an instance, a physical entity of computation. We are taking about software is an idea, a <i>design</i> for computation.<p>What DARPA is looking for is the equivalent of a car <i>design</i> that is still in use after 100 years. One that can be maintained and occasionally modified in backwards compatible ways.<p>But that's a little stupid, both for automotive designs and for software (computational designs). Creating a 100 year car design is probably at best fruitless and at worst counterproductive. Trying to create a 100 year software project shares the same pitfalls.
I thought all large software products effectively last forever. Isn't this why COBOL programmers still have jobs for life? I would have thought the challenge is to create systems that will die.
If DARPA succeeds in this, it will be a HUGE advantage for everyone.<p>The way I personally see this happening is everything has to be formally verified. This will guarantee that the file written tomorrow will be successfully read by yesterday's programs, and that contemporary software is compatible with future OSes. (Does this mean that we freeze libc?)
But there is a problem: there are a lot of quirks for hardware in modern OS/drivers, which add weird and possibly unreliable code. Does the hardware+firmware has to be formally verified too?<p>Do we have to run our software on all hardware that exists, e.g. starting from 6502 and until some future CPU?<p>Do we want to use POSIX? Subset of POSIX? <i>cough</i> Plan9? <i>cough</i><p>Another problem I see is seemingly inevitable software bloating over time.<p>- What features do we have to include in our OS, our kernel?<p>- Does this list of features only grows over time?<p>- Do we want to have GUI as a requirement? What if UI paradigm changes?<p>There is also a bloating of protocols, e.g. TLS. Maybe replace TLS with CurveCP?<p>Related reading:<p>DOD Trusted Computer System Evaluation Criteria <a href="http://csrc.nist.gov/publications/history/dod85.pdf" rel="nofollow">http://csrc.nist.gov/publications/history/dod85.pdf</a><p>Formally proven OS kernel: <a href="http://sel4.systems/" rel="nofollow">http://sel4.systems/</a><p>List of theorem proving systems on wikipedia: <a href="http://en.wikipedia.org/wiki/Category:Theorem_proving_software_systems" rel="nofollow">http://en.wikipedia.org/wiki/Category:Theorem_proving_softwa...</a><p>Note that Nqthm prover started in 1970. ACL2 has a HUGE collection of proofs for code <a href="https://github.com/acl2/acl2" rel="nofollow">https://github.com/acl2/acl2</a><p>Jonathan K. Millen, Security Kernel validation in practice (1976), "The correctness of a security kernel on a PDP-11/45 is being proved" DOI:10.1145/360051.360059 <a href="https://mega.co.nz/#!U8UAWLQY!YJ1YsOqe6E0jge5lGktBZiJUar1lu2L74JguUoGjP30" rel="nofollow">https://mega.co.nz/#!U8UAWLQY!YJ1YsOqe6E0jge5lGktBZiJUar1lu2...</a>
Some of the comments here claim that we already have pretty long lived and robust software. While this may be true, I don't think that's what DARPA is looking for. I believe that they are looking something that could keep an interstellar probe running for few hundred years, or something like a remote base somewhere in space. Something that could detect and fix any issues with the software and hardware. But it's not only about reliability. Think about a Moon base, where the software keeps running for decades, and once in a while new module/hardware is added to it. MoonOS would have to detect new addition and reconfigure itself to work with it. Maybe it could even decide to move some critical parts of itself to the new hardware. It would do it without any input from humans.
>users have become accustomed to periodic cycles of updating and upgrading to avoid obsolescence—if at some cost in terms of frustration.<p>That fear of obsolescence is what drives those upgrade/subscription revenues. Finding replacement revenues thus is the real task here.<p>Anyway, TCP is 40 years old and will be with us for the other 60 years (with some fine-tuning for the big latency roundtrips to Mars) - so this is your 100 year system for example. Others mentioned COBOL already and one can also look at Fortran libraries like in astronomy, etc...
The only reliable approach to this I can think of is to 'write' the program purely as a declarative specification mapping every supported input pattern into a corresponding expected output pattern (for a familiar example, spec driven unit testing: <a href="http://jasmine.github.io/edge/introduction.html" rel="nofollow">http://jasmine.github.io/edge/introduction.html</a>).<p>Then one needs to write whatever's going to generate the implementation (currently that 'whatever' is a human programmer). If done right, it doesn't matter what the underlying platform is (theoretically, this could even be used to train a neural network).
I would say that they should build it as modular and clean as possible. With modular i mean possibility to rewrite parts of the system in different languages etc. A distributed system with multiple copies of each module running on different machines in different locations. Build it around a "live" monitoring and control system.<p>Use the base from the last 50 years, and add tested modern practices. This would include the possibility to upgrade any part of the system without taking it offline.<p>From there, the sky is the limit.
I don't quite get what the article is talking about. It starts with saying that updates are a problem. Then it talks about things I can't really distinguish from 'quality issues, reliability, complexity issues.."<p>What does this "BRASS: even mean, anyone got a clue? "Resource Adaptive" seems to be the important part. What are they talking about?
Sometimes when I read DARPA headlines I imagine someone like the Dude stroking his beard and going "yeaaaaah, let's do THAT man! Wouldn't that be wild?"
It's weird. Godel's incompleteness theorem is basic CS knowledge, but then we pretend it doesn't exist because it's too inconvenient.