Those were the days…when we didn't have stupid watchdogs like memory protection and preemptive scheduling, and we all shared resources nicely and fairly, all the time. There were never crashes because someone touched memory that they weren't supposed to, or hangs because someone decided they were more important than all the other processes. No siree.

What? These aren't completely orthogonal at all, they all fall under the umbrella of "process isolation" and containerization. There's a reason we have safeguards for processes in place; it's because it's a lot better when you have something to police badly behaved software than to trust that everything will work well 100% of the time.

Here's my point: those things mentioned were improvements on things that didn't work very well even for trusted applications that did nothing unreasonable.

When your development environment or even regular desktop software spreads itself all over the filehierarchy as a matter of practice, conflicting and interfering with every other application because it does the same thing, that's taking something that used to work just fine and breaking it. Then you add a layer of abstraction like containers to solve the mess you created.

Containers are a good idea for a lot of things, I just don't think I should need them to run normal everyday software.

Not on Unix though. "Stepping all over each other" sounds like the guiding design principle behind Unix's folder structure and dynamic library loading aproach.

Docker's isolation is far more than just isolation of files and folders. It's more like J2EE for Linux :)

Containers help with keeping bad behaviors from stepping all over each other.

Unless of course you're saying that most software in the GNU/Linux world is badly behaved, which I'd kind of agree with.

That never happened... Maybe it happened in some tight academic environment for a few years, but once the cat was out of the academic environment, it basically never happened.