Actually, if what you want is to avoid heat loss, reducing the number and area of windows is a pretty good strategy. Simpler (picture) windows are also easier to secure than complex ones that can be forced open.
It's the same with roofs: want to avoid leaks? Make your roof as simple as possible, with as few penetrations as possible.
Very large, complicated projects are harder to audit, to the point of infeasibility (OpenSSL in its pre-heartbleed form comes to mind).
Originally, a lot of people who were against "software bloat" (like Wirth with Oberon) did it because they wanted to run stuff on affordable computers (minicomputers rather than mainframes in the 1970s, microcomputer rather than workstations in the 1980s). That reason disappeared thanks to computing power.
But now, with the internet as Serious Business where attackers create a constant barrage, it doesn't make much sense to run a "full OS" created for minis and workstations when all you want to do is serve some Web content.
Unix-as-a-server-OS is a historical accident borne of the BSD implementation of TCP/IP and the usefulness of Unix-running hardware in the early days of the net.
Yes, one wonders why peterwwillis hasn't, as he suggests as an easy approach, "audited" OpenSSL himself and found the heartbleed in process. And that "over one weekend."
Please do audit the Mirage OS as modified in the article and show what you find. I'm interested to see how you can claim that the OS which doesn't even have a file system, has only drivers for virtual hardware and not even code for starting a process isn't more secure than any other big solution. Above all, the code based on the functional language. It's closest to what we have to have a provably secure system.
This is the same security fallacy as I mentioned twice before, just reworded. Removing code does not leave you with secure code. There's still a memory allocator, I/O layer, a tcp/ip stack, DHCP protocol+service, HTTP protocol+service, HTTPS protocol+service (edit: sorry, there's no HTTPS support in Mirage), and all of the miscellaneous parts required to run those bits, which all have security concerns.
These are the exact same things you expose to vulnerability in a regular Unix OS, and have the exact same potential flaws. Code doesn't become more secure just because you have to use an ABI. Computers (and security) are not magic.
And provable security, really? First of all, proofs have bugs. Second, no real-world attackers have ever been stopped by a provably secure design (partly because implementation is never provably secure). And finally, Mirage was only written to be a statically-typed low-overhead binary that encourages more code reuse. It was not designed with security in mind. That shows that it's nowhere near provable security to begin with, and real-world attackers won't care either way.
Until you present some proof of any vulnerability, your word has not more weight than mine, and I claim that you don't understand what you talk about and that you can't find a way to compromise her setup.
Extra software that is never used does not increase complexity. A Linux distribution is not a large, complex project. I'm guessing your heat loss analogy is about performance? Do benchmarks and get back to me.
If all you want to do is serve (not run) web content, put it on Geocities. Creating your own Geocities is not more secure or easier.
The article was never about "easier" solution. Where have you read anything about "easy"? It's an extreme solution. Think at least once about that please: the "OS" from which she serves her site doesn't even have a file system. Doesn't have users. Doesn't have new processes. Doesn't have drivers for different actual hardware, only for the virtual one.
It's the same with roofs: want to avoid leaks? Make your roof as simple as possible, with as few penetrations as possible.
Very large, complicated projects are harder to audit, to the point of infeasibility (OpenSSL in its pre-heartbleed form comes to mind).
Originally, a lot of people who were against "software bloat" (like Wirth with Oberon) did it because they wanted to run stuff on affordable computers (minicomputers rather than mainframes in the 1970s, microcomputer rather than workstations in the 1980s). That reason disappeared thanks to computing power.
But now, with the internet as Serious Business where attackers create a constant barrage, it doesn't make much sense to run a "full OS" created for minis and workstations when all you want to do is serve some Web content.
Unix-as-a-server-OS is a historical accident borne of the BSD implementation of TCP/IP and the usefulness of Unix-running hardware in the early days of the net.