UNIX and UNIX Variants
When UNIX was first being developed, some people at Bell Labs had contacts in the university system, and word of the V4 and later V6 UNIX OS began to spread, along with copies of the source code. Chief among the schools that began using it was University of California, Berkeley (UCB). In 1979, Bell Labs created its UNIX Support Group (USG), which later spun off as UNIX System Laboratories (USL) . USL began supplying source code to a number of UNIX vendors, such as Sun, Digital Equipment, etc. Eventually, this source code evolved into the System III UNIX kernel in 1982. All this was copyright AT&T, including the name UNIX; as a result, the Berkeley BSD (Berkeley Software Distribution) code began to diverge from the commercial AT&T code. In 1983-1984, AT&T/Bell Labs went through the breakup and System V Release 2 was released in 1984. System V has been licensed by many commercial UNIX companies for use on their proprietary hardware. Some of these are Sun, with the Solaris Sparc version, IBM with System/370 and AIX on RS/6000, and DEC with OSF on its Alpha line. The most current version is System V Release 4, shortly written as SVR4. Today, all major UNIX vendors use SVR4 with the exception of HP/UX, which as a distant BSD base.
At Berkeley, in 1980, BSD passed under control of the Computing Science Research Group (CSRG), which applied the Berkeley copyright to all the kernel source and many of its utilities, such as Sendmail. In 1981, they released 4.1BSD. From 1982 to 1994, University of California, Berkeley (UCB) made many changes to the Berkeley Software Distribution software - BSD 4.2 was released in 1983, BSD 4.3 was released in 1986. By 1989, UCB released Net/1, which consisted mostly of the networking code (TCP/IP) written in UCB. This code became the basis of a number of commercial versions as well, such as SunOS and HP/UX.
In 1990, some in the CSRG decided to release a version of BSD with all USL code removed. At the 1990 UK UNIX users group conference, Chris Torek (one of the BSD fathers) referred to this project as "detoxification". In May of 1991, a number of Berkeley CSRG's key people left to found BSDi, with the purpose of selling a 80386 port of BSD UNIX. A month later, UCB/CSRG released Net/2 (BSD 4.4), which was the result of the detoxification project begun the previous year. Net/2 wasn't a complete, working BSD UNIX operating system; at the time, UCB was merely interested in getting out a new version of BSD that did not contain any proprietary USL code.
In July 1992, AT&T/USL dragged the Regents of the University of California (UCB) into the suit, adding breach of contract and misappropriation of trade secrets to the complaints. This was because BSDi argued that UCB made the source code available with AT&T's approval. The suit was finally settled in 1994, UCB agreed to modify the BSD 4.4 sources by removing certain kernel files (mainly dealing with the scheduler and virtual memory). This new distribution was to be labeled BSD 4.4-Lite. In addition, USL was prohibited from suing anyone using BSD 4.4-Lite as a a basis for a commercial OS. BSDi's agreement with USL was confidential, although, as in cases of this type, it very probably required them to license modifications they had made back to USL. One of the more damaging things to happen to the commercial UNIX community was when AT&T finally sold USL to Novell in 1992. This was the beginning of the end for USL; ultimately Novell as a corporation could not make the transition into the UNIX realm and it sold its UNIXware to SCO a number of years later. USL ended up in pieces spread around between various other major UNIX vendors, including Sun.
The rise of multiprocessor UNIX servers had caused Symmetric Multiprocessing (SMP) support to be added to System V, and UNIX vendors were starting to turn away from the BSD source because, at that time, it didn't have SMP. UCB became uncomfortable with the idea of carrying on the responsibility for maintaining control over what had turned into a commercial source for code. Because UCB seemed to be less and less interested in maintaining the BSD sources as time passed, a number of people communicating via the Internet began to discuss the possibility of an open port of the BSD 4.4 source to the Intel 80386. December 1991, there was a crude alpha-quality port of the BSD to 80386 that filled in the missing USL code - created by William Jolitz - and a beta version became available in early 1992. After the release of 386BSD, Bill Jolitz trademarked the 386BSD name to block BSDi from appropriating the name. At that time, the first serious split occurred in the BSD community when the NetBSD group separated from the 386BSD project. NetBSD wished to decouple BSD from the Intel 80386.
Many community members tried working with Bill to get the 0.2 release accelerated, but no release was forthcoming. Eventually, they gave up waiting for him and went forward with the next 386BSD release. Since the 386BSD name was trademarked, thus the FreeBSD name was coined and FreeBSD 1.0 was released in 1993. In January of 1995, FreeBSD 2.0 was released based on the unencumbered BSD-Lite release that came out in 1994. One notable addition to 2.2.X was Divert Sockets, which permitted NATs and firewalls to be built using FreeBSD. By November 1998, FreeBSD 3.0 was released. The production kernel 4.0 was shipped in March 2000. Major improvements over 2.2.X are the addition of SMP, better PPP dialup connectivity allowing IP dial-on-demand, and significant changes to the Adaptec 2940/3940 PCI SCSI card drivers.
BSD-Lite did not contain enough of a kernel to boot it out of the box. In 1995, 4.4 BSD-Lite version 2 was released by CSRG, which subsequently disbanded. Today most active BSD development had left UCB and was now being done within the NetBSD, FreeBSD, BSDi, and later OpenBSD groups.
Update soon ...
| Linux kernel is monolithic | Most commercial UNIX variants are monolitihic except Carnegie-Mellon's Mach 3.0 |
| Linux supports modules | Among the main commercial UNIX variants, only the SVR4.2 kernel has a similar feature. Most modern kernels can dynamically load and unload modules - some portions of the kernel code (typically, device drivers). |
| Linux kernel threats cannot execute user programs - they do not represent the basic execution context abstraction | Some modern UNIX kernels, like Solaris 2.x and SVR4.2/MP, are organized as a set of kernel threats |
| Linux defines its own version of lightweight processes (LWP), which is different from the types used on other systems such as SVR4 and Solaris. Linux regards lightweight processes as the basic execution context and handles them via the nonstandard clone() system call. | While all the commercial UNIX variants of LWP are based on kernel threats. A multithreated user application could be composed of many LWPs, or processes that can operate on a common address space, common physical memory pages, common opened files, and so on. |
| Linux is a nonpreemptive kernel | Currently, only Solaris 2.x and Mach 3.x are fully preemptive kernels. SVR4.2/MP introduced some fixed preemption points as a method to get limited preemption capability |
| Linux does not make optimal use of SMP. Several kernel activities that could be executed concurrently - like filesystem handling and networking - executed sequentially. | |
| Linux's standard filesystem lacks some advanced features, such as journaling. Thanks to a powerful object-oriented Virtual File System technology inspired by Solaris and SVR4, porting a foreign filesystem to Linux is relatively easy. | |
| Linux has no analog to the STREAMS I/O subsystem introduced in SVR4. STREAM has become the perferred interface for writing device drivers, terminal drivers, and network protocols. |
| Most UNIX kernels are monolithic: each kernel layer is integrated into the whole kernel program and runs in Kernel Mode on behalf of the current process. | In contrast, microkernel operating systems demand a very small set of functions from the kernel, generall including a few synchronization primitives, a simple scheduler, and an interprocess communciation mechanism. The core is a collection of OS-neutral abstractions (tasks, threads, ...). Several system processes on top of the microkernel implement other operating system-layer functions, like memory allocators, device drivers, system call handlers, and so on. |
| Modules in Linux achieves many of the theoretical advantages of mk without introducing performance penalities. The object code of modules usually consists of a set of functions that implements a filesystem, a device driver, or other features at the kernel's upper layer. It does not run as a specific process. Instead, it is executed in Kernel Mode on behalf of the current process, like any other statically linked kernel function. | All hardware-dependent components are generally encapsulated in the mk code. Therefore, mk os can be fairly easily ported to other architectures. Finally, mk os tend to make better use of RAM than monolithic ones, since system processes that aren't implementing needed functionalities might be swapped out or destoryed. |
OSF Microkernel
Update soon ...