There have been many discussions in this area recently. Certainly, the worrisome trend of using containers as 'lightweight VMs' (with nearly all the same attack surfaces as regular VMs) suggests the current container-craze is kind of unlikely to change things: your analysis is correct... there's useless fat there on many layers. The question is how do we get rid of it?
You discuss changing the entire design process and electing to use compilers or languages that are capable of shaving off disused codepaths automatically. The problem with this idea is that declaring what is disused is difficult in a conventionally hacked-together-from-components unix-style system. The option to hack stuff together is precisely what makes it a lovely platform for getting things done, and it's hard to retrain most developers/admins on to a greenfield platform (for an example of this approach see, eg. the Erlang or Clojure communities).
I have taken a different yet similar approach in my thinking[1] where one assumption is that behavioural profiling of a codebase from a very high (eg. OS, network) level should be generally applicable to any codebase, allow sidestepping the need to retrain developers, and yet still be able to whittle away much of this fat (though far from all of it). Things like grsec implement learning modes which allow this to be done at the system call level, network profiling is easy as is filesystem monitoring, etc.
When you step back and think about this junk, the sad fact is that the NSA was publicly releasing the kernel-level implementation for this stuff nearly 20 years ago ... and have likely been doing this for even longer. The academic community tries to provide mechanisms for provable correctness but the world's time-sapped developers just chug along the same old tired path.
What we really need, I feel, is automated help that doesn't require a difficult to achieve cognitive paradigm shift for current generation programmers.
You discuss changing the entire design process and electing to use compilers or languages that are capable of shaving off disused codepaths automatically. The problem with this idea is that declaring what is disused is difficult in a conventionally hacked-together-from-components unix-style system. The option to hack stuff together is precisely what makes it a lovely platform for getting things done, and it's hard to retrain most developers/admins on to a greenfield platform (for an example of this approach see, eg. the Erlang or Clojure communities).
I have taken a different yet similar approach in my thinking[1] where one assumption is that behavioural profiling of a codebase from a very high (eg. OS, network) level should be generally applicable to any codebase, allow sidestepping the need to retrain developers, and yet still be able to whittle away much of this fat (though far from all of it). Things like grsec implement learning modes which allow this to be done at the system call level, network profiling is easy as is filesystem monitoring, etc.
When you step back and think about this junk, the sad fact is that the NSA was publicly releasing the kernel-level implementation for this stuff nearly 20 years ago ... and have likely been doing this for even longer. The academic community tries to provide mechanisms for provable correctness but the world's time-sapped developers just chug along the same old tired path.
What we really need, I feel, is automated help that doesn't require a difficult to achieve cognitive paradigm shift for current generation programmers.
[1] http://stani.sh/walter/pfcts/original/