i keep reading about these shaihalud npm supply chain attacks, so, i built a containerized dev workflow that quarantines npm completely. per-project images, isolated dependency volumes. nothing touches the host!
Comments
naikrovek•2mo ago
I really wish Plan9 got more attention when it came out.
All processes in Plan9 are given their own namespace. By mounting things to or unmounting things from the namespace, you grant or disable access to specific parts of the filesystem. And because everything is a file in Plan9, the filesystem is the filesystem, the audio device is part of the filesystem, the video device is part of the filesystem, network interfaces are exposed via the filesystem, etc.
Isolation by default.
In 1995.
Docker would never have been needed if operating systems adopted this feature. The kraken known as Kubernetes might never have been needed if Plan9s features were adopted.
It’s too late to change how things are, but it’s never too late to set things right.
We need an operating system which isolates child processes from their parent and from siblings, and from everything else unless access to specific things is granted at launch time.
We’ve built so much crap on top of our old operating systems that we view it as normal. We should not need docker or virtualization to have isolation. There is no technical need for those things, and they are each another layer on a stack that is maybe already too tall. They are points of failure and if operating systems were capable, we would not need them.
The source code and design of Plan9 can fit entirely inside one mind. It isn’t a huge behemoth. It takes single digit seconds to compile.
It could be the basis of something supreme.
If I were rich, among my other altruistic endeavors, I would be hiring folks to develop this OS into something a little more current and a little more fit for the environment we see in 2025 and beyond.
My point: one should not need docker to do what you have done. Default per-process isolation should be a core feature of the operating system.
neechoop•2mo ago
plan9 were always ahead of its time
Yasuraka•2mo ago
> The kraken known as Kubernetes might never have been needed if Plan9s features were adopted.
Which Plan9 features exactly give me a unified API layer to handle workload scheduling incl. fault tolerance, flat networking across a cluster or service discovery?
Containers are an implementation detail and not what Kubernetes is fundamentally about.
naikrovek•2mo ago
Let’s be clear about one thing: Kubernetes is an operating system on top of Linux which exists solely because operating systems don’t provide what it needs already. I’m saying that operating systems should provide scalable ways to launch applications securely across many physical machines natively. Plan9 offers that, and it has for 30 flippin years.
Plan9 has those things out of the box if you configure them. Fault tolerance, flat networking across a cluster, and service discovery. And if I’m wrong about that (my knowledge of both Plan9 and kubernetes is incomplete) then it would almost be trivial to implement given what plan9 has out of the box. In fact, I think the built-in network database can do all of these things if you put the relevant data in and use it. It was designed for these exact things.
Plan9 is designed to be deployed as lots of physical systems all working cooperatively. User systems and servers in a server room, both. A program that lives on computer A can run using the CPU of computer B and the networking of computer C. Natively. It can look up the address of any service via the network database (provided that info is put into the database when that service is started) and all of it. Note that I am not talking about DNS. That is separate from the network database.
Plan9 is different and it is superior in many ways.
Unix was built with the assumption that end users had terminals and that computing was centralized at the server. That assumption is no longer even remotely true. Yet we still cling to it as if it is ideal. It is not.
Plan9 was built with the assumption that everyone had capable computers at their desks and that people seated together often worked on things together. Closer to where we are today, but not quite. Today we have near-supercomputers at our desks in the form of development machines and servers of all descriptions in the server room, both more powerful and less powerful than our local machines.
If Plan9 were designed today it would be different, but the core features would remain.
And if you look at the source for Plan9 you’ll see that they got a hell of a lot done with very few lines of code. They were very, very “pro-simplicity”. Go read it and see how they did it. Then count the lines of code in Kubernetes and see which is bigger and more complex and then ponder that for a bit. It would have been easier to write an operating system to handle those workloads natively than it was to write Kubernetes.
Yasuraka•2mo ago
Oh thats great to hear, go ahead and post some simple examples then if you will, e.g. what does a cron job look like in Plan9's API?
Clearly,
> which exists solely because operating systems don’t provide what it needs already
means Plan9 provided those needs already.
elmerfud•2mo ago
I'm not sure, at the end of the day, it would have made that much difference. Those who are security and separation aware still are and plan9 would have been a much easier tool for those people.
Those people who are not, still would not be, and having that separation ability wouldn't help. You see this with apps and other things that have the ability to limit their access but you want the app and you just click through without reading what permissions it wants. So those who just want to use something without understanding the danger of it still fall prey to nefarious actors.
naikrovek•2mo ago
It would have if security people really existed as a career at the time I think. But who knows.
They were thinking ahead when they made themselves OS. No one else was.
naikrovek•2mo ago
All processes in Plan9 are given their own namespace. By mounting things to or unmounting things from the namespace, you grant or disable access to specific parts of the filesystem. And because everything is a file in Plan9, the filesystem is the filesystem, the audio device is part of the filesystem, the video device is part of the filesystem, network interfaces are exposed via the filesystem, etc.
Isolation by default.
In 1995.
Docker would never have been needed if operating systems adopted this feature. The kraken known as Kubernetes might never have been needed if Plan9s features were adopted.
It’s too late to change how things are, but it’s never too late to set things right.
We need an operating system which isolates child processes from their parent and from siblings, and from everything else unless access to specific things is granted at launch time.
We’ve built so much crap on top of our old operating systems that we view it as normal. We should not need docker or virtualization to have isolation. There is no technical need for those things, and they are each another layer on a stack that is maybe already too tall. They are points of failure and if operating systems were capable, we would not need them.
The source code and design of Plan9 can fit entirely inside one mind. It isn’t a huge behemoth. It takes single digit seconds to compile.
It could be the basis of something supreme.
If I were rich, among my other altruistic endeavors, I would be hiring folks to develop this OS into something a little more current and a little more fit for the environment we see in 2025 and beyond.
My point: one should not need docker to do what you have done. Default per-process isolation should be a core feature of the operating system.
neechoop•2mo ago
Yasuraka•2mo ago
Which Plan9 features exactly give me a unified API layer to handle workload scheduling incl. fault tolerance, flat networking across a cluster or service discovery? Containers are an implementation detail and not what Kubernetes is fundamentally about.
naikrovek•2mo ago
Plan9 has those things out of the box if you configure them. Fault tolerance, flat networking across a cluster, and service discovery. And if I’m wrong about that (my knowledge of both Plan9 and kubernetes is incomplete) then it would almost be trivial to implement given what plan9 has out of the box. In fact, I think the built-in network database can do all of these things if you put the relevant data in and use it. It was designed for these exact things.
Plan9 is designed to be deployed as lots of physical systems all working cooperatively. User systems and servers in a server room, both. A program that lives on computer A can run using the CPU of computer B and the networking of computer C. Natively. It can look up the address of any service via the network database (provided that info is put into the database when that service is started) and all of it. Note that I am not talking about DNS. That is separate from the network database.
Plan9 is different and it is superior in many ways.
Unix was built with the assumption that end users had terminals and that computing was centralized at the server. That assumption is no longer even remotely true. Yet we still cling to it as if it is ideal. It is not.
Plan9 was built with the assumption that everyone had capable computers at their desks and that people seated together often worked on things together. Closer to where we are today, but not quite. Today we have near-supercomputers at our desks in the form of development machines and servers of all descriptions in the server room, both more powerful and less powerful than our local machines.
If Plan9 were designed today it would be different, but the core features would remain.
And if you look at the source for Plan9 you’ll see that they got a hell of a lot done with very few lines of code. They were very, very “pro-simplicity”. Go read it and see how they did it. Then count the lines of code in Kubernetes and see which is bigger and more complex and then ponder that for a bit. It would have been easier to write an operating system to handle those workloads natively than it was to write Kubernetes.
Yasuraka•2mo ago
Clearly,
> which exists solely because operating systems don’t provide what it needs already
means Plan9 provided those needs already.
elmerfud•2mo ago
Those people who are not, still would not be, and having that separation ability wouldn't help. You see this with apps and other things that have the ability to limit their access but you want the app and you just click through without reading what permissions it wants. So those who just want to use something without understanding the danger of it still fall prey to nefarious actors.
naikrovek•2mo ago
They were thinking ahead when they made themselves OS. No one else was.