Slashdot Mirror

• AIX is dying.
• AmigaOS is dying.
• BSD is dying.
• BeOS is dying.
• CPM is dying.
• DOS is dying.
• FreeBSD is dying.
• GNU Hurd is dying.
• HP-UX is dying.
• IRIX is dying.
• Inferno is dying.
• Linux is dying.
• LynxOS is dying.
• MINIX is dying.
• MacOS is dying.
• Mach is dying.
• MicroC/OS is dying.
• NachOS is dying.
• NeXT is dying.
• Nemesis is dying.
• NetBSD is dying.
• NetWare is dying.
• OS-400 is dying.
• OS-9 is dying.
• OS/2 is dying.
• Oberon is dying.
• OpenBSD is dying.
• Palm OS is dying.
• Plan 9 is dying.
• pSOS is dying.
• QNX is dying.
• RTEMS is dying.
• SCO is dying.
• Solaris is dying.
• SunOS is dying.
• TRON is dying.
• ThreadX is dying.
• TinyOS is dying.
• Unix is dying.
• VMS is dying.
• VxWorks is dying.
• Windows 2000 is dying.
• Windows 3.11 is dying.
• Windows 95 is dying.
• Windows 98 is dying.
• Windows CE is dying.
• Windows ME is dying.
• Windows NT is dying.
• Windows XP is dying.

The operating system loader, BIOS, or other firmware required at boot time or when installing the operating system would generally not be considered part of the operating system, though this distinction is unclear in the case of a rommable operating system such as RISC OS. The facilities an operating system provides and its general design philosophy exert an extremely strong influence on programming style and on the technical cultures that grow up around the machines on which it runs.

The comp.os.research FAQ makes the following distinction between micro- and macrokernels:
"A recurrent topic of discussion in this newsgroup has been the comparison between microkernel (for example Mach and QNX) and `macrokernel' (traditional Unix) operating systems. The basic notion of a microkernel consists of devolving as much functionality as possible into processes rather than the kernel itself; different systems take different approaches to implementing this.

For example, some systems (such as Mach) leave device drivers in the kernel, and place higher-level services (such as file systems) outside; others (such as QNX) move device drivers outside of the kernel.

However, anecdotal evidence [93-03-03-07-56.52] suggests that the distinction between microkernel and monolithic architectures is becoming more blurred as time goes on, as the two advance. For example, most modern monolithic kernels now implement multiple threads of execution and fine-grained parallelism. Architecturally, this approach begins to appear similar to a microkernel with several kernel-space processes working from shared memory.

As an aside, people often complain that the Mach system can't be a `real' microkernel, because it is so large (at least, this is the argument most frequently cited). However, I have been told that automatically-generated code stubs contribute very significantly to the size of the kernel, and that some size reduction would be likely if MIG (the stub generator) produced better code. [Can someone from CMU comment on this?] As mentioned above, the leaving of device drivers in the kernel also contributes to Mach's size.

Debating microkernels versus monolithic kernels on the basis of kernel size misses the central, architectural point. In the same way as the point of a RISC processor is not to minimise the instruction count, but rather to make a different tradeoff between what is implemented in the processor instruction set and what is implemented in other ways, the microkernel architectural issue is to determine which services are implemented in the microkernel, and which services are implemented external to that microkernel. By making appropriate choices here, the goal is to enhance various OS attributes in a manner that might not be addressable with a monolithic kernel OS. System attributes such as performance, flexibility, realtime, etc. are all variables which are taken into account.

• AIX is dying.
• AmigaOS is dying.
• BSD is dying.
• BeOS is dying.
• CPM is dying.
• DOS is dying.
• FreeBSD is dying.
• GNU Hurd is dying.
• HP-UX is dying.
• IRIX is dying.
• Inferno is dying.
• Linux is dying.
• LynxOS is dying.
• MINIX is dying.
• MacOS is dying.
• Mach is dying.
• MicroC/OS is dying.
• NachOS is dying.
• NeXT is dying.
• Nemesis is dying.
• NetBSD is dying.
• NetWare is dying.
• OS-400 is dying.
• OS-9 is dying.
• OS/2 is dying.
• Oberon is dying.
• OpenBSD is dying.
• Palm OS is dying.
• Plan 9 is dying.
• pSOS is dying.
• QNX is dying.
• RTEMS is dying.
• SCO is dying.
• Solaris is dying.
• SunOS is dying.
• TRON is dying.
• ThreadX is dying.
• TinyOS is dying.
• Unix is dying.
• VMS is dying.
• VxWorks is dying.
• Windows 2000 is dying.
• Windows 3.11 is dying.
• Windows 95 is dying.
• Windows 98 is dying.
• Windows CE is dying.
• Windows ME is dying.
• Windows NT is dying.
• Windows XP is dying.

The operating system loader, BIOS, or other firmware required at boot time or when installing the operating system would generally not be considered part of the operating system, though this distinction is unclear in the case of a rommable operating system such as RISC OS. The facilities an operating system provides and its general design philosophy exert an extremely strong influence on programming style and on the technical cultures that grow up around the machines on which it runs.

The comp.os.research FAQ makes the following distinction between micro- and macrokernels:

"A recurrent topic of discussion in this newsgroup has been the comparison between microkernel (for example Mach and QNX) and `macrokernel' (traditional Unix) operating systems. The basic notion of a microkernel consists of devolving as much functionality as possible into processes rather than the kernel itself; different systems take different approaches to implementing this.

For example, some systems (such as Mach) leave device drivers in the kernel, and place higher-level services (such as file systems) outside; others (such as QNX) move device drivers outside of the kernel.

However, anecdotal evidence [93-03-03-07-56.52] suggests that the distinction between microkernel and monolithic architectures is becoming more blurred as time goes on, as the two advance. For example, most modern monolithic kernels now implement multiple threads of execution and fine-grained parallelism. Architecturally, this approach begins to appear similar to a microkernel with several kernel-space processes working from shared memory.

As an aside, people often complain that the Mach system can't be a `real' microkernel, because it is so large (at least, this is the argument most frequently cited). However, I have been told that automatically-generated code stubs contribute very significantly to the size of the kernel, and that some size reduction would be likely if MIG (the stub generator) produced better code. [Can someone from CMU comment on this?] As mentioned above, the leaving of device drivers in the kernel also contributes to Mach's size.

Debating microkernels versus monolithic kernels on the basis of kernel size misses the central, architectural point. In the same way as the point of a RISC processor is not to minimise the instruction count, but rather to make a different tradeoff between what is implemented in the processor instruction set and what is implemented in other ways, the microkernel architectural issue is to determine which services are implemented in the microkernel, and which services are implemented external to that microkernel. By making appropriate choices here, the goal is to enhance various OS attributes in a manner that might not be addressable with a monolithic kernel OS. System attributes such as performance, flexibility, realtime, etc. are all variables which are taken into account.

The Computer History Graphing Project -- it looks like it needs some work, but we'll see.

There's lots of other info out there too, like FOLDOC, which could probably be incorporated into a project like this.
---
pb Reply or e-mail; don't vaguely moderate.