**HINTS for Computer System Design**
====================================

When learning this: try to related to example in the paper as well as 
examples in those paper that I have read

# 0. Functionality:

# 0.1 KISS
- Keep the Interface simple as much as possible
(or otherwise, you will pay the cost fore generalization)
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away"
	+ Why? otherwise, implementation is large, slow, and complicated.
	==> Worst, if you have 6 abstractions, each cost 50% more, then the total 
	cost is *extremely* huge
	+ apply most strongly to interfaces which client used heavily:
		> virtual memory
		> files...
	==> seldom used interface can sacrifice some performance
	+ service cost must be predictable
	
	+ Example of offering too much:
		> memory mapped-file
	+ get it right
	
# 0.2 Corollaries
- make it fast
	+ better to have fast basic operation rather than slow powerful ones
	(best if you can get fast powerful one)
	Why? the client who doesn't want the power pays for basic operation
	+ programs spend most of their time do simple thing
		> hence, fast basic operation is good (like RISC)
- don't hide power (?)
- use procedure argument
	+ to make flexible interface
	(e.g, let the client specify the filter, rather provide it on your own)
- leave it to the client	
	+ e.g monitor (read more)

# 0.3 Continuity
- keep the basic interface stable
	+ E.g: FFS changes implementation, not interface
	+ why? because interface are shared among many system part
- keep a place to stand (when you have to change the interface)
	+ compatibility package implements old interfaces on top of new system
	+ e.g: Mesa world-swap debugger

# 0.4 Make Implementations work
- plan to throw one away
- keep secrets
	+ that is client has no assumption about detailed implementation
	==> easier to program and modify a system
	+ but this make it hard to design a good interface
	+ indeed, some assumption may improve performance
	(a set known to be sorted may reduce the membership testing from n to logn)
	==> striking balance is an art
- divide and conquer: reduce the big/hard problem to small/easy ones
- handle normal and worse case separately
	+ normal case: must be fast
	+ worst case: must make some progress

# 1. Speed: how to make system fast