A kernel connects the application software to the hardware of a computer

In computing, the kernel (from German Kern, nucleus, core^{[citation needed]}) is the main component of most computer operating systems; it is a bridge between applications and the actual data processing done at the hardware level. The kernel's responsibilities include managing the system's resources (the communication between hardware and software components).^[1] Usually as a basic component of an operating system, a kernel can provide the lowest-level abstraction layer for the resources (especially processors and I/O devices) that application software must control to perform its function. It typically makes these facilities available to application processes through inter-process communication mechanisms and system calls.

Operating system tasks are done differently by different kernels, depending on their design and implementation. While monolithic kernels execute all the operating system code in the same address space to increase the performance of the system, microkernels run most of the operating system services in user space as servers, aiming to improve maintainability and modularity of the operating system.^[2] A range of possibilities exists between these two extremes.

Kernel basic facilities[link]

The kernel's primary function is to manage the computer's resources and allow other programs to run and use these resources.^[1] Typically, the resources consist of:

• The Central Processing Unit. This is the most central part of a computer system, responsible for running or executing programs. The kernel takes responsibility for deciding at any time which of the many running programs should be allocated to the processor or processors (each of which can usually run only one program at a time)
• The computer's memory. Memory is used to store both program instructions and data. Typically, both need to be present in memory in order for a program to execute. Often multiple programs will want access to memory, frequently demanding more memory than the computer has available. The kernel is responsible for deciding which memory each process can use, and determining what to do when not enough is available.
• Any Input/Output (I/O) devices present in the computer, such as keyboard, mouse, disk drives, printers, displays, network adapters, etc. The kernel allocates requests from applications to perform I/O to an appropriate device (or subsection of a device, in the case of files on a disk or windows on a display) and provides convenient methods for using the device (typically abstracted to the point where the application does not need to know implementation details of the device).

Key aspects necessary in resource managements are the definition of an execution domain (address space) and the protection mechanism used to mediate the accesses to the resources within a domain.^[1]

Kernels also usually provide methods for synchronization and communication between processes called inter-process communication (IPC).

A kernel may implement these features itself, or rely on some of the processes it runs to provide the facilities to other processes, although in this case it must provide some means of IPC to allow processes to access the facilities provided by each other.

Finally, a kernel must provide running programs with a method to make requests to access these facilities.

Process management[link]

The main task of a kernel is to allow the execution of applications and support them with features such as hardware abstractions. A process defines which memory portions the application can access.^[3] (For this introduction, process, application and program are used as synonyms.) Kernel process management must take into account the hardware built-in equipment for memory protection.^[4]

To run an application, a kernel typically sets up an address space for the application, loads the file containing the application's code into memory (perhaps via demand paging), sets up a stack for the program and branches to a given location inside the program, thus starting its execution.^[5]

Multi-tasking kernels are able to give the user the illusion that the number of processes being run simultaneously on the computer is higher than the maximum number of processes the computer is physically able to run simultaneously. Typically, the number of processes a system may run simultaneously is equal to the number of CPUs installed (however this may not be the case if the processors support simultaneous multithreading).

In a pre-emptive multitasking system, the kernel will give every program a slice of time and switch from process to process so quickly that it will appear to the user as if these processes were being executed simultaneously. The kernel uses scheduling algorithms to determine which process is running next and how much time it will be given. The algorithm chosen may allow for some processes to have higher priority than others. The kernel generally also provides these processes a way to communicate; this is known as inter-process communication (IPC) and the main approaches are shared memory, message passing and remote procedure calls (see concurrent computing).

Other systems (particularly on smaller, less powerful computers) may provide co-operative multitasking, where each process is allowed to run uninterrupted until it makes a special request that tells the kernel it may switch to another process. Such requests are known as "yielding", and typically occur in response to requests for interprocess communication, or for waiting for an event to occur. Older versions of Windows and Mac OS both used co-operative multitasking but switched to pre-emptive schemes as the power of the computers to which they were targeted grew.^[6]

The operating system might also support multiprocessing (SMP or Non-Uniform Memory Access); in that case, different programs and threads may run on different processors. A kernel for such a system must be designed to be re-entrant, meaning that it may safely run two different parts of its code simultaneously. This typically means providing synchronization mechanisms (such as spinlocks) to ensure that no two processors attempt to modify the same data at the same time.

Memory management[link]

The kernel has full access to the system's memory and must allow processes to safely access this memory as they require it. Often the first step in doing this is virtual addressing, usually achieved by paging and/or segmentation. Virtual addressing allows the kernel to make a given physical address appear to be another address, the virtual address. Virtual address spaces may be different for different processes; the memory that one process accesses at a particular (virtual) address may be different memory from what another process accesses at the same address. This allows every program to behave as if it is the only one (apart from the kernel) running and thus prevents applications from crashing each other.^[5]

On many systems, a program's virtual address may refer to data which is not currently in memory. The layer of indirection provided by virtual addressing allows the operating system to use other data stores, like a hard drive, to store what would otherwise have to remain in main memory (RAM). As a result, operating systems can allow programs to use more memory than the system has physically available. When a program needs data which is not currently in RAM, the CPU signals to the kernel that this has happened, and the kernel responds by writing the contents of an inactive memory block to disk (if necessary) and replacing it with the data requested by the program. The program can then be resumed from the point where it was stopped. This scheme is generally known as demand paging.

Virtual addressing also allows creation of virtual partitions of memory in two disjointed areas, one being reserved for the kernel (kernel space) and the other for the applications (user space). The applications are not permitted by the processor to address kernel memory, thus preventing an application from damaging the running kernel. This fundamental partition of memory space has contributed much to current designs of actual general-purpose kernels and is almost universal in such systems, although some research kernels (e.g. Singularity) take other approaches.

Device management[link]

To perform useful functions, processes need access to the peripherals connected to the computer, which are controlled by the kernel through device drivers. A device driver is a computer program that enables the operating system to interact with a hardware device. It provides the operating system with information of how to control and communicate with a certain piece of hardware. The driver is an important and vital piece to a program application. The design goal of a driver is abstraction; the function of the driver is to translate the OS-mandated function calls (programming calls) into device-specific calls. In theory, the device should work correctly with the suitable driver. Device drivers are used for such things as video cards, sound cards, printers, scanners, modems, and LAN cards. The common levels of abstraction of device drivers are:

1. On the hardware side:

• Interfacing directly.
• Using a high level interface (Video BIOS).
• Using a lower-level device driver (file drivers using disk drivers).
• Simulating work with hardware, while doing something entirely different.

2. On the software side:

• Allowing the operating system direct access to hardware resources.
• Implementing only primitives.
• Implementing an interface for non-driver software (Example: TWAIN).
• Implementing a language, sometimes high-level (Example PostScript).

For example, to show the user something on the screen, an application would make a request to the kernel, which would forward the request to its display driver, which is then responsible for actually plotting the character/pixel.^[5]

A kernel must maintain a list of available devices. This list may be known in advance (e.g. on an embedded system where the kernel will be rewritten if the available hardware changes), configured by the user (typical on older PCs and on systems that are not designed for personal use) or detected by the operating system at run time (normally called plug and play). In a plug and play system, a device manager first performs a scan on different hardware buses, such as Peripheral Component Interconnect (PCI) or Universal Serial Bus (USB), to detect installed devices, then searches for the appropriate drivers.

As device management is a very OS-specific topic, these drivers are handled differently by each kind of kernel design, but in every case, the kernel has to provide the I/O to allow drivers to physically access their devices through some port or memory location. Very important decisions have to be made when designing the device management system, as in some designs accesses may involve context switches, making the operation very CPU-intensive and easily causing a significant performance overhead.^{[citation needed]}

System calls[link]

A system call is a mechanism that is used by the application program to request a service from the operating system. They use a machine-code instruction that causes the processor to change mode. An example would be from supervisor mode to protected mode. This is where the operating system performs actions like accessing hardware devices or the memory management unit. Generally the operating system provides a library that sits between the operating system and normal programs. Usually it is a C library such as Glibc or Windows API. The library handles the low-level details of passing information to the kernel and switching to supervisor mode. System calls include close, open, read, wait and write.

To actually perform useful work, a process must be able to access the services provided by the kernel. This is implemented differently by each kernel, but most provide a C library or an API, which in turn invokes the related kernel functions.^[7]

The method of invoking the kernel function varies from kernel to kernel. If memory isolation is in use, it is impossible for a user process to call the kernel directly, because that would be a violation of the processor's access control rules. A few possibilities are:

• Using a software-simulated interrupt. This method is available on most hardware, and is therefore very common.
• Using a call gate. A call gate is a special address stored by the kernel in a list in kernel memory at a location known to the processor. When the processor detects a call to that address, it instead redirects to the target location without causing an access violation. This requires hardware support, but the hardware for it is quite common.
• Using a special system call instruction. This technique requires special hardware support, which common architectures (notably, x86) may lack. System call instructions have been added to recent models of x86 processors, however, and some operating systems for PCs make use of them when available.
• Using a memory-based queue. An application that makes large numbers of requests but does not need to wait for the result of each may add details of requests to an area of memory that the kernel periodically scans to find requests.

Kernel design decisions[link]

Issues of kernel support for protection[link]

An important consideration in the design of a kernel is the support it provides for protection from faults (fault tolerance) and from malicious behaviors (security). These two aspects are usually not clearly distinguished, and the adoption of this distinction in the kernel design leads to the rejection of a hierarchical structure for protection.^[1]

The mechanisms or policies provided by the kernel can be classified according to several criteria, as: static (enforced at compile time) or dynamic (enforced at run time); preemptive or post-detection; according to the protection principles they satisfy (i.e. Denning^[8][9]); whether they are hardware supported or language based; whether they are more an open mechanism or a binding policy; and many more.

Support for hierarchical protection domains^[10] is typically that of "CPU modes." An efficient and simple way to provide hardware support of capabilities is to delegate the MMU the responsibility of checking access-rights for every memory access, a mechanism called capability-based addressing.^[11] Most commercial computer architectures lack MMU support for capabilities. An alternative approach is to simulate capabilities using commonly supported hierarchical domains; in this approach, each protected object must reside in an address space that the application does not have access to; the kernel also maintains a list of capabilities in such memory. When an application needs to access an object protected by a capability, it performs a system call and the kernel performs the access for it. The performance cost of address space switching limits the practicality of this approach in systems with complex interactions between objects, but it is used in current operating systems for objects that are not accessed frequently or which are not expected to perform quickly.^[12][13] Approaches where protection mechanism are not firmware supported but are instead simulated at higher levels (e.g. simulating capabilities by manipulating page tables on hardware that does not have direct support), are possible, but there are performance implications.^[14] Lack of hardware support may not be an issue, however, for systems that choose to use language-based protection.^[15]

An important kernel design decision is the choice of the abstraction levels where the security mechanisms and policies should be implemented. Kernel security mechanisms play a critical role in supporting security at higher levels.^{[11][16][17][18][19]}

One approach is to use firmware and kernel support for fault tolerance (see above), and build the security policy for malicious behavior on top of that (adding features such as cryptography mechanisms where necessary), delegating some responsibility to the compiler. Approaches that delegate enforcement of security policy to the compiler and/or the application level are often called language-based security.

The lack of many critical security mechanisms in current mainstream operating systems impedes the implementation of adequate security policies at the application abstraction level.^[16] In fact, a common misconception in computer security is that any security policy can be implemented in an application regardless of kernel support.^[16]

Hardware-based protection or language-based protection[link]

Typical computer systems today use hardware-enforced rules about what programs are allowed to access what data. The processor monitors the execution and stops a program that violates a rule (e.g., a user process that is about to read or write to kernel memory, and so on). In systems that lack support for capabilities, processes are isolated from each other by using separate address spaces.^[20] Calls from user processes into the kernel are regulated by requiring them to use one of the above-described system call methods.

An alternative approach is to use language-based protection. In a language-based protection system, the kernel will only allow code to execute that has been produced by a trusted language compiler. The language may then be designed such that it is impossible for the programmer to instruct it to do something that will violate a security requirement.^[15]

Advantages of this approach include:

• No need for separate address spaces. Switching between address spaces is a slow operation that causes a great deal of overhead, and a lot of optimization work is currently performed in order to prevent unnecessary switches in current operating systems. Switching is completely unnecessary in a language-based protection system, as all code can safely operate in the same address space.
• Flexibility. Any protection scheme that can be designed to be expressed via a programming language can be implemented using this method. Changes to the protection scheme (e.g. from a hierarchical system to a capability-based one) do not require new hardware.

Disadvantages include:

• Longer application start up time. Applications must be verified when they are started to ensure they have been compiled by the correct compiler, or may need recompiling either from source code or from bytecode.
• Inflexible type systems. On traditional systems, applications frequently perform operations that are not type safe. Such operations cannot be permitted in a language-based protection system, which means that applications may need to be rewritten and may, in some cases, lose performance.

Examples of systems with language-based protection include JX and Microsoft's Singularity.

Process cooperation[link]

Edsger Dijkstra proved that from a logical point of view, atomic lock and unlock operations operating on binary semaphores are sufficient primitives to express any functionality of process cooperation.^[21] However this approach is generally held to be lacking in terms of safety and efficiency, whereas a message passing approach is more flexible.^[22] A number of other approaches (either lower- or higher-level) are available as well, with many modern kernels providing support for systems such as shared memory and remote procedure calls.

I/O devices management[link]

The idea of a kernel where I/O devices are handled uniformly with other processes, as parallel co-operating processes, was first proposed and implemented by Brinch Hansen (although similar ideas were suggested in 1967^[23][24]). In Hansen's description of this, the "common" processes are called internal processes, while the I/O devices are called external processes.^[22]

Similar to physical memory, allowing applications direct access to controller ports and registers can cause the controller to malfunction, or system to crash. With this, depending on the complexity of the device, some devices can get surprisingly complex to program, and use several different controllers. Because of this, providing a more abstract interface to manage the device is important. This interface is normally done by a Device Driver or Hardware Abstraction Layer. Frequently, applications will require access to these devices. The Kernel must maintain the list of these devices by querying the system for them in some way. This can be done through the BIOS, or through one of the various system buses (Such as PCI/PCIE, or USB.) When an application requests an operation on a device (Such as displaying a character), the kernel needs to send this request to the current active video driver. The video driver, in turn, needs to carry out this request. This is an example of Inter Process Communication (IPC).

Kernel-wide design approaches[link]

Naturally, the above listed tasks and features can be provided in many ways that differ from each other in design and implementation.

The principle of separation of mechanism and policy is the substantial difference between the philosophy of micro and monolithic kernels.^[25][26] Here a mechanism is the support that allows the implementation of many different policies, while a policy is a particular "mode of operation". For instance, a mechanism may provide for user log-in attempts to call an authorization server to determine whether access should be granted; a policy may be for the authorization server to request a password and check it against an encrypted password stored in a database. Because the mechanism is generic, the policy could more easily be changed (e.g. by requiring the use of a security token) than if the mechanism and policy were integrated in the same module.

In minimal microkernel just some very basic policies are included,^[26] and its mechanisms allows what is running on top of the kernel (the remaining part of the operating system and the other applications) to decide which policies to adopt (as memory management, high level process scheduling, file system management, etc.).^[1][22] A monolithic kernel instead tends to include many policies, therefore restricting the rest of the system to rely on them.

Per Brinch Hansen presented arguments in favor of separation of mechanism and policy.^[1][22] The failure to properly fulfill this separation, is one of the major causes of the lack of substantial innovation in existing operating systems,^[1] a problem common in computer architecture.^[27][28][29] The monolithic design is induced by the "kernel mode"/"user mode" architectural approach to protection (technically called hierarchical protection domains), which is common in conventional commercial systems;^[30] in fact, every module needing protection is therefore preferably included into the kernel.^[30] This link between monolithic design and "privileged mode" can be reconducted to the key issue of mechanism-policy separation;^[1] in fact the "privileged mode" architectural approach melts together the protection mechanism with the security policies, while the major alternative architectural approach, capability-based addressing, clearly distinguishes between the two, leading naturally to a microkernel design^[1] (see Separation of protection and security).

While monolithic kernels execute all of their code in the same address space (kernel space) microkernels try to run most of their services in user space, aiming to improve maintainability and modularity of the codebase.^[2] Most kernels do not fit exactly into one of these categories, but are rather found in between these two designs. These are called hybrid kernels. More exotic designs such as nanokernels and exokernels are available, but are seldom used for production systems. The Xen hypervisor, for example, is an exokernel.

Monolithic kernels[link]

In a monolithic kernel, all OS services run along with the main kernel thread, thus also residing in the same memory area. This approach provides rich and powerful hardware access. Some developers, such as UNIX developer Ken Thompson, maintain that it is "easier to implement a monolithic kernel"^[31] than microkernels. The main disadvantages of monolithic kernels are the dependencies between system components — a bug in a device driver might crash the entire system — and the fact that large kernels can become very difficult to maintain.

Monolithic kernels, which have traditionally been used by Unix-like operating systems, contain all the operating system core functions and the device drivers (small programs that allow the operating system to interact with hardware devices, such as disk drives, video cards and printers). This is the traditional design of UNIX systems. A monolithic kernel is one single program that contains all of the code necessary to perform every kernel related task. Every part which is to be accessed by most programs which cannot be put in a library is in the kernel space: Device drivers, Scheduler, Memory handling, File systems, Network stacks. Many system calls are provided to applications, to allow them to access all those services. A monolithic kernel, while initially loaded with subsystems that may not be needed can be tuned to a point where it is as fast as or faster than the one that was specifically designed for the hardware, although more in a general sense. Modern monolithic kernels, such as those of Linux and FreeBSD, both of which fall into the category of Unix-like operating systems, feature the ability to load modules at runtime, thereby allowing easy extension of the kernel's capabilities as required, while helping to minimize the amount of code running in kernel space. In the monolithic kernel, some advantages hinge on these points:

• Since there is less software involved it is faster.
• As it is one single piece of software it should be smaller both in source and compiled forms.
• Less code generally means fewer bugs which can translate to fewer security problems.

Most work in the monolithic kernel is done via system calls. These are interfaces, usually kept in a tabular structure, that access some subsystem within the kernel such as disk operations. Essentially calls are made within programs and a checked copy of the request is passed through the system call. Hence, not far to travel at all. The monolithic Linux kernel can be made extremely small not only because of its ability to dynamically load modules but also because of its ease of customization. In fact, there are some versions that are small enough to fit together with a large number of utilities and other programs on a single floppy disk and still provide a fully functional operating system (one of the most popular of which is muLinux). This ability to miniaturize its kernel has also led to a rapid growth in the use of Linux in embedded systems.

These types of kernels consist of the core functions of the operating system and the device drivers with the ability to load modules at runtime. They provide rich and powerful abstractions of the underlying hardware. They provide a small set of simple hardware abstractions and use applications called servers to provide more functionality. This particular approach defines a high-level virtual interface over the hardware, with a set of system calls to implement operating system services such as process management, concurrency and memory management in several modules that run in supervisor mode. This design has several flaws and limitations:

• Coding in kernel can be challenging, in part because you cannot use common libraries (like a full-featured libc), and because you need to use a source-level debugger like gdb). Rebooting the computer is often needed. This is not just a problem of convenience to the developers. When debugging is harder, and as difficulties become stronger, it becomes more likely that code will be "buggier".
• Bugs in one part of the kernel have strong side effects, since every function in the kernel has all the privileges, a bug in one function can corrupt data structure of another, totally unrelated part of the kernel, or of any running program.
• Kernels often become very huge, and difficult to maintain.
• Even if the modules servicing these operations are separate from the whole, the code integration is tight and difficult to do correctly.
• Since the modules run in the same address space, a bug can bring down the entire system.
• The disadvantage cited for monolithic kernels is that they are not portable; that is, they must be rewritten for each new architecture that the operating system is to be used on.

In the microkernel approach, the kernel itself only provides basic functionality that allows the execution of servers, separate programs that assume former kernel functions, such as device drivers, GUI servers, etc.

Microkernels[link]

Microkernel (also abbreviated μK or uK) is the term describing an approach to Operating System design by which the functionality of the system is moved out of the traditional "kernel", into a set of "servers" that communicate through a "minimal" kernel, leaving as little as possible in "system space" and as much as possible in "user space". A microkernel that is designed for a specific platform or device is only ever going to have what it needs to operate. The microkernel approach consists of defining a simple abstraction over the hardware, with a set of primitives or system calls to implement minimal OS services such as memory management, multitasking, and inter-process communication. Other services, including those normally provided by the kernel, such as networking, are implemented in user-space programs, referred to as servers. Microkernels are easier to maintain than monolithic kernels, but the large number of system calls and context switches might slow down the system because they typically generate more overhead than plain function calls.

Only parts which really require being in a privileged mode are in kernel space: IPC (Inter-Process Communication), Basic scheduler, or scheduling primitives, Basic memory handling, Basic I/O primitives. Many critical parts are now running in user space: The complete scheduler, Memory handling, File systems, and Network stacks. Micro kernels were invented as a reaction to traditional "monolithic" kernel design, whereby all system functionality was put in a one static program running in a special "system" mode of the processor. In the microkernel, only the most fundamental of tasks are performed such as being able to access some (not necessarily all) of the hardware, manage memory and coordinate message passing between the processes. Some systems that use micro kernels are QNX and the HURD. In the case of QNX and HURD, user sessions can be entire snapshots of the system itself or views as it is referred to. The very essence of the microkernel architecture illustrates some of its advantages:

• Maintenance is generally easier.
• Patches can be tested in a separate instance, and then swapped in to take over a production instance.
• Rapid development time and new software can be tested without having to reboot the kernel.
• More persistence in general, if one instance goes hay-wire, it is often possible to substitute it with an operational mirror.

Most micro kernels use a message passing system of some sort to handle requests from one server to another. The message passing system generally operates on a port basis with the microkernel. As an example, if a request for more memory is sent, a port is opened with the microkernel and the request sent through. Once within the microkernel, the steps are similar to system calls. The rationale was that it would bring modularity in the system architecture, which would entail a cleaner system, easier to debug or dynamically modify, customizable to users' needs, and more performing. They are part of the operating systems like AIX, BeOS, Hurd, Mach, Mac OS X, MINIX, QNX. Etc. Although micro kernels are very small by themselves, in combination with all their required auxiliary code they are, in fact, often larger than monolithic kernels. Advocates of monolithic kernels also point out that the two-tiered structure of microkernel systems, in which most of the operating system does not interact directly with the hardware, creates a not-insignificant cost in terms of system efficiency. These types of kernels normally provide only the minimal services such as defining memory address spaces, Inter-process communication (IPC) and the process management. The other functions such as running the hardware processes are not handled directly by micro kernels. Proponents of micro kernels point out those monolithic kernels have the disadvantage that an error in the kernel can cause the entire system to crash. However, with a microkernel, if a kernel process crashes, it is still possible to prevent a crash of the system as a whole by merely restarting the service that caused the error. Although this sounds sensible, it is questionable how important it is in reality, because operating systems with monolithic kernels such as Linux have become extremely stable and can run for years without crashing.

Other services provided by the kernel such as networking are implemented in user-space programs referred to as servers. Servers allow the operating system to be modified by simply starting and stopping programs. For a machine without networking support, for instance, the networking server is not started. The task of moving in and out of the kernel to move data between the various applications and servers creates overhead which is detrimental to the efficiency of micro kernels in comparison with monolithic kernels.

Disadvantages in the microkernel exist however. Some are:

• Larger running memory footprint
• More software for interfacing is required, there is a potential for performance loss.
• Messaging bugs can be harder to fix due to the longer trip they have to take versus the one off copy in a monolithic kernel.
• Process management in general can be very complicated.
• The disadvantages for micro kernels are extremely context based. As an example, they work well for small single purpose (and critical) systems because if not many processes need to run, then the complications of process management are effectively mitigated.

A microkernel allows the implementation of the remaining part of the operating system as a normal application program written in a high-level language, and the use of different operating systems on top of the same unchanged kernel.^[22] It is also possible to dynamically switch among operating systems and to have more than one active simultaneously.^[22]

Monolithic kernels vs. microkernels[link]

As the computer kernel grows, a number of problems become evident. One of the most obvious is that the memory footprint increases. This is mitigated to some degree by perfecting the virtual memory system, but not all computer architectures have virtual memory support.^[32] To reduce the kernel's footprint, extensive editing has to be performed to carefully remove unneeded code, which can be very difficult with non-obvious interdependencies between parts of a kernel with millions of lines of code.

By the early 1990s, due to the various shortcomings of monolithic kernels versus microkernels, monolithic kernels were considered obsolete by virtually all operating system researchers. As a result, the design of Linux as a monolithic kernel rather than a microkernel was the topic of a famous debate between Linus Torvalds and Andrew Tanenbaum.^[33] There is merit on both sides of the argument presented in the Tanenbaum–Torvalds debate.

Performances[link]

Monolithic kernels are designed to have all of their code in the same address space (kernel space), which some developers argue is necessary to increase the performance of the system.^[34] Some developers also maintain that monolithic systems are extremely efficient if well-written.^[34] The monolithic model tends to be more efficient^{[citation needed]} through the use of shared kernel memory, rather than the slower IPC system of microkernel designs, which is typically based on message passing.^{[citation needed]}

The performance of microkernels constructed in the 1980s the year in which it started and early 1990s was poor.^[35][36] Studies that empirically measured the performance of these microkernels did not analyze the reasons of such inefficiency.^[35] The explanations of this data were left to "folklore", with the assumption that they were due to the increased frequency of switches from "kernel-mode" to "user-mode",^[35] to the increased frequency of inter-process communication^[35] and to the increased frequency of context switches.^[35]

In fact, as guessed in 1995, the reasons for the poor performance of microkernels might as well have been: (1) an actual inefficiency of the whole microkernel approach, (2) the particular concepts implemented in those microkernels, and (3) the particular implementation of those concepts.^[35] Therefore it remained to be studied if the solution to build an efficient microkernel was, unlike previous attempts, to apply the correct construction techniques.^[35]

On the other end, the hierarchical protection domains architecture that leads to the design of a monolithic kernel^[30] has a significant performance drawback each time there's an interaction between different levels of protection (i.e. when a process has to manipulate a data structure both in 'user mode' and 'supervisor mode'), since this requires message copying by value.^[37]

By the mid-1990s, most researchers had abandoned the belief that careful tuning could reduce this overhead dramatically,^{[citation needed]} but recently, newer microkernels, optimized for performance, such as L4^[38] and K42 have addressed these problems.^{[verification needed]}

The hybrid kernel approach combines the speed and simpler design of a monolithic kernel with the modularity and execution safety of a microkernel.

Hybrid (or) Modular kernels[link]

Hybrid kernels are used in most commercial operating systems such as Microsoft Windows NT, 2000, XP, Vista, and 7. Apple Inc's own Mac OS X uses a hybrid kernel called XNU which is based upon code from Carnegie Mellon's Mach kernel and FreeBSD's monolithic kernel. They are similar to micro kernels, except they include some additional code in kernel-space to increase performance. These kernels represent a compromise that was implemented by some developers before it was demonstrated that pure micro kernels can provide high performance. These types of kernels are extensions of micro kernels with some properties of monolithic kernels. Unlike monolithic kernels, these types of kernels are unable to load modules at runtime on their own. Hybrid kernels are micro kernels that have some "non-essential" code in kernel-space in order for the code to run more quickly than it would were it to be in user-space. Hybrid kernels are a compromise between the monolithic and microkernel designs. This implies running some services (such as the network stack or the filesystem) in kernel space to reduce the performance overhead of a traditional microkernel, but still running kernel code (such as device drivers) as servers in user space.

Many traditionally monolithic kernels are now at least adding (if not actively exploiting) the module capability. The most well known of these kernels is the Linux kernel. The modular kernel essentially can have parts of it that are built into the core kernel binary or binaries that load into memory on demand. It is important to note that a code tainted module has the potential to destabilize a running kernel. Many people become confused on this point when discussing micro kernels. It is possible to write a driver for a microkernel in a completely separate memory space and test it before "going" live. When a kernel module is loaded, it accesses the monolithic portion's memory space by adding to it what it needs, therefore, opening the doorway to possible pollution. A few advantages to the modular (or) Hybrid kernel are:

• Faster development time for drivers that can operate from within modules. No reboot required for testing (provided the kernel is not destabilized).
• On demand capability versus spending time recompiling a whole kernel for things like new drivers or subsystems.
• Faster integration of third party technology (related to development but pertinent unto itself nonetheless).

Modules, generally, communicate with the kernel using a module interface of some sort. The interface is generalized (although particular to a given operating system) so it is not always possible to use modules. Often the device drivers may need more flexibility than the module interface affords. Essentially, it is two system calls and often the safety checks that only have to be done once in the monolithic kernel now may be done twice. Some of the disadvantages of the modular approach are:

• With more interfaces to pass through, the possibility of increased bugs exists (which implies more security holes).
• Maintaining modules can be confusing for some administrators when dealing with problems like symbol differences.

Nanokernels[link]

A nanokernel delegates virtually all services — including even the most basic ones like interrupt controllers or the timer — to device drivers to make the kernel memory requirement even smaller than a traditional microkernel.^[39]

Exokernels[link]

Exokernels are a still experimental approach to operating system design. They differ from the other types of kernels in that their functionality is limited to the protection and multiplexing of the raw hardware, and they provide no hardware abstractions on top of which applications can be constructed. This separation of hardware protection from hardware management enables application developers to determine how to make the most efficient use of the available hardware for each specific program.

Exokernels in themselves are extremely small. However, they are accompanied by library operating systems, which provide application developers with the conventional functionalities of a complete operating system. A major advantage of exokernel-based systems is that they can incorporate multiple library operating systems, each exporting a different API (application programming interface), such as one for Linux and one for Microsoft Windows, thus making it possible to simultaneously run both Linux and Windows applications. They are evolving and still under experimental stage in development of an operating system that could incorporate multiple library operating systems and are intended to simultaneously run multiple operating systems of different kinds like Linux and Microsoft Windows together using appropriate Application Programming Interface (API). They provide minimal abstractions, allowing low-level hardware access.

In exokernel systems, library operating systems provide the abstractions typically present in monolithic kernels. Exokernels, also known vertically structured operating systems, are a new and radical approach to OS design. The idea is to force as very few abstractions possible on developers, enabling them to make as many decisions as possible regarding hardware abstractions. They are limited to protection and multiplexing resources. They enable low-level access to the hardware. The applications and abstractions that require specific memory addresses or disk blocks, the kernel ensures that the request resource is free and the application is allowed to access it. The kernel utilizes library operating systems to provide abstractions. MIT has constructed an exokernel called ExOS. An exokernel is a type of kernel that does not abstract hardware into theoretical models. Instead it allocates physical hardware resources, such as processor time, memory pages, and disk blocks, to different programs. A program running on an exokernel can link to a library operating system that uses the exokernel to simulate the abstractions of a well-known OS, or it can develop application-specific abstractions for better performance.^[40]

History of kernel development[link]

Early operating system kernels[link]

Strictly speaking, an operating system (and thus, a kernel) is not required to run a computer. Programs can be directly loaded and executed on the "bare metal" machine, provided that the authors of those programs are willing to work without any hardware abstraction or operating system support. Most early computers operated this way during the 1950s and early 1960s, which were reset and reloaded between the execution of different programs. Eventually, small ancillary programs such as program loaders and debuggers were left in memory between runs, or loaded from ROM. As these were developed, they formed the basis of what became early operating system kernels. The "bare metal" approach is still used today on some video game consoles and embedded systems,^[41] but in general, newer computers use modern operating systems and kernels.

In 1969 the RC 4000 Multiprogramming System introduced the system design philosophy of a small nucleus "upon which operating systems for different purposes could be built in an orderly manner",^[42] what would be called the microkernel approach.

Time-sharing operating systems[link]

In the decade preceding Unix, computers had grown enormously in power — to the point where computer operators were looking for new ways to get people to use the spare time on their machines. One of the major developments during this era was time-sharing, whereby a number of users would get small slices of computer time, at a rate at which it appeared they were each connected to their own, slower, machine.^[43]

The development of time-sharing systems led to a number of problems. One was that users, particularly at universities where the systems were being developed, seemed to want to hack the system to get more CPU time. For this reason, security and access control became a major focus of the Multics project in 1965.^[44] Another ongoing issue was properly handling computing resources: users spent most of their time staring at the screen and thinking instead of actually using the resources of the computer, and a time-sharing system should give the CPU time to an active user during these periods. Finally, the systems typically offered a memory hierarchy several layers deep, and partitioning this expensive resource led to major developments in virtual memory systems.

Amiga[link]

The Commodore Amiga was released in 1985, and was among the first (and certainly most successful) home computers to feature a hybrid architecture.^{[citation needed]} The Amiga's kernel executive component, exec.library, uses microkernel message passing design but there are other kernel components, like graphics.library, that had a direct access to the hardware. There is no memory protection and the kernel is almost always running in a user mode. Only special actions are executed in kernel mode and user mode applications can ask operating system to execute their code in kernel mode.

Unix[link]

A diagram of the predecessor/successor family relationship for Unix-like systems.

During the design phase of Unix, programmers decided to model every high-level device as a file, because they believed the purpose of computation was data transformation.^[45]

For instance, printers were represented as a "file" at a known location — when data was copied to the file, it printed out. Other systems, to provide a similar functionality, tended to virtualize devices at a lower level — that is, both devices and files would be instances of some lower level concept. Virtualizing the system at the file level allowed users to manipulate the entire system using their existing file management utilities and concepts, dramatically simplifying operation. As an extension of the same paradigm, Unix allows programmers to manipulate files using a series of small programs, using the concept of pipes, which allowed users to complete operations in stages, feeding a file through a chain of single-purpose tools. Although the end result was the same, using smaller programs in this way dramatically increased flexibility as well as ease of development and use, allowing the user to modify their workflow by adding or removing a program from the chain.

In the Unix model, the Operating System consists of two parts; first, the huge collection of utility programs that drive most operations, the other the kernel that runs the programs.^[45] Under Unix, from a programming standpoint, the distinction between the two is fairly thin; the kernel is a program, running in supervisor mode,^[46] that acts as a program loader and supervisor for the small utility programs making up the rest of the system, and to provide locking and I/O services for these programs; beyond that, the kernel didn't intervene at all in user space.

Over the years the computing model changed, and Unix's treatment of everything as a file or byte stream no longer was as universally applicable as it was before. Although a terminal could be treated as a file or a byte stream, which is printed to or read from, the same did not seem to be true for a graphical user interface. Networking posed another problem. Even if network communication can be compared to file access, the low-level packet-oriented architecture dealt with discrete chunks of data and not with whole files. As the capability of computers grew, Unix became increasingly cluttered with code. It is also because the modularity of the Unix kernel is extensively scalable.^[47] While kernels might have had 100,000 lines of code in the seventies and eighties, kernels of modern Unix successors like Linux have more than 13 million lines.^[48]

Modern Unix-derivatives are generally based on module-loading monolithic kernels. Examples of this are the Linux kernel in its many distributions as well as the Berkeley software distribution variant kernels such as FreeBSD, DragonflyBSD, OpenBSD, NetBSD, and Mac OS X. Apart from these alternatives, amateur developers maintain an active operating system development community, populated by self-written hobby kernels which mostly end up sharing many features with Linux, FreeBSD, DragonflyBSD, OpenBSD or NetBSD kernels and/or being compatible with them.^[49]

Mac OS[link]

Apple Computer first launched Mac OS in 1984, bundled with its Apple Macintosh personal computer. Apple moved to a nanokernel design in Mac OS 8.6. Against this, Mac OS X is based on Darwin, which uses a hybrid kernel called XNU, which was created combining the 4.3BSD kernel and the Mach kernel.^[50]

Microsoft Windows[link]

Microsoft Windows was first released in 1985 as an add-on to MS-DOS. Because of its dependence on another operating system, initial releases of Windows, prior to Windows 95, were considered an operating environment (not to be confused with an operating system). This product line continued to evolve through the 1980s and 1990s, culminating with release of the Windows 9x series (upgrading the system's capabilities to 32-bit addressing and pre-emptive multitasking) through the mid 1990s and ending with the release of Windows Me in 2000. Microsoft also developed Windows NT, an operating system intended for high-end and business users. This line started with the release of Windows NT 3.1 in 1993, and has continued through the years of 2000 with Windows 7 and Windows Server 2008.

The release of Windows XP in October 2001 brought these two product lines together, with the intent of combining the stability of the NT kernel with consumer features from the 9x series.^[51] The architecture of Windows NT's kernel is considered a hybrid kernel because the kernel itself contains tasks such as the Window Manager and the IPC Manager, but several subsystems run in user mode.^[52] The precise breakdown of user mode and kernel mode components has changed from release to release, but the introduction of the User Mode Driver Framework in Windows Vista, and user-mode thread scheduling in Windows 7,^[53] have brought more kernel-mode functionality into user-mode processes.

Development of microkernels[link]

Although Mach, developed at Carnegie Mellon University from 1985 to 1994, is the best-known general-purpose microkernel, other microkernels have been developed with more specific aims. The L4 microkernel family (mainly the L3 and the L4 kernel) was created to demonstrate that microkernels are not necessarily slow.^[38] Newer implementations such as Fiasco and Pistachio are able to run Linux next to other L4 processes in separate address spaces.^[54][55]

QNX is a real-time operating system with a minimalistic microkernel design that has been developed since 1982, having been far more successful than Mach in achieving the goals of the microkernel paradigm.^[56] It is principally used in embedded systems and in situations where software is not allowed to fail, such as the robotic arms on the space shuttle and machines that control grinding of glass to extremely fine tolerances, where a tiny mistake may cost hundreds of thousands of dollars.

See also[link]

• Comparison of operating system kernels

Notes[link]

References[link]

Further reading[link]

• Andrew Tanenbaum, Operating Systems – Design and Implementation (Third edition);
• Andrew Tanenbaum, Modern Operating Systems (Second edition);
• Daniel P. Bovet, Marco Cesati, The Linux Kernel;
• David A. Peterson, Nitin Indurkhya, Patterson, Computer Organization and Design, Morgan Koffman (ISBN 1-55860-428-6);
• B.S. Chalk, Computer Organisation and Architecture, Macmillan P.(ISBN 0-333-64551-0).

External links[link]

Wikiversity has learning materials about Kernel Models at Operating Systems/Kernel Models

• Detailed comparison between most popular operating system kernels

Look up kernel in Wiktionary, the free dictionary.

Kernel may refer to:

Business[link]

• Kernel Holding, an agri-business company

Computer science[link]

• Kernel (computing), the central component of most operating systems
  • The Linux kernel, used on many Linux-based operating systems
  • The Windows 9x kernel, used in Windows 95, 98 and ME
  • The Windows NT kernel, used in all Windows NT systems including Windows 2000, XP, Vista and 7
  • XNU, from the Mac OS X operating systems
• Kernel (programming language), a Scheme-like language
• Kernel trick, in machine learning and statistics
• Kernel, a function that executes on OpenCL devices
• Kernel in GPGPU

Literature[link]

• Kernel (Lilo & Stitch), experiment 014 from the Lilo & Stitch cartoon series
• Kernel Fleck, a character in the Demonata series of books

Mathematics[link]

• Kernel (algebra)
• Kernel (category theory)
• Kernel (linear operator)
• Kernel (mathematics)
• Kernel (matrix)
• Kernel (statistics)
• Kernel smoother, a statistical technique
• Convolution kernel, as of a linear filter
• Heat kernel
• Polygon kernel
• Positive definite kernel
• Stochastic kernel
• Kernel of an integral transform
• Kernel of a function
• The kernel in the cooperative game, in game theory

Science[link]

• A seed of some plants
• Palm kernel
• Atomic nucleus

See also[link]

Wikisource has the text of the 1911 Encyclopædia Britannica article kernel.

• KERNAL, Commodore's 8-bit OS software
• Colonel

This disambiguation page lists articles associated with the same title. If an internal link led you here, you may wish to change the link to point directly to the intended article.

Steve Wozniak
Born	Stephan Gary Wozniak (1950-08-11) August 11, 1950 (age 61) San Jose, California, U.S.
Nationality	American
Other names	Woz
Alma mater	University of California, Berkeley
Occupation	Computer scientist Electronics engineer
Net worth	US$100 million (2011)[1]
Spouse	Alice Robertson (m. 1976–1980) «start: (1976)–end+1: (1981)»"Marriage: Alice Robertson to Steve Wozniak" Location: (linkback:http://en-wiki.pop.wn.com/index.php/Steve_Wozniak) Candice Clark (m. 1981–1987) «start: (1981)–end+1: (1988)»"Marriage: Candice Clark to Steve Wozniak" Location: (linkback:http://en-wiki.pop.wn.com/index.php/Steve_Wozniak) Suzanne Mulkern (m. 1990–2004) «start: (1990)–end+1: (2005)»"Marriage: Suzanne Mulkern to Steve Wozniak" Location: (linkback:http://en-wiki.pop.wn.com/index.php/Steve_Wozniak) Janet Hill (m. 2008) «start: (2008)»"Marriage: Janet Hill to Steve Wozniak" Location: (linkback:http://en-wiki.pop.wn.com/index.php/Steve_Wozniak)
Children	3
Website
www.woz.org

Stephan Gary "Woz" Wozniak (born August 11, 1950)^[2] is an American computer engineer and programmer who founded Apple Computer (now Apple Inc.) with Steve Jobs and Ronald Wayne. Wozniak created the Apple I computer and co-created the Apple II computer in the mid-1970s, which contributed significantly to the microcomputer revolution of that era.^[3]

Nicknames[link]

Wozniak has been referred to frequently by the nickname "Woz" or "The Woz”^[4]; "WoZ" (short for "Wheels of Zeus") is also the name of a company Wozniak founded.

Apple Computer[link]

Origins of Apple[link]

Wozniak met Steve Jobs when fellow Homestead High School student, Bill Fernandez, introduced them to each other.^[5] In 1970, they became friends when Jobs worked for the summer at Hewlett-Packard (HP), where Wozniak was working on a mainframe computer.^[6] According to Wozniak's autobiography, iWoz, Jobs had the idea to sell a computer as a fully assembled printed circuit board. Wozniak, at first skeptical, was later convinced by Jobs that even if they were not successful they could at least say to their grandkids they had had their own company. Together they sold some of their possessions (such as Wozniak's HP scientific calculator and Jobs' Volkswagen van), raised USD $1,300, and assembled the first prototypes in Jobs' bedroom and later (when there was no space left) in Jobs' garage. Wozniak's apartment in San Jose was filled with monitors, electronic devices, and some computer games Wozniak had developed.

Excerpt from the Apple I design manual, including Wozniak's hand-drawn diagrams

By 1971, one year after enrolling, Wozniak withdrew from the University of California, Berkeley and developed the computer that eventually made him famous. By himself he designed the hardware, circuit board designs, and operating system for the Apple I.^[7] With the Apple I design, he and Jobs were largely working to impress other members of the Palo Alto-based Homebrew Computer Club, a local group of electronics hobbyists very interested in computing. The Club was one of several key centers which established the home hobbyist era, essentially creating the microcomputer industry over several years. Unlike other Homebrew designs, the Apple had an easy-to-achieve video capability that drew a crowd when it was unveiled.^[7]

On April 1, 1976, Jobs and Wozniak formed Apple Computer. Wozniak quit his job at Hewlett-Packard and became the vice president in charge of research and development at Apple. Their first product, the Apple I computer, was similar to the Altair 8800, the first commercially available microcomputer, except it had no provision for internal expansion cards. With the addition of expansion cards, the Altair could be attached to a computer terminal and could be programmed in BASIC. The Apple I was purely a hobbyist machine, a $25 microprocessor (MOS 6502) on a single-circuit board with 256 bytes of ROM, 4K or 8K bytes of RAM and a 40-character by 24-row display controller. It lacked a case, power supply, keyboard, or display, which had to be provided by the user.

The Apple I was priced at $666.66. (Wozniak later said he had no idea about the relation between the number and the mark of the beast, and "I came up with [it] because I like repeating digits." It was $500 plus a 1/3 markup, which is actually $666.67, rounding up to the nearest penny.) Jobs and Wozniak sold their first 50 system boards to Paul Terrell, who was starting a new computer shop, called the Byte Shop, in Mountain View, California.^[8]

Airplane crash[link]

In February 1981, Wozniak was injured in a private plane crash taking off from the Santa Cruz Sky Park.^[9] The cause of the crash was determined to be premature liftoff.^{[further explanation needed]} He was unable to recall details of the crash and, for many weeks after being released from the hospital, did not realize he had been in a crash at all. He says he wandered around in a haze and did not report to work, thinking every day was a weekend day. He did not remember one day to the next, and needed to be told how to get to places familiar to him. After questioning his wife,^{[citation needed]} he finally began to figure out what had happened, after which his memory began operating correctly again.

Employment with Apple[link]

Steve Wozniak in 1983

Wozniak did not immediately return to Apple after having recovered from the crash. Instead, he married Candice Clark and returned to UC Berkeley under the name "Rocky Clark" (Rocky Raccoon was his dog's name and Clark his wife's maiden name), finally earning his undergraduate degree in electrical engineering & computer sciences (EECS) in 1986.^[10] In May 1982 and 1983, Wozniak also sponsored two US Festivals to celebrate evolving technologies; they ended up as a technology exposition and a rock festival as a combination of music, computers, television and people.

In 1983 he returned to Apple product development, desiring no more of a role than that of an engineer and a motivational factor for the Apple workforce.^[8]

Wozniak permanently ended his full-time employment with Apple on February 6, 1987, 12 years after having created the company. He still remains an employee and receives a small token paycheck, est. to be roughly 120k per year.^[8][11][12] He is also an Apple shareholder.^[13] He also maintained connections with Steve Jobs until Jobs' death in October 2011,^[14] although in 2006 Wozniak stated that he and Jobs were not close friends.^[15]

Post-Apple career[link]

Wozniak founded a new venture called CL 9, which developed and brought the first programmable universal remote control to market in 1987.^[8] He says he "did a degree under an assumed name — Rocky Racoon Clark".^[16] Wozniak also taught fifth-grade students.

In 2001, Wozniak founded Wheels of Zeus (WoZ), to create wireless GPS technology to "help everyday people find everyday things. much easily" In 2002, he joined the Board of Directors of Ripcord Networks, Inc., joining Ellen Hancock, Gil Amelio, Mike Connor, and Wheels of Zeus co-founder Alex Fielding, all Apple alumni, in a new telecommunications venture. Later the same year he joined the Board of Directors of Danger, Inc., the maker of the Hip Top (a.k.a. Side Kick from T-Mobile).

In 2006, Wheels of Zeus was closed, and Wozniak founded Acquicor Technology, a holding company for acquiring technology companies and developing them, with Apple alumni Ellen Hancock and Gil Amelio.

In September 2006, Wozniak published his autobiography, iWoz: From Computer Geek to Cult Icon: How I Invented the Personal Computer, Co-Founded Apple, and Had Fun Doing It. It was co-authored by writer Gina Smith.

In March 2006, Wozniak attended the FIRST National Competition in Atlanta to show off Lego robots.^[17] In 2010, he attended another FIRST event, a regional event in downtown Phoenix Arizona at the Arizona State Fairgrounds. In 2012, he attended and was a judge at another FIRST event, the FRC Las Vegas Regional.

In February 2009, Steve Wozniak joined Fusion-io, a data storage and server company, in Salt Lake City, Utah as their chief scientist.^[18]

On November 18, 2010, Steve Wozniak gave a speech at the Science & Technology Summit at the World Forum Convention Center in The Hague in which he predicted that Android would be dominant over the iPhone market-wise but the iPhone would retain the quality edge.^[19]

On June 9, 2011, Wozniak joined members of Fusion-io’s management team to celebrate the company’s first day of trading on the NYSE by ringing The Opening Bell.^[20]

On October 20, 2011, Wozniak delivered a keynote presentation entitled "Today’s Science Fiction, Tomorrow’s Science Fact" at IP EXPO, a Computer expo which takes place at Earls Court Exhibition Centre in London.^[21]

On November 14, 2011, Steve Wozniak was the keynote speaker at "Rutgers Entrepreneurship Day" at Rutgers University in New Brunswick, New Jersey.^[22]

Philanthropy[link]

Joey Slotnick, left, poses with Steve Wozniak. Slotnick portrayed Wozniak in the film Pirates of Silicon Valley.

Since leaving Apple, Wozniak has provided all the money, as well as a good amount of on-site technical support, for the technology program in his local school district.^[8] Un.U.Son. (Unite Us In Song), an organization Wozniak formed to organize the two US Festivals, is now primarily tasked with supporting his educational and philanthropic projects.^[8] In 1986, Wozniak lent his name to the Stephen G. Wozniak Achievement Awards (referred to as Wozzie Awards), which he presented to six Bay Area high school and college students for their innovative use of computers in the fields of business, art and music.

Honors and awards[link]

In 1979, Wozniak was awarded the ACM Grace Murray Hopper Award. In 1985, Wozniak received the National Medal of Technology (with Steve Jobs) from US President Ronald Reagan.^[8] In December 1989, he received an honorary Doctor of Engineering degree from the University of Colorado at Boulder, where he studied in the late sixties.^[23] Later he donated funds to create the "Woz Lab" at the University of Colorado at Boulder. In 1997, he was named a Fellow of the Computer History Museum. Wozniak was a key contributor and benefactor to the Children's Discovery Museum of San Jose; the street in front of the museum has been renamed Woz Way in his honor.^[24]

In September 2000, Wozniak was inducted into the National Inventors Hall of Fame,^[25] and in 2001 he was awarded the 7th Annual Heinz Award for Technology, the Economy and Employment.^[26] The American Humanist Association awarded him the Isaac Asimov Science Award in 2011.

In December 2005, Wozniak was awarded an honorary Doctor of Engineering degree from Kettering University.^[27] He also received honorary degrees from North Carolina State University and Nova Southeastern University, and the Telluride Tech Festival Award of Technology. In May 2011, Wozniak received an honorary Doctor of Engineering degree from Michigan State University.^[28]

He was awarded the Global Award of the President of Armenia for Outstanding Contribution to Humanity Through IT in 2011.^[29]

Steve Wozniak's Honorary Doctor of Engineering degrees[link]

• University of Colorado at Boulder — 1989
• Kettering University — 2005
• North Carolina State University — 2005
• Nova Southeastern University — 2005
• ESPOL University in Ecuador — 2008
• Michigan State University — 2011
• Concordia University in Montreal Canada — June 22, 2011
• State Engineering University of Armenia — November 11, 2011

Patents[link]

Wozniak is listed as the sole inventor on the following patents:

• US Patent No. 4,136,359 — "Microcomputer for use with video display"^[30] — for which he was inducted into the National Inventors Hall of Fame.
• US Patent No. 4,210,959 — "Controller for magnetic disc, recorder, or the like"^[31]
• US Patent No. 4,217,604 — "Apparatus for digitally controlling PAL color display"^[32]
• US Patent No. 4,278,972 — "Digitally-controlled color signal generation means for use with display"^[33]

Television appearances[link]

After seeing her stand-up performance in Saratoga, California, Wozniak began dating comedian Kathy Griffin.^[34] Together, they attended the 2007 Emmy Awards,^[35] and he subsequently made many appearances on the fourth season of her show Kathy Griffin: My Life on the D-List. Woz is on the show as her date for the Producers Guild of America award show. However, on a June 19, 2008 appearance on The Howard Stern Show, Griffin confirmed that they were no longer dating and decided to remain friends.^[36]

Wozniak portrays a parody of himself in the first episode of the television series Code Monkeys; he plays the owner of Gameavision before selling it to help fund Apple. He later appears again in the twelfth episode when he is in Las Vegas at the annual Video Game Convention and sees Dave and Jerry. He also appears in a parody of the "Get a Mac" ads featured in the final episode of Code Monkeys' second season. Wozniak is also interviewed and featured in the documentary Hackers Wanted and on BBC.

Wozniak competed on Season 8 of Dancing with the Stars in 2009^[37][38] where he danced with Karina Smirnoff. Despite Wozniak and Smirnoff receiving 10 combined points from the three judges out of 30, the lowest score of the evening, he remained in the competition. He later posted on a social networking site that he felt that the vote count was not legitimate and suggested that the Dancing with the Stars judges had lied about the vote count to keep him on the show.^[39] After being briefed on the method of judging and vote counting, he retracted and apologized for his statements.^[40] Despite suffering a pulled hamstring and a fracture in his foot, Wozniak continued to compete,^[41] but was eliminated from the competition on March 31, with a score of 12 out of 30 for an Argentine Tango.^[42]

On September 30, 2010, he appeared as himself on The Big Bang Theory Season 4 Episode 2 Titled "The Cruciferous Vegetable Amplification". While dining in The Cheesecake Factory where Penny works and is approached by a robot Sheldon, Leonard tries to explain to Penny who Steve is, but she says she knows him from Dancing with the Stars.

Steve Wozniak signs a Modbook for a fan during an appearance at the Axiotron booth during Macworld Expo 2009.

Personal life[link]

Wozniak's father is Polish^[43] and his mother is German, though Wozniak has said that "Either family might have come from the other country, or near the border."^[44] Family immigrated to the USA, where Steve was born. Wozniak lives in Los Gatos, California.

He is a member of a Segway Polo team, the Silicon Valley Aftershocks. In 2006, they were challenged to a game by the newly formed New Zealand Pole Blacks (the Woz Challenge Cup); the match ended in a 2-2 tie, with the Woz Challenge Cup staying in Auckland. In 2007, the Silicon Valley Aftershocks avenged the tie by defeating the Pole Blacks 5-0 in the Woz Challenge Cup finals. The 2008 Woz Challenge Cup was held at the SegwayFesT 2008 in Indianapolis, Indiana, on August 8–10, 2008 (polo events ran August 7–9).^[45] Sept 30 through October 2, 2011, Woz played Segway Polo in the Zurich Cup in Berchtesgaden, Germany. He played for the Funky Move Turtles team which placed 7th in the tournament.

His favorite video game is Tetris.^[46] In the 1990s he submitted so many high scores for the game to Nintendo Power that they would no longer print his scores, so he started sending them in under the alphabetically reversed "Evets Kainzow".^{[citation needed]}

He is also a member of the Freemasons. Wozniak describes his impetus for joining the Freemasons as being able to spend more time with his wife at the time, Alice. Alice belonged to the Order of the Eastern Star, associated with the Masons. Wozniak has said that he quickly rose to a third degree Freemason because, whatever he does, he tries to do well. He was initiated in 1979 at Charity Lodge No. 362 in Campbell, California, now part of Mt. Moriah Lodge No. 292 in Los Gatos, California.^[47]

He is married to Janet Hill.^[48] According to his ex-girlfriend Kathy Griffin, “He met someone very quickly and then they [got] engaged. I have had dinner with them, and she’s a thousand times more appropriate!”^[49]

See also[link]

• Blue box
• iWoz — an autobiography
• Pirates of Silicon Valley — A movie based on the rise of Apple and Microsoft; Wozniak is portrayed by actor Joey Slotnick.
• Triumph of the Nerds — A documentary about the rise of the PC industry by Robert X. Cringely.
• Breakout

References[link]

External links[link]

This article's use of external links may not follow Wikipedia's policies or guidelines. Please improve this article by removing excessive or inappropriate external links, and converting useful links where appropriate into footnote references. (October 2011)

Wikimedia Commons has media related to: Steve Wozniak

Wikiquote has a collection of quotations related to: Steve Wozniak

• woz.org Wozniak's official site
• "Apple Computer The Early Days A Personal Perspective" by Paul Laughton
• How I Invented the Personal Computer discussion with Chris Kelley and Vintage Foster at Book Passage, September 2006
• Creativity in the 21st Century conversation at the Discovery Forum 2010 at Bay Area Discovery Museum, February 2010
• Interview with Steve Wozniak by Jessica Livingston

Videos[link]

• In Search of the Valley A 2006 documentary on Silicon Valley featuring Steve Wozniak
• iWoz: From Computer Geek to Culture Icon: How I Invented the Personal Computer, Co-Founded Apple, and Had Fun Doing It
• Steve Wozniak interview on iWoz Book An hour long video interview by Guy Kawasaki, November, 2006^{[dead link]}
• Steve Wozniak interviewed by Charlie Rose January 29, 2007