They still apply based on similar stuff published since then. Several are best practices for robust systems even today. The HR question should've been addressed by fact that medium assurance techniques take either little or no training: mostly just effort and accountability.
"This amounts to automated application-level middleware, for SOA-type systems, direct from protocol spec."
Great work. An example of the higher end of what I'm talking about. I did something similar and kept checks on in production. This lets me laugh about these obvious vulnerabilities like protocol downgrades while others scurry around trying to patch them. Common problem that tools can help us do better so we use tools to do it better. I'd like to see more think that way.
I cleared history and tried Altran link again. It works on my end. Try this one again:
https://www.commoncriteriaportal.org/iccc/7iccc/t1/t1201100....
Note: I'd really rather give you one that shows the use of the method like on the CA they built. Yet, the Altran transistion and effect of time means links are disappearing off the net slowly. Happened to old language studies, too, that weren't put into IEEE or ACM.
"The internet's basis in decentralization roughly equates to FOSS clustering "
Not quite. When a site goes down, it goes down. I have to manually look for mirrors, archive.org, etc. One can use load balancers, CDN's, etc to cluster such things. That's not default, though.
" equates to torrents"
The default at the time was FTP or HTTP. This led to problems. Following my recommend, a person sat down to think of how they'd meet their goals differently. A combo of good architecture and coding led to BitTorrent.
"I do not think you can claim in good faith that embracing failure has "rarely proven to work"."
My overall claim is that you benefit by taking extra time to apply lessons learned to architecture, design, and coding to increase effectiveness (esp quality). The two cases you cited support my point that this creates benefits rather than your original case of cheap labor throwing together whatever they can download. Most people who are stitching together components with good long-term results are using components or cookbooks made with my approach. So one may even precede the other.
Far as embracing failure, high assurance has been on that for a while. Hell, the concept even presupposes failures across the lifecycle. Most such systems are designed as interacting FSM's that incorporate failure states with a fail fast and fail safe approach. Later on, it was taken further with "recovery-oriented computing" funded by DARPA, etc. Google that phrase with words "survey" and/or "security" for some interesting architectures.
"I'd like to know the source of your "old rule" that you can't make high robustness systems by composing low-robustness component"
It came Bell of Bell-Lapadula model. Probably another person, too, though can't recall name. The DOD funded high assurance safety & security research leading up to Orange Book A1 systems over a period of three decades. Some systems were built to right principles from the start. Some tried to retrofit things like UNIX for both availability and security. All the security plus some availability retrofits failed with pentesters finding more and more obscure failures or vulnerabilities. These often resulted from interactions of overly complex, stitched-together components. That's because combining two complex programs essentially makes a third, complex program. Being unable to prove reliability or security of input components makes it difficult to say anything about output.
Note that this is true for security more than availability. HA solutions show that, depending on failure type, one can get at least three 9's out of crap systems. The HA had to be well-designed and coded. Fault-tolerance took solutions like NonStop or Stratus straight designed for them. So, both took my model to varying degrees either at middleware or whole-system level for availability. Many of these still failed at upper layers of stack, occasionally lower ones, due to Byzantine failures due to how data moves throughout the cluster & corrupts stuff. Led to Byzantine-tolerant schemes, recovery-oriented architectures, and MILS architecture for secure composition of stuff like Linux. These efforts had mixed success with the problem hard enough that DARPA & NSF are still funding smart people trying to find & prove anything about a solution up-front.
So, I think my claim is well-grounded in evidence. Availability often applies on common cases that really smart people... carefully designing and coding as I advocate... optimized the hell out of. Same at various layers of the stack. These things work well enough that average users will get results unless they stress them unexpectedly. Others are solving root problems where they can with better systems and software. Think RDBMS clusters vs Hadoop stuff vs Google's F1 RDMBS. The best method is composing a combo of what exists... in common, battle-hardened configuration/usage... with higher-quality stuff while incrementally replacing what you can as better stuff appears. This was high-assurance strategy called "incremental MLS" designed to address high costs and slow time-to-market of full, custom MLS. Worked wonders applied to web servers, databases, etc.
" You do recognize however that many standard load Linux systems have run for 5+ or 10+ years with no problem, as I too know well as I've had some. "
Most I've seen didn't. Yours did. Just collecting data to support or refute their claim. It's certainly possible. The question is how probable. It's close to 100% for some solutions in real-world loads. Those are pricey for sure but they work by design that can be emulated. I'd like to know where Linux's design & code puts it.
"comparing apples and oranges, bygone eras to the present, monolithic transaction-oriented mainframes to general purpose complex COTS disposables"
The 2016 mainframes, NonStop clusters, IBM i's, etc run similar workloads with high availability and throughput on mainframes due to Channel I/O. The modern COTS "disposables" in cloud sector are even setup to emulate mainframes with many CPU's, virtualization, metered CPU/memory use, some I/O offloading, management software, etc. It's getting more apples to apples all the time. Their reliability just still isn't there with whole datacenters going offline here and there. The management tech, on other hand, has caught up in the lights out datacenters maybe even exceeded prior work.
You want to talk disposables, though. So, let's compare good architecture on a budget vs common architecture. In embedded sector, there's uptake of Java subsets to run safety-critical applications. Common deployments are microcontrollers or PowerPC boards with weak CPU's running a watered down JVM. The JOP people and Sandia's SSP team each just built a JVM on silicon w/out any abstraction issues that would hurt them. Everything down to OS code is Java bytecode. Results were low cost, low watts, acceptable performance, and high safety. The Azul Systems Vega processors did something similar for premium, enterprise market with hardware-assisted pauseless GC and tons of cores doing native Java. A fraction of that could be implemented inexpensively with standard cell model and sold as plug-in cards to disposable market.
https://www.azul.com/products/vega/
There's doing what's typical but keeps causing problems vs doing something different that addresses needs & root problems from ground up. Not always an option but is more than people would admit.
"I expect that net COTS system longevity is increasing rather than decreasing"
That's debatable. You cited good evidence to back it up. The counter evidence is that the ridiculous levels of complexity in modern hardware and problems on deep-submicron nodes mean things fail in little ways more often. Overall, your claim holds as hardware is very reliable given complexity level and they've forced the failures into a few, predictable spots. We occasionally get surprises like RAM fault paper. Yet, clustering covers basic stuff pretty well.
"My quote about sqlite and Linux running in harsh environments with limited resources in hundreds of millions - nay - billions of instances, extremely reliably, was primarily referring to mobile devices."
You should've said that. Yes, embedded stuff is easier to do that with. Lots of embedded devices run for years. Especially with clock gating etc where most of the chip stays off most of the time only coming online to do its work. Quite effective in mitigating transient errors. Let's see. My Galaxy freezes up on cameria here and there. Just failed to recognize SIM card yesterday requiring battery reset. Otherwise, very reliable as you say given complexity of stack.
Yet again, as it's almost a trend in this discussion, were SQlite and Linux done in the cheap/free people stich together whatever exists method you espoused or clean-slate solution that carefully designed or reviewed changes as I push? I'm cheating as I know Linux kernel process is pickier & lower defect than average. I also know SQLite has a strong review process designed to keep complexity to a minimum and quality up. Two more examples leveraging my recommendations. :P
I will take a look at http://infohost.nmt.edu/~shipman/soft/clean/ tomorrow (evening here).
I agree with your assertions around reasonable use of prior work. I personally came to similar methods designing security-oriented systems (eg. at Kraken), eg. by strictly defining a protocol in a formalistic manner with a language suited for that purpose, then generating interfaces for client systems ... and even application-level enforcement proxies that can be inserted either during testing or (preferably) even automatically during live deployment. This amounts to automated application-level middleware, for SOA-type systems, direct from protocol spec.
Enforcement proxies ensure that broken implementation A and broken implementation B may only talk correct subset C of any given protocol, block and alarm on noncompliant communications, make otherwise restricted communication between nodes extremely difficult for attackers to use to horizontally expand any foothold established through security breaches. Assertions may be enforced in real time. Logging may occur there also. Very useful stuff. Not actually that hard to do, in practice. By contrast, the current norm of arbitrary HTTP POST with barely enforced JSON is a leaky bucket of slop.
Altran link 404s for me.
The internet's basis in decentralization roughly equates to FOSS clustering equates to torrents equates to the wisdom and utility of failable components, I do not think you can claim in good faith that embracing failure has "rarely proven to work".
Therefore, I'd like to know the source of your "old rule" that you can't make high robustness systems by composing low-robustness components, because in the face of just the above evidence it looks like bullshit. Get enough redundancy in a system and it will operate with high resilience, as long as the orchestration algorithms are well tested. Redundancy is virtually free today in hardware, software, network connectivity, legal jurisdiction and a host of other ways. Not to take advantage of this reality is to have one's head firmly in the sand. To take advantage brings benefits beyond merely security and availability, such as system mobility, peer service provider independence, legal jurisdiction independence, cheaper sourcing, easier scaling, etc.
Some of the rest of your post seems to me to be comparing apples and oranges, bygone eras to the present, monolithic transaction-oriented mainframes to general purpose complex COTS disposables, so I don't feel it warranted to discuss further.
With regards to Linux uptimes, you never specified workload, and that's hard to assure in hindsight, so you've created an impossible requirement to disprove your assertion. You do recognize however that many standard load Linux systems have run for 5+ or 10+ years with no problem, as I too know well as I've had some. Further, with changes in hardware (more work in RAM than ever, less unpredictable disk failure, higher quality cooling, more recognition of component lifetimes, ECC RAM, etc.) I expect that net COTS system longevity is increasing rather than decreasing, and Linux will not crash before the hardware in all but very unlucky cases... particularly with easily scripted, reasonable load testing.
My quote about sqlite and Linux running in harsh environments with limited resources in hundreds of millions - nay - billions of instances, extremely reliably, was primarily referring to mobile devices. Power challenges, many power cycles, physical bashing, temperature variations, heavily intermittent connectivity, dynamic clock speed migrations, moisture, etc. Furthermore, they are far more complex in terms of software stack than 1980s/early 1990s transaction processing oriented mainframes.