DistOS 2018F 2018-09-26

From Soma-notes
Revision as of 02:09, 3 October 2018 by Sheldon (talk | contribs) (→‎Notes)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Readings

V, Amoeba, Clouds:

Notes

in-class lecture notes: - V – Fast RPC but wanted to do software backed plain

Non of them are saying let’s use UNIX so they tried other things but did not caught on

Amoeba:

Wanted to cluster computers so that users at terminals that could send load balanced jobs to the cluster and easier to implement than a pear implemented system.

Bunch of servers do things, and file servers and then clients

So distributed but specialized, not peer-to-peer

File system implemented as a set of processes

Had Unix interface but removed file system approach...had a notion of files but their files were different. Contiguous blocks but they were also immutable files .... replicated at will...powerful idea b/c we will see again...immutability why? Avoid the problem of shared state...when you replicate it, you replicate it and your done, don’t need to synchronize. If want something different, make a new file or segment. Distributed files, will see immutable stuff like Amazon S3; have versions but the underlying system is immutable. Git is immutable underneath b/c taking these things identified by hashes and that is being stored.

Mutability to immutability with versions....can use kinda the same but the underlying system is very different.

Ameoba is influential b/c they did a couple of things in an interesting way. Lessons learned from the dream of a distributed OS. Key lesson, how did they do permissions? Access control lists...no They had capabilties...big idea in access control b/c normally when we think of UNIX permissions access control lists....what’s the objects being controlled and who can access it. With a capability model instead we have a string set of bits and if you have these bits you can access the resource and if you don’t have it can’t access. Get the capability, and once have it can use it to access that resource. It means that the permission granting is separate from the permission check...don’t need to know who you are but that you have the correct capability. To make it work well you need something cryptographic...Ameoba didn’t have good cryptography (48 bits) but it was the concept model...distributed access control.

Linux capabilities are not the same, same term but only some of the notions....capabilities is an un-forgable bit string to gain access to resource. Keys today are not b/c of performance reasons.

Active directory in Windows is based on Kerberos and the server gives a ticket that allows access to resources...basically capabilities.

Process model:

Clouds

What went wrong? Execution context are not indexed. Moving between address spaces. Normally execution context and state are connected. If you blow that up, what’s your security model?

Why didn’t UNIX die? Programs and development environment would have to all be developed again from scratch. Get new OS that do new things when you have a reason, a use case. Unix is below, everything else on top.