Under Construction
Under Construction
John F. Peters, a friend and Unix guru when I was a beginning kernel hacker for Siemens once told me something about operating systems which I will never forget. I remember asking him what could be the most important property of an operating system. I sure thought about message passing, micro-kernal architecture etc. But John said “ The single most important property is transparency. An OS may fail and crash - but with a good one you will be able to figure out the reason for the crash. There is nothing worse than an Operating System that fails without a known reason. ” This quote also nicely explains the differences between business applications and system software: system software needs to crash in an understandable way.
Operating systems are neither brand new nor did too much happen during the last couple of years so that onecould speak of a revolution in design or reliability. This should lead to computer scientists and programmers being well aware of possiblities and limitations of operating systems and how programs should be written to take advantage of them.
But this did not really happen. Instead - we see young programmers skilled in object-oriented computing but totally unaware of performance aspects. Worse, if something happens they seem to be unable to diagnose the problems and find a solution. Automation is used as far as provided by modern IDEs which rarely provide everything used in large projects. GUIs seem to have a disabling effect on many as Neil Stephenson argues in his latest book.
From these considerations we can derive a number of goals for our operating systems class
We want our students to know the major functional components of an OS. Both looking towards hardware support und the system call interface offered to applications. On each level the OS offers a number of abstractions, e.g. processes and threads, pipes and sockets, shared memory and semaphores etc. which can be used by application programmers. But nowadays many programmers work on top of advanced virtual machines which provide their own interfaces. After all an OS is a framework and the device drivers are its plug-ins. The patterns book on concurrency and distributed computing (I believe it's Buschman et.al. gave names to a number of old unix patterns and made them accessible. The top level of an OS is its interface - a concept well known at least to our students which take an advanced Java and OO class at the same time.
Guided by a number of use-cases we would like to show how e.g. an application gets constructed using the c language and its related tools. How the application is started which touches process and rights management, virtual memory, swapping etc.
An operating system and its toolset offers a lot of help in diagnosing and fixing problems. Logging facilities like syslog or the NT envent log let applications write messages to users or administrators. Debuggers allow fine grained stepping through applications and system call tracers like truss (is there a linux or windows equivalent?) give a coarse grainded view on what the application does. On top of these there are system admin tools which let us know about process management (ps), resource use (sar). A good understanding of OS abstractions for interprocess communication helps surely.
How many times do nice OO-projects turn sour because of performance issues? I am not saying that C or assembler are reasonable languages for application development - not even C++ is in my point of view. But at least these languages let you get a glance at how things work under the hood. How expensive heap allocation really is and how it is done. Moving from user space to kernel space and back frequently is expensive. Interprocess communication requires rescheduling in many cases and is also expensive but still much cheaper than e.g. inter-machine communication. And one thing for sure is true: no matter what Moores law says: most OO-programs I have seen in my live (are there any others left?) could run faster. Besides reliability performance still is the number one problem of applications.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution 2.5 License by Walter Kriha.