You
So I'm so sorry about this. I didn't even remember. So how do I do this I don't know how to put it in?
Yeah.
Oh, okay.
Mine is 5 minutes. Sorry. Sorry, this is my fault.
The clip is supposed to be on the left of him.
Yeah, it's pretty tight.
Yeah.
Okay.
I hope that can you please be honest.
Yeah, I'm going to hold this one.
All right.
All right, boys.
So it had one global file tree rooted as lash.
Most of it was just files.
Well, yeah, there we go.
Most of it was just files, actual files.
Some of it was directories.
Others were devices, so we had devices being represented as files like terrenals,
hard drives and line printers.
Some of them were programs that were stored in slash bin.
What am I doing here?
And when you want to run one of these programs because of the process.
Process can copy itself.
It replaces itself with another process.
It can send numeric signals to other processes to indicate specific events.
For example, I'm killing this one right now.
Besides opening reading writing, you could use the device specific control call.
And you would run programs using the shell.
This is an example over there.
The operating system did not define any file formats.
So it was the program's responsibility to know what you do with the data in a file.
Therefore, you could make scripts by starting a sequence of commands in a file.
And ask the shell to execute it.
Now, there you go.
To build programs, developers would create dependency rules in a make file and run make.
Because everything was organized in a file tree, it became unanimous with unix that everything was a file.
To this day, version 7 still serves as the foundation to modern unix-like operating systems,
for example like Linux, Android, iOS, and Mac OS.
However, things were changing very fast.
Ethernet technology starts to be commercialized in 1980.
And it becomes obvious that was an immediate need to start connecting machines between each other.
But unix wasn't made for that.
Computers were getting faster and memory was becoming cheaper.
And graphical terms started to become viable.
Like the Blit Terminal built by Rob Pike in 1982.
It looked like something like this.
It was, in fact, so early that people didn't even know what a mouse was.
And I did, but make this BNG index 16 to make it easier for me to download the file.
Oh, this is the run computer.
All right.
So, I am in the run computer again.
All right.
Unix can now render graphics.
But now, terminals were no longer speaking just next.
This latch of the development of a window manager, which doesn't want to show up right now.
It should thank you.
Thank you.
Let me delete this guy.
There you go.
It looked like something like this, right?
I think that some of you are familiar with it.
The way you would use it would be to hold the right mouse button.
And many would show up showing all of the options that you could use to manage the layers.
You know, back then layers windows were not a expression used.
It was actually called layers.
So, you could open a terminal like that.
You would hold the mouse button 3, which would be this one.
You would create a window, the size you want it.
And now, we also had this graphical innovation led to the development of new graphical tools.
For example, the text editor Jim, which looked like something like this.
Now,
you have the ability to use multiple shells at the same time on the same screen.
We take that for granted now, but it foreshadowed how modern window systems would work.
It enabled the development of new graphical tools, just like the one I showed you.
I am very confused about your computers.
I should have not done that.
So, in 1983, BSD4.2 is released.
It comes with a socket API.
And this was our solution to networking.
And to this day, it is the D facto Unix networking API.
However, that solution introduced problems.
You should be simple.
Now, instead of one IOModel, the kernel grew separate paths for terminals, pipes, and networking.
It worked, but the elegance was gone.
Now, as you all know, in Unix, everything is a file.
So, here's the list of things that are not files in Unix.
So, in 1984, the year, not the documentary, by the way,
the engineers at Bell Labs started developing their own version of networking.
So, instead of adding new kernel objects for networking, they worked on streams.
This allowed a user program to interact with a device.
And therefore, it was possible to talk to other computers.
Good.
The machines can connect to each other.
Now, what?
Well, the question is, how do you make software network aware?
How do we rewrite all of our old software to make them network aware?
The answer is, you don't.
You create a new directory.
You name your machines.
And you access the file through it.
And now, copying a file is just copying a file.
You copy a file between machines is no different from a local copy.
And because these machines were just names in the file system,
that meant you could change them together to access files from another server
that you didn't have access to.
Now, mind you.
This was five years before an FS was released.
Okay.
So, we can name machines and put them in the file system.
But what else can we put in the file system?
What about things inside the machine?
What about processes for example?
The answer is surprisingly the same.
We just name the processes and find a way to put them in.
And find a directory you should put them in there.
But wait a minute.
A process file system.
I've already seen that somewhere.
Isn't that a little bit you complicated?
Isn't that very not unix-like to have something like this?
Well, if you're thinking about the unix file system,
then yes, that's definitely you complicated.
But that was not the case for unix.
Back then, we only had one file per process.
And I don't know how I'm going to the next slide,
but I'm going to accept it.
So, now you could write a process inspector.
And you didn't need any special system calls for it.
You could just use standard file system operations.
Now, for the very first time, we have a synthetic file system
that doesn't represent anything physical in the computer.
And this is very important to understand, because otherwise,
it's going to be difficult to understand plan 9 later down the line.
So, whereas previously files represented only physical things,
for example, like a real file on a hard drive.
Now, we have a completely synthetic file system
that doesn't represent anything physically.
So, what comes after number 7?
Number 8, unix version 8 is released.
It comes with networking graphics,
the news, lashing, file system, and the lashing product file system.
Now, because terminals were now graphical, we have a problem.
You see, the file that is used to represent the terminal
was made with the intention of having only one program at a time accessing it.
So, now we had multiple shells at the same time trying to access this file.
So, how do we solve that problem?
The key is to identify the root of the problem.
So, the problem happens when we try to open the file.
So, what if we could make it so that only one program would open this file at a time,
and the other ones would be transferred to a virtual file.
Now, the way you would do that with, you know, the BSDs,
they decided to make a special file for it.
You know, a special kernel case for it.
The people at Bell Lab didn't really want to do this.
They knew that this would not be in the long term a good solution.
So, they decided to think about something that would mess with the namespace itself.
So, they thought about making mounts with strings.
So, now you could take a string and mount it directly to a file.
This would allow you to create a program that would open the terminal.
We would have only one program reading and writing to the terminal.
And whatever programs that try to access it later after it mounted itself as a terminal
would become, would be talking to this program.
A program like Vismon for example.
It is used to display system time and also, you know, incoming email.
So, at this point, a pattern should be obvious.
Instead of trying to create a new object something external to the file system.
Whenever unix engineers find a problem, they try to fit it inside the file system.
Now, what people don't understand is that it's never being about files for the file's sake.
You know, what you really want is a single interface that is uniform across your entire system.
Because the moment you want to add a new technology, if you are able to incorporate it into this interface,
every previous software that you have ever written is going to automatically support it.
So, you don't need to backtrack your work and start writing things again.
Now, since operating systems need to represent files anyway, why not try to use that interface to use it to represent everything?
I mean, how else are you going to represent files if not in a hierarchical file free?
So, this is the true spirit of everything being a file.
And it is with this spirit that then is rich in Dave Prasoto, brought to an networking on unix.
So, by the mid-80s, we already had several services running on our networks,
and they tried to bring those to the file system.
Since Mount had been extended, we could now have a file connected to a stream.
Now, we can create a directory and store all those connections in it.
We're going to call it the connection server, CS down there.
Now, some files stuck directly to the server.
Other files act as a middleman for more complicated protocols.
So, for example, if you wanted to dial a phone, you would call for the phone file,
and then you would provide the phone that you want to talk to.
If you wanted to talk to an email server, you would ask for the TCP file,
and then you provide the address and the port.
And then you start sending the SMTP messages by yourself.
Not by yourself, you're client.
So, everything was being done with file operations.
You didn't need an extra system, call you didn't need to create a new kernel driver
for the TCP for the IP stack.
So, moving away from network for a little bit.
By this time, the text editor Jim was already showing a little bit of its limitations.
He was a cut-and-paste text editor, and it was limited to the blip thermal.
Now, Rob Pike started to write the text editor Sam.
Both of these text editors tried to solve the same problem space.
How do you edit large files over a very low link?
Now, the way Sam went about this problem was to create a client server model,
where the server would hold the file, and the client would just send commands to edit those files.
It worked really well.
And for that reason, Sam was designed with a more robust command language.
It was a visual text editor, but it's true power state in the command language that it possessed.
So, as you can see, this is an example of the same text editor.
We have a blue window over there where you can resize, move around.
You put your commands in there.
You can create as many yellow windows as you want.
This is how many files you can edit at a time.
There you go.
I have made a mistake.
There you go.
So, what comes after?
That's right.
Version 9.
Unix's version 9 is related in 1986 with mouse streams, the connection server file system, and the text editor Sam.
Now, earlier the Unix had a culture.
At this point, the computer world was vastly different from when Unix was conceived.
For that reason, a lot of things that had been put on the system were not made for them.
Unix had become big and fragmented.
This was bad.
You see, everyone had access to the same file system in the same machine.
This local interaction created local community, a fellowship that built the foundations of Unix.
But now, Bell Labs had hundreds of Unix installations across the laboratory.
And each one with their own disk, their own users, and their own configurations, and their own quirks.
But how do we preserve this culture that was built on locality?
When systems were clearly becoming more distributed and isolated.
If we go back and think about it, the computer in early Unix, we didn't really have any network.
Because there was no need to have any.
In a sense, the network was the computer itself.
So, that's it.
That's the idea that drove the development of the new operating system that Bell Labs would create.
Now, instead of treating the network as an amalgamation of individual Unix machines,
why don't we create a network that is the computer itself?
But Unix would not be abandoned yet.
It would be developing parallel with both versions.
So, the first design decision was to delegate the different parts of the operating system to different physical machines.
So, the operating system was divided into three independent parts.
First, we had the file server.
It only did one thing, which was to serve files using a protocol, which I'll get into detail later.
It could not execute any commands.
Next, we had the CPU server.
There we go.
Basically, you would use it to run commands remotely on your machines.
It did not have any disks.
It's kernel did not even have drivers for audio, keyboard, and stuff like that.
It would just be used as a remote machine where your turn-lose, which are the third type of computer, would connect to.
Now, turn-lose were a little bit more complete than the CPU servers.
They could do the same thing that could execute commands, not remotely though,
but they were not as powerful as a CPU server.
So, in essence, what you want to do is use the terminal to do lightweight work,
and when you need to compile something heavy, you would connect to the CPU server.
Now, when developing the new operating system, the team at Bell Labs followed two principles.
First, we're going to have a private view of the name space for each and every individual process.
The second principle is that everything in this operating system is going to be done with a single protocol.
Now, let's talk about this last one first.
In order to create a network service, we need to write true programs of client and a server.
Both of them need to write network code, and we need to design a protocol for them to speed.
We have to do this every single time.
Now, what if we define a new interprocess protocol for all those services?
And what if we use that protocol for local machine services as well?
That means that we would be able to have a significant amount of service with only a single client,
and everything would be remote file, it wouldn't matter if the server was a remote file server or a local file server.
That is the conception of the 9-P protocol.
Here's the current 9-P protocol.
It's pretty simple. I can print it in the entire screen.
So, having local services, talk the same protocol, which is a file system protocol, as remote services has a very big implication.
If we can design our device interfaces as file systems, we can share the devices around the network.
This is how you would make a CPU server, for example, play audio on a terminal.
Even though there was not any drivers or special code for that.
Remember, this is all possible.
Due to the fact that we have a single uniform interface to our system.
Now, let's get back to our first principle.
The go behind private namespaces, what should give power and flexibility to users.
If they can build their own private spaces, they don't have to wait for the system administrator to give them permission,
and they don't have to worry about affecting other users.
But, in order to manipulate namespaces, we need to understand what the concept of a mount, a bind, and a union directory are.
So, amount to something that you can straight up from unix.
You just have a device or a service that you want to mount, and you provide a mount point for it.
Bind is something similar, except that it takes an existing point in your tree, and you'll buy it somewhere else.
Now, both points are referring to the same place.
And a union directory takes the same idea as the mount, except that they don't replace one with the other.
They join their files together, and notice how the original files of the directory are still there, but now we have two profiles.
This is something that Unix would never allow.
When you join two directors together, you can specify which one comes before and which one comes after.
And this is going to determine what profile actually gets read.
Now, this might feel like you're linking files and directories, but that's not the case.
This is a virtual view that the kernel is showing to you, and this is not supposed to happen right now.
I don't know what happened.
Well, we're going to be without the computer turned off.
I was just going to make.
All right, so we're going to wait for the computer to turn on.
And since I already went through the heavy stuff, I am going to make a demonstration of what namespaces are,
because I believe that it is kind of hard to understand the purpose and what you can do with a namespace,
if you don't see it being used at the time.
So let's just wait for a while.
I'm sorry, what do you say?
So when you do a union mount, you can tell the kernel if the director is going to come before or after the other one that was already there.
So if it is going to come before, it is going to take priority over the directorie that was there.
So this is the profile that is going to be used.
However, if you tell it that it comes after, it has less priority.
Does that make sense?
Yeah, yeah.
So actually, it's already 9.30, 6.
So this is pretty much the time I had.
I apologize for the technical delays.
Yeah, that's pretty much it, guys.
Thank you very much.
Thank you.