Considering operating systems, feature at a time
The study of operating systems can be approached from different sides, dependent first and foremost on the particular goals set for such study. Below we’ll consider a selection of such systems and their families, focusing on particular features that may be important when choosing the best suited system for a particular task, or when a systematic study of the approaches to system internal organization is attempted.
We note that, similar to all the other foundational notions of informatics (such as file, process, etc.), it’s hardly possible to strictly define what an operating system is. The set of ‘operations’ provided to the user or application can vary widely from system to system. In practice, this means that the software developer or the user in their work have to rely on the relevant documentation or, should the question at hand not be covered there, on reading the respective source code (if available.)
We will start with the simpler, less featureful systems (and hence less demanding of the hardware) going then to more complex ones, highlighting selected new features found along the way.
FreeDOS
Free (as in freedom) FreeDOS system appeared as an attempt to recreate application binary interfaces (ABIs) of the earlier proprietary MS-DOS system, after it was announced in that the latter would no longer be sold or developed by its respective proprietor. The system saw its first release in . One of the project’s goals is to provide a platform upon which the vast majority of software developed for MS-DOS could be run unaltered.
The MS-DOS system arose, in turn, as an attempt to recreate on 16-bit platforms based on Intel 8086 (8088) processors the environment similar (including the respective application programming interface, API) to that provided by the immensely popular in the 1970s (and used in embedded solutions until early 2000s) CP/M system. It was expected that a significant fraction of preexisting CP/M applications would be easily ported to the new system.
The FAT filesystem, originally developed for MS-DOS, until recently was virtually the only one widely supported by consumer computing devices (such as audio and video players and recorders) and was standardized as Ecma 107.
FreeDOS currently has mainly educational (owing to its simplicity) and historical value; with the former also facilitated by its ability to run on rather unsophisticated hardware, or a simulation thereof (such as 8086tiny.) It can also be useful for embedded software development, although we do not know of contemporary hardware platforms (aside of FPGA-based ones) capable of running it. Similar considerations also apply to the earlier CP/M system, released as free software in .
Contiki
An operating system for embedded platforms with an emphasis on Internet use. The first edition of the system was developed in ‒. The second (‘next generation’), aimed at somewhat more capable hardware, as of this writing, is still maintained.
As opposed to FreeDOS, this system supports several contemporary hardware architectures, such as ARM and, in the first edition, AVR. Also supported is cooperative multitasking (that is, it requires the application developer to explicitly designate the points in the code where the control will be passed back to scheduler so other ready tasks could be run; or, in absence of such, the processor’s low-power sleep mode could be entered, until the next event wakes it up.)
This system should be of interest to those developing embedded applications, including those designed to interact with the Internet.
NetBSD
NetBSD is a descendant of the proprietary AT&T Research Unix system, the licenses for which were made available at a modest price to educational institutions, leading to its wide adoption there; including its Berkeley Software Distribution (BSD) variant, developed at the time at University of California, Berkeley.
Contrary to the systems described above, NetBSD does not allow user programs to directly access devices or the memory belonging to other programs. This kind of isolation facilitates better reliability: generally, a fatal failure in one program will result in its abnormal termination, but not in some kind of failure for the system as a whole. This, however, also means that there’s ought to be some program that sets up and controls this isolation and, therefore, not constrained by it. In Unix-like systems, this program is called system’s kernel. As a rule, the kernel tends to be rather complex and, despite developers’ best efforts, bugs in it (which, in this case, can result in a failure of the system as a whole) are not insignificantly rare.
A feature of particular interest is the support since version 5.0 () of rump kernel, which, on one hand, allows for kernel components to be built for execution in user space (in other words, as ordinary processes, or components thereof; which is useful for debugging, or alternatively can be used to improve the reliability of the system, even if at some performance cost.) On the other, it allows for an ordinary application to be built to run in kernel space, by turning said application alongside the kernel into a monolithic unikernel system, which may allow for reduced resource usage and improved performance.
Xen
Xen (pronounced /ˈzɛn/) hypervisor isn’t, strictly speaking, an operating system. Nevertheless, its role is somewhat similar to that of an operating system kernel. For instance, Xen prevents several operating systems running in parallel at a given host from accessing memory of one another, as well as from attempting to drive any given device concurrently.
The introduction of Xen () was facilitated by the observation that many then-contemporary systems used no more than two protection rings (with the most privileged ring 0 being used to implement kernel space, and the least privileged one used for user space) out of four provided by Intel 80386 and later. In paravirtualization mode, Xen itself occupies the most privileged ring 0, while the guest kernels need to be modified to run in ring 1. In hardware virtualization mode, the CPU is required to support ‘ring −1’, which is used to run Xen; guest kernels can be ran unmodified in this case. Either way, the (user-space) applications need no modification to run under Xen.
Controlling Xen itself requires sophisticated software, which in turn requires some underlying operating system to run on. Such a system is in this case called the privileged domain, or dom0; as opposed to user domain (domU), used to run ‘guest’ systems. The aforementioned NetBSD can act as dom0 since version 3.0 (.)
GNU/Hurd
The GNU Project for development of a fully free Unix-like operating system, including development tools (compilers, linkers, assemblers, etc.), editors, text processing tools and, in the long run, any other software of interest to the user, was first announced .
By early 1990s, the system largely took shape, yet was lacking a crucial element: a kernel of its own. In other words, the system existed as a set of different software packages which it was possible to run on a variety of existing (non-free) Unix-like systems.
As mentioned above, one of the complex parts of kernel development is that programming mistakes tend to result in system crashes and require the system to be rebooted. The realization of this led to the idea of moving as much code as possible out of kernel space and into user space, where the consequences of such mistakes are considerably easier to contain and mitigate. The resulting microkernel concept requires that kernel space is only used for the code providing basic memory and device management, including possibly some basic set of device drivers.
In , the Mach microkernel development project was started in Carnegie Mellon University, with the 4.2BSD system kernel taken as a starting point. The project concluded with the release of version 3.0 in , which the developers deemed to fully embody the microkernel concept.
The GNU Hurd project of development of a Unix-like kernel on top of the Mach microkernel was announced By kernel in this case is understood a selection of programs that run in unprivileged user space but perform the functions traditionally implemented within kernel space in Unix-like systems.
The development of Mach continued in the University of Utah until version 4. From onward, the microkernel is development as part of the GNU Project (as GNU Mach.)
Specific components of GNU are widely available for different systems (such as NetBSD above) and are both practically important and are of value when studing the internals of systems and their constituent parts. The variant of the GNU system that uses the GNU Hurd kernel atop of the GNU Mach microkernel (and often referred to as GNU/Hurd) is mainly useful for studying existing and researching new approaches to operating system development and operation.
GNU/Linux
Concurrently with the GNU Hurd announcement, saw the first release of the Linux kernel. The development of this kernel, as well as porting of the GNU packages to run on top of it, attracted far more programmers than the GNU Hurd and later GNU Mach projects, resulting in the fast evolution and adoption of systems that made use of both GNU and Linux, and known as GNU/Linux (or, alternatively, GNU + Linux.)
The GNU/Linux family of systems is of considerable practical interest; the system is widely adopted as a ‘server’ platform; it also sees use as a ‘desktop’. The Linux kernel by itself is widespread as the basis for embedded systems; in place of GNU packages simpler alternatives are often used in this case, such as Busybox and the Musl C library. Nevertheless, the considerable internal complexity and the fast pace of development of the Linux kernel severely limit its application in research or educational contexts.
Conclusion
While we’ve covered only a small fraction of the operating systems available today, we believe that the selection given is, to a degree, representative, with systems of historic, model, research and practical interest being listed.
Of the systems mentioned, FreeDOS and CP/M are primarily of historic interest, yet they can also be studied as relatively easy to understand models of system organization. Their use in embedded applications is somewhat constrained by the requirement to use old or custom hardware.
The variants of Contiki are readily suitable for embedding into simpler computing hardware, particularly in the cases where Internet connectivity is desired. It should be noted that the reliability of resulting solutions is often easier to assess when simpler software and hardware are used.
NetBSD and GNU/Hurd are both useful for research purposes. However, NetBSD follows somewhat more traditional approach, and hence harder to make groundbreaking discoveries in system design with. At the same time, studying it may offer more immediate practical benefits.
All the mentioned operating systems are free software with participation in their development open to anyone. That said, considerable internal complexity and the fast pace of development of the Linux kernel may require considerable skill and effort on the part of the prospective developer.
Feedback
The author can be contacted via the #sdf
channel on the irc