By Amir Mohsen Djourabchi, Cen Kwang Ge, and Robert Nakamoto

Professor: Eddie Kohler
Office: 4531C Boelter Hall
Office Hours: MW 4~5 pm
Discussion Section: F 2~4 pm 5440 Boelter Hall
Class Website: http://www.read.cs.ucla.edu/111/
Textbook: Operating System Principles (can be purchased from Course Reader Material located at 1137 Westwood Blvd)
Progamming Language: C
Operating System: Unix/Linux (Linux Users Group at UCLA provides free installations and consultations)

1/3 Midterm (Wednesday 05/09) and final (cumulative 60% of 1/3): Both exams are open book and open notes.

1/3 Labs: There will be four labs for the quarter. The labs cover the following topics:

1. Writing a shell
2. Creating what looks like a block device inside a Linux Kernel (might be changed)
3. Implementing a File System
4. Working with some kind of server and investigating some security problems

1/3 Miscellaneous assignments: Including:

• Design problem (4 ~ 8 pages single spaced): Each team is required to complete one design project, which involves an extension of one of the four labs. You will need to create a design specification for some additional functionality and implement parts of it. Individuals/teams will be assigned ahead of time to one of the four design projects.
• Mini-labs: There will be two to three smaller labs for the quarter designed to offer some hands-on experience with course concepts.
• Paper report: One-page report on current operating system developments will be assigned during the end of the quarter.
• Class participation
• Scribe notes: At the beginning of each lecture, three students will be asked to serve as scribes. Their job, after the lecture, is to collaboratively create an online notes document using the class wiki. Notes are due about one week after the lecture. Details can be found here.

Late Policy: Every student is allowed three free late days which they may use on any assignments throughout the quarter. After the free late days are gone, each day an assignment is submitted late will result in a grade reduction of about one letter grade.
Note that the unit of this late policy is days, neither hours nor minutes. As long as an assignment is late, it will be counted as one late day even though it is only late for several hours or minutes.

The following is a quote from Barbara Liskov who was a researcher at IBM and a professor at MIT. This is what she said about what it is like to be a software researcher:

Unlike engineers who design something in the physical world and are constrained by the laws of gravity, Liskov calls her medium "infinitely plastic." "We can do anything," she says. "There are no constraints." [from a profile of Liskov by Sarah P. Jones published in the Boston Herald, Sept. 30, 1996]

Why is software so plastic? Computers are the first type of artifact where improvements to the artifact help you improve the artifact faster. Software systems are plastic because we can use the first generation of the software to make the next generation more powerful. This fact can be written as the following differential equation:

d(technology)/dt = k * technology

Solving the differential equation results in the following:
=> technology = c * e ^ (kt) (i.e. technology is an exponential function of time)
The better our technology is, the faster our technology will improve.
The result of this property is that computer system technology continues to progress at an unprecedented rate, as described by Moore's Law.

Some examples:

1)
In 1973, Ethernet was designed at the speed of 3 Megabits/second.
In 2007, Ethernet’s speed is 10 Gigabits/second.
There is an increase of 3333 times in speed in about 30 years.

2)
In 1983, purchasing 1 GB of memory costs $200000.
In 2007, purchasing 1 GB of memory costs $.10.

Because of these properties we have a huge opportunity to change the world!

For example, the Human Genome project would be impossible without the computer systems because of the large collections of data required. However, with Perl, it is possible to store and manipulate such large sets of data.

The paper called “How Perl saved the Human Genome Project” discusses this issue.

Nevertheless, in order to change the world, it is not enough to have an idea! You must implement it!

Textbook definition: A system is a set of interconnected components that have specified behavior observed at the interface with its environment. (This says that a system is made up of little pieces/blocks that are interconnected. A system can be viewed as successful if it satisfies some behavioral specifications. We don’t necessarily care how the system works internally, rather its interface to the environment.)

American Heritage Dictionary definition: A group of interacting, interrelated, or interdependent elements forming a complex whole.

Examples of some systems:

• professors
• animals
• cars
• vending machines
• buildings
• city sewer
• government
• highway systems
• web servers
• laptops
• the Internet
• operating systems

Why is it hard to build a system?

Properties of a system not present in the individual components but only present in the aggregate system.

Examples:

1. The Millennium Bridge: When a lot of people were on the bridge, the bridge started swaying back and forth several feet in each direction. The reason was that the bridge didn’t have enough bracing in the horizontal direction so when the pedestrians stepped to the sides they naturally fell into resonance with the bridge. The more the bridge shook back and forth the more people stepped back and forth and that intensified the bridge’s movement.
2. Hancock Tower: Hancock Tower is a long and narrow building. One problem of the Hancock Building was that its glass window panes would pop out due to pressure differences and the construction of the glass. Also, the building would sway during windy weather, and people in the upper floors would experience motion sickness, so more money was spent designing and installing a damper for the building. It had bracings to protect the tower against the wind blowing to the sides. But, the tower was not resistant against wind blowing to the front of the building. Later on, it was found that the building could topple towards its narrow edges, not just its wide edges, so even more money was spent reinforcing those sides of the building. These were all unexpected results of the original design of the building that could not be predicted just by looking at individual components.

In both of these examples the designers did not take into account the affects of what could happen to the entirety of the system.

Emergent Properties of integers:

Here, we want to keep track of milk prices. Initially, we use integers to represent milk prices.

int price_of_milk_cents = 429;

But what if we want to measure things in fractional cents? We can use real numbers.

double price_of_milk_dollars = 4.29;

The emergent property here is the rounding error problem; the floating point numbers cannot precisely represent numbers of cents because 10 is not a power of 2. For instance:

double one_penny = 0.01;

But if you keep adding one_penny to itself, the answer you get eventually falls short of the expected answer.

Solution: Use decimal floating-point arithmetic where the base is 10 rather than 2. This is supported by hardware where fractions of a decimal can be very important (i.e. a bank).

Small changes propagate to affect the whole system. In other words, there are no “small changes” in a large system

Example: Airbus A380
What should change so that airports can support this larger airplane?

• The terminals should be re-designed to accomodate more passengers because of larger capacities of Airbus planes.
• While Airbus planes need more space to park, the number of planes that the terminals can hold will decline.
• Refueling takes longer time for Airbus planes.
• Fewer airplanes can take off at any given time due to stonger vibrations on the runways.
• Length of the runways should be extended. Heavier planes may take longer time to take off.
• Runways may need to be improved to support more weights since Airbus planes are heavier than regular planes.

When the purpose of making Airbus A380 is to increase the efficiency of trasporting passengers, we see that how propagation of effects by Airbus A380 can affect the whole airport system and contradict the initial goal of flying more passengers.

Not all parts of the system follow the same scaling rules. As the system scales, some parts break!

Examples:

1. 50-foot person cannot exist since the legs cannot support the body weight. The reason is that the strength of the bones is proportional to its cross section area and it scales as a square. But, the weight (volume) that the legs need to support increases as a cube.
2. In a network topology with a switch connected directly to the hosts, when the number of hosts increases, the switch needs to scale. Alternatively we can change to a hierarchical design.

Some goals are incompatible with one another.

Example:
Spam filtering can lead to the following errors:
False positive: Mark real mails as spam.
False negatives: Mark spam as real mail.

One could write a spam filter that marks everything as being real mail. This will result in zero false positives, but it also results in a large number of false negatives. The more aggressive you are at marking mail as spam, the more likely you are to cause false positives. And the more aggressive you are at marking mail as real, the more likely you are to cause false negatives. This introduces a tradeoff between having false positives and false negatives.

Modularity breaks systems into subsystems, or modules, that counter emergent properties and propagation of effects and help us understand tradeoffs and incommensurate scaling.
The basic idea is that if we construct a big system from small systems where each of the small systems are correctly modular, then the big system will not have the above problems and is easier to work with.
A good system will contain modules that have a well defined behavior and interact only at specified interfaces.
The challenge is to achieve good modularity without compromising the system’s performance.

Examples:

The Golden Gate Bridge: Each of the cables of the bridge appears as a big single entity. However, designers of the bridge realized that having big single cables was problematic since if one cable failed the entire bridge would be destroyed. Also, it is almost impossible to produce one big single cable from the factory and transport it to the site. So, instead of having single gigantic cables, the cables of the bridge are each built from 17664 small wires. In that way, the cables are easier to manufacture and are more robust. But still, the interface between the bridge and the cables appears as single thick cables.

Modularity in object oriented programming:

Class Price {
        public:
	    int cents() {return _c;}
	private:
	    int _dollars;
	    int _c;
	    int hundredth_of_c;
};

Here we achieve modularity by making the variables private and writing accessor functions. In the Price class the “_c” variable cannot be accessed directly outside this class.
How is a function modular? A function has some arguments and a return type but the underlying implementation can be arbitrarily changed without changing its interface. Function modularity is the basic modularity in programming.

Operating system abstracts hardware for applications. It provides applications with access to a abstract machine or virtual computer. This virtual computer virtualizes all of the computer's hardware, thereby enabling multiple applications and thus the user to access the hardware in a more performant, robust, neutral, and simple way than programming the hardware directly.
The operating system enables a computer to function properly by providing protection and sharing, that is, preventing applications from breaking the computer and allowing multiple applications to be run at the same time.
An important aspect of the OS/Application interface is that it has system calls. These are a special type of function call provided by the kernel for applications to use.

The most basic modularity in any computer system is the OS/Application interface. If this interface is poorly defined, good applications cannot be written. The history of Operating Systems is the history of improving this interface.

1. Versatility (generality): Versatility loosely concerns the amount of flexibility inherent in a system. A versatile interface can be used in many ways. An interface that makes many assumptions about its use, and that therefore can be used in only one way, is not versatile and is less flexible. Standards definitions provide one example of versatility: any device can implement the publicly-available Ethernet protocol, and then participate in any Ethernet network. Contrast this to a network that only works for one manufacturer's products.
2. Performance: deals with issues that involve how well a system handles a task. How efficient does the operating system use hardware resources? How fast can a computer complete a set of processes? Each of these issues pertains directly to the performance of a system. A good interface will not damage performance.
3. Simplicity: Simplicity corresponds to how easily a system can be accessed or used, whether by a trained technician or an end user.
4. Protection (safe sharing): Protection assures that applications cannot damage hardware or each other.
5. Utilization (sharing): Utilization refers to the amount of resources being used. We get high utilization by running multiple applications concurrently.
6. Robustness (fault tolerance): With robustness, errors do not spread very far. For instance, earlier versions of Linux were not robust since when you unplugged the flash drive before ejecting it, the Operating System hung. Robustness can help to constrain propagation of effects.