Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

These decisions here are all older than Windows and weren't in reaction to them. It's in reaction to the awful mainframe ways to spawn processes like using JCL.

We've sort of come back to that with kubernetes yaml files to describe how to launch an executable in a specific env and all of the resources it needs. Like it can be traced explicitly, the Borg paper references mainframes and knowingly calls the language that would be replaced by kubernetes's yaml files 'BCL' instead of z/OS's JCL.



Plan9 is a lot older than Kubernetes and has the same namespacing of all processes. So it's not impossible to have a "*nix like" OS that still has mainframe-like separation of concerns to ease deployment.


The distinction I'm making here is between opt-in and opt-out namespacing.

Plan9's vfs namespacing is closer to clone(2) than kubernetes.


If you want foolproof sandboxing, you need opt-out namespacing. Because there might be resource types that your version of the software doesn't know about, and these should really be namespaced by default.

Besides, what really matter is whether namespacing is idiomatic or not. It was always idiomatic in plan9, and containerization has certainly made it more idiomatic even on *nix systems.


Plan9 was the model you're saying isn't foolproof. Switching namespaces were explicit calls seperate from process creation.

The Linux namespace scheme was explicitly inspired by plan9, but didn't have nearly as many gotchas (like plan9 vfs namespaces being only per uid).

My bringing up kubernetes is to contrast the Unix style methods in a way that developers today would recognize.


> The Linux namespace scheme was explicitly inspired by plan9, but didn't have nearly as many gotchas

There were other OS's doing similar stuff at the time, e.g. BSD jails predate Linux containers AIUI.


I'm going to be honest, I don't know what point you're arguing against at this point. Can you clarify that?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: