Map
Index
Random
Help
th

QuoteRef: lampBW10_1983

topics > all references > ThesaHelp: references i-l



ThesaHelp:
references i-l
ThesaHelp:
ACM references f-l
Topic:
interface between program modules
Topic:
handling complexity
Topic:
good requirement specifications
Topic:
importance of information hiding for requirement specification
Topic:
general vs. specific purpose systems
Topic:
efficiency
Topic:
function cost
Topic:
abstraction by common attributes
Topic:
procedure valued variables
Topic:
debugger
Topic:
software maintenance by patching
Topic:
monitored statements and events
Topic:
syntax analysis
Topic:
program module as encapsulation
Group:
program design
Topic:
design for change
Group:
testing
Topic:
import/export lists for defining an interface
Group:
exception handling
Topic:
builtin functions
Topic:
ordered data types
Topic:
collecting statistics on a UserInterface
Topic:
unbounded precision
Topic:
data caching
Topic:
interpreter
Topic:
just-in-time compilation
Topic:
information as a hint
Topic:
file directory
Topic:
self-identifying data structures
Group:
file system
Topic:
disk allocation
Topic:
hardware for interprocess communication
Topic:
multi-processing for a user interface
Topic:
incremental execution
Topic:
no need for efficiency
Topic:
general purpose computer systems
Topic:
memory management by working sets
Topic:
memory management by paging
Topic:
task scheduling
Topic:
plan-based task scheduling
Topic:
error safe systems
Topic:
reliability of distributed systems
Topic:
reliable communication
Topic:
logging data and events
Topic:
log-structured rollback-recovery
Topic:
immutable files and data
Topic:
version control
Topic:
version identification
Topic:
database transactions

Reference

Lampson, B.W., "Hints for computer system design", Proceedings of the ninth ACM Symposium on Operating Systems Principles, ACM, October 1983. Google

Other Reference

Operating Systems Review, vol 17, num 5

Quotations
34 ;;Quote: interface design is the most important part of system design; should be simple, complete, and allow an efficient implementation
34 ;;Quote: an interface defines a small programming language of objects and operations; does not need a syntactic definition
34 ;;Quote: perfection is reached when there is nothing to take away
35 ;;Quote: an interface should capture the minimum essentials of an abstraction, without generalization
35 ;;Quote: an interface is a contract to deliver a certain amount of service and functionality
35 ;;Quote: while clients of an interface depend on an efficient implementation; the costs are seldom documented
35 ;;Quote: everything should be as simple as possible but no simpler
36 ;;Quote: an interface should be fast; basic operations should execute quickly, otherwise everyone pays for a powerful by slow operation
37 ;;Quote: an interface shouldn't hide power; abstractions should not bury the power of lower abstraction levels
37+;;Quote: an abstraction should conceal undesirable properties without hiding desirable ones
37 ;;Quote: procedure arguments increases the flexibility of an interface; e.g., a procedure instead of a mini-language for testing some property
37 ;;Quote: Spy allows a user to patch the supervisor program; no wild branches, no loops, short, stores only into statistic memory
37 ;;Quote: an interface should solve only one problem and let client routines do the rest; e.g., a parser calls client-supplied semantic routines
38 ;;Quote: constant tension between improving a design and providing stability and continuity
38 ;;Quote: if change an interface, should provide backward compatibility by implementing the old interface
38 ;;Quote: world-swap debugger writes the memory image to disk and swaps in the debugger; clumsy but almost no dependence on the target system
40 ;;Quote: handle normal and worst case separately; the normal case is fast and the worst case makes progress
40 ;;Quote: if a count reaches its limit, reduce by half, increment an overflow count in a hashed table, and set a flag; reverse for decrementing
41 ;;Quote: if in doubt, split resources instead of sharing them; faster allocation and access, more predictable
41 ;;Quote: interpret by dynamically translating a compact, flexible or mnemonic representation into a fast representation and caching the result
43 ;;Quote: use hints to speed up normal execution; like cache but may be wrong and doesn't need associative lookup
43 ;;Quote: for Alto and Pilot, a file's leader page defined the file's directory and string name; the actual directory entry was just a hint
43 ;;Quote: the bit table for free disk pages is a hint, verified against the label of the free page
43 ;;Quote: on the Ethernet, lack of a carrier is a hint that a packet can be sent
44 ;;Quote: often better to use a straightforward, brute force solution that is easily analyzed, than a poorly understood one
44 ;;Quote: compute in the background when possible; rapid response to requests, and load balancing
44 ;;Quote: use batch processing if possible; more efficient and simpler error recovery
44 ;;Quote: a general-purpose system can not optimize the use of resources; too easy to overload the system and degrade service by thrashing
44 ;;Quote: in a paging system, the only important thing is to avoid thrashing; otherwise spend all of the time waiting for the disk
45 ;;Quote: few parameters work in processor scheduling; interactive vs. batch, foreground vs. background, fixed share of cycles per job, unused cycles wasted
45 ;;Quote: shed load to control demand rather than allowing the system to become overloaded
45 ;;Quote: reliability requires simplicity
45 ;;Quote: while end-to-end error recovery is sufficient, it requires a cheap test for success and may cause severe performance problems under heavy load
46 ;;Quote: for reliability, log all updates to an object; since append-only, non-volatility is cheap
46 ;;Quote: while objects are not immutable, a version is immutable; change version whenever change object
46 ;;Quote: version id by [object id, number of updates]; then replaying the specified number of log entries yields the desired version
47 ;;Quote: all actions should be atomic or restartable; i.e., use transactions


Related Topics up

ThesaHelp: references i-l (342 items)
ThesaHelp: ACM references f-l (241 items)
Topic: interface between program modules (55 items)
Topic: handling complexity (59 items)
Topic: good requirement specifications (36 items)
Topic: importance of information hiding for requirement specification (23 items)
Topic: general vs. specific purpose systems (11 items)
Topic: efficiency (96 items)
Topic: function cost (8 items)
Topic: abstraction by common attributes (19 items)
Topic: procedure valued variables (34 items)
Topic: debugger (37 items)
Topic: software maintenance by patching (26 items)
Topic: monitored statements and events (16 items)
Topic: syntax analysis (29 items)
Topic: program module as encapsulation (28 items)
Group: program design   (13 topics, 453 quotes)
Topic: design for change (75 items)
Group: testing   (18 topics, 551 quotes)
Topic: import/export lists for defining an interface (20 items)
Group: exception handling   (12 topics, 305 quotes)
Topic: builtin functions (6 items)
Topic: ordered data types (8 items)
Topic: collecting statistics on a UserInterface (12 items)
Topic: unbounded precision (9 items)
Topic: data caching (28 items)
Topic: interpreter (59 items)
Topic: just-in-time compilation (19 items)
Topic: information as a hint (18 items)
Topic: file directory (42 items)
Topic: self-identifying data structures (18 items)
Group: file system   (9 topics, 285 quotes)
Topic: disk allocation (32 items)
Topic: hardware for interprocess communication (31 items)
Topic: multi-processing for a user interface (14 items)
Topic: incremental execution (22 items)
Topic: no need for efficiency (28 items)
Topic: general purpose computer systems (9 items)
Topic: memory management by working sets (18 items)
Topic: memory management by paging (23 items)
Topic: task scheduling (49 items)
Topic: plan-based task scheduling (13 items)
Topic: error safe systems (75 items)
Topic: reliability of distributed systems (33 items)
Topic: reliable communication (29 items)
Topic: logging data and events (16 items)
Topic: log-structured rollback-recovery (12 items)
Topic: immutable files and data (57 items)
Topic: version control (30 items)
Topic: version identification (12 items)
Topic: database transactions (26 items)

Collected barberCB 1/87
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.