Follow this link for the course website
There are 4 labs which worth 1/12 each. Labs can be done in teams of 2.
Breakdown of topics (tentative):
There are 2 minilabs which are worth 1/15 each. Minilabs are to be done individually.
Breakdown of topics (tentative):
There will be 1 design problem, which requires a written report, to be done in teams of 2.
There is one 2-4 page paper on a contemporary operating system topic
Scribe notes are to be done in groups of up to 4 students. They are due one week after the lecture.
The definition of the word "system" (and later the phrase "operating system") has been rather vague since it first appeared. The following section consists of a few definitions from various sources with what insight we may glean from the definitions therein.
derived from the Greek "sýstēma" - organized whole, government, constitution, a body of people or animals, a musical interval
root: "set up with"
A set of interconnected components that has a specified behavior observed at the interface of its environment
Software designed to control hardware of a specific data processing system in order to allow users and application programs to make use of it.
Master control program in a computer
Collection of smaller programs and software that is used to control and operate the computer system
So what have we learned from these definitions? Well, according to the non-professionals (the English scholars), the professionals (Microsoft), and the unwashed public (Wikipedia), operating systems all have to do with control. Furthermore, we realize that the American Heritage Dictionary is a bit outdated because it has the phrase "specific data processing system" whereas nowadays systems are quite portable. The Wikipedia page slips up by using the word "operate" in the definition of "operating system". Lastly, there are some major issues in operating systems that these definitions do not address.
Let us examine a simple command-line interaction . We typed the following commands into a console of circa 2008 hardware.
$ ls -l big
-rw-rw-r--1 eggert faculty 9223372036854775000 Oct 6 11:31 big
$ grep x big
$ time grep x big
real 0m0.009s
As we can see from the second line, the file, big, is 9223372036854775000 bytes big. However, estimating from the output of time on the fifth line, the grep command read the file at a speed of 1022 bits/seconds. This speed is virtually impossible to achieve if we actually process every byte.
So what happened here? First, when we created the file big, the command we used was
$truncate 9223372036854775000 big
As seen from its manual page, truncate "truncate or extend a file to a specified length". So when we typed the above command, the file big with 9223372036854775000 of nullbytes was created. The key here, however, is that truncate did not actually create a file of that size. Instead, because it was an intensional file, the system interepreted a reminder that the file had 9223372036854775000 of nullbyes.
When we ran the grep command, grep first consulted the file type before interpreting it appropriately. It realized that this file only contained nullbytes, so it just returned false immediately, without actually looking through 9223372036854775000 bytes of data.
According to What If?, the bandwidth of Internet is about 167 Tb/s, or ~1011 bits/seconds. If we use all the freight trucks in United States to transfer SD cards us (which by the way will cost $1.2 million/gallon), we can achieve about 0.52 zettabit persecond (zetta = 1021)
In development, as project get larger often times not everything scales at the same rate. There are two primary categories of changes that this can cause: economies of scale (coined by Adam Smith) and likewise diseconomies of scale.
Economies of scale describe components that have a decrease in cost per unit as a system grows. A blacksmith with a grindstone creates pins more efficiently than having every member of the general populace dedicated to production, especially as the size of the populace increases. Economies of scale can cause waste.
On the other side of the coin, diseconomies of scale are components that have an increase in cost per unit as a system grows. While a star network is viable for few hosts, for several hundred hosts the interconnections become horribly inefficient. Diseconomies of scale can break a growing system.
Sometimes properties undetected in the early, small versions of a system may emerge as the system grows in size. Indeed, an unexpected emergent property may have been present but unnoticed in early verisons of the system. For example, when civil engineers constructed the Tacoma Narrows bridge they did so with consideration to the strongest possible gusts of wind. However, because of the unprecedented length of the bridge, resonance frequency, a previously negligible factor, became a huge problem. The gusts of wind triggered the resonance frequency of the bridge and it collapsed. It was a valuable and costly lesson on the importance of accounting for emergent properties.
This term describes the phenomenon in which a seemingly local change or failure can have a profound impact on some other part of the system. For example, a tree falling on a power line in Oregon may knock out the power of a building in a completely different state, thousands of miles away.
The pathways for progagation are more "effective" in a digital system, where a single component change can be very profound.
For example, if we had a system that contained an international characters component as well as a file system component, we could have a feature in the international characters that breaks the file system. How? Well, the encoding of Japanese characters could be in Shift-JIS, where the first byte is all 1's and the second byte could be anything. If we allow the second byte to be anything, then it could be the ASCII '\', and hence trying to rename a file in the file system to a Japanese character could cause it to break the title into subdirectories and look at a wrong or nonexistent location.
One possible solution would be to use UTF-8 encodings. This has its own upsides and downsides, as we will discuss next.
Trade offs can be summarized by the Waterbed Effect; if we have a water bed and we apply downward pressure to a part of it, certainly another part will suddenly spring upwards. The water must be sent somewhere else. Systems design always considers trade offs.
If we used the UTF-8 coding instead of the shift-JIS coding, we would avoid the backslash error but would in turn have to represent Japanese characters with 3 bytes instead of 2.
If we added additional security measures to keep grading information at UCLA more secure, we would have to consider other factors like maintenance costs or cranky faculty. The added benefit, of course, would be the security.