Here we're going to talk about design.
Much of what we say applies to implementation as well.
But we're going to focus this on the higher-level design.
So you can see how broadly
the principles we talk about are going to be applied.
I'm going to give you a quick overview
of the principles and the ideas underlying them.
Then, we're going to talk about the principles.
These are from Saltzer and Schroeder's principles as
updated by Saltzer and Kaashoek quite recently.
There was one change that I will talk about
because it's a very interesting change.
Now, as a puzzle,
Windows and Unix and Linux like
systems all have this admin
or root user that effectively is omnipotent,
they can do whatever they like on the system.
Dennis Ritchie, one of the designers of the Unix system,
called the existence of such a user
a theoretical flaw as well as a practical one.
Why? I'll give you
about 30 seconds to think this one through.
The main problem is that
user is simply too powerful.
It combines necessary functionalities,
but it combines them all together
on one system in one user.
What happens if that user makes a mistake?
What happens if someone breaks into
the system and acquires access to that account?
They can do whatever they want.
Ideally what should happen are
the functionality should be split up among many users.
So if for example I break into
the one that controls backups,
I still can't affect networking
of people on the system currently.
All right. So, let's look at these design principles.
First of all, they have two themes underlying them.
The theme of simplicity and the theme of restriction.
Simplicity is basically well,
if it's simple is less that can go wrong
and it's easier to understand.
So there are fewer inconsistencies
and I'm more likely to find
inconsistencies or problems than
if it's very hideously complex.
Restriction goes back to the security rule
of try to keep things as contained as possible.
Minimize access, inhibit communication
where communication is not necessary and so forth.