Oberon  new system called A2
Oberon Homepage at ETH Zürich 
Oberon is both a programming language in the Pascal-Modula tradition and a modern operating system for single-user personal workstations. Its highlights are: 
     an integrated and modular programming environment and 
     a versatile textual user interface. 

Oberon is both an object-oriented programming language and an operating system with new concepts such as commands and dynamic loading. The language and the system make up an environment that is similar to  Smalltalk in its flexibility but offers static type-checking and is much more efficient. Has a single author, a "Swiss watchmaker",  Niklaus Wirth of Fortran fame. 

In 1985 Niklaus Wirth and Juerg Gutknecht embarked on a project to build a new workstation from scratch. The quote from Einstein: 'Make it as simple as possible, but not simpler' served as a signpost for their approach resulting in a system of exemplary lucidity, efficiency and compactness. Wirth was fascinated by the accuracy and reliability of the Voyager space probe then passing Oberon, one of the moons of Uranus. The project was christened Oberon in its honor. 

Oberon System 3 is an ongoing research project which is actively being developed at the ETH. It is the standard base Oberon system supported here and its maintainance is coordinated by the ETH. Code developed for it is portable across all implementations. It can be installed on various platforms, either on top of the operating system (Windows, Linux for Intel-based PC, MacOS for Macintosh) of the host machine or, in the case of Intel-based PCs, as native operating system, known as PC Native Oberon. People outside the ETH are currently porting the system to SPARC Solaris, PowerPC Solaris, PowerPC Linux and HPUX. The system is available with full source code by ftp. 

PC Native Oberon is a free 32-bit operating system for Intel-based PCs. The minimal nature of the basic system appeals to people who appreciate lean software, but it also has modern features like the Gadgets component framework with integrated Internet support. The system is an ideal environment for low-resource computing, and has been applied in embedded systems. It is maintained actively at the Swiss Federal Institute 
of Technology Zürich (ETH), and email support is available. Being native means that the system is in complete control of the computer, and no other operating system is used, although it can coexist with other operating systems on the same disk. Most of the source code is freely downloadable, and the full source code can be obtained under contract from the ETH. 

Oberon System 3 can also be used as a production-ready system for work other than programming systems research. Anybody is welcome to use it as such but should be aware of the system's limitations. Comments and experience reports are appreciated. 

Oberon V4 is the original Oberon system with a textual user interface. It is available with full source code by ftp. There are implementations for many platforms: Amiga, Linux, Macintosh, Unix (DECstation, HP station, RS600, Silicon Graphics, SparcStation), PowerMac and Windows. These implementations are source-code compatible with each other and share the same document architecture. Download the latest version from the Linz server. A HP station version is found on the ETH server. 

In many computer scientists eyes Niklaus Wirth disqualified his own work by permanently throwing new versions of his creations on the market, making his old creations obsolet: Pascal was soon followed by Modula, then came Oberon...

OO (Object Orientation) 
Paradigm in programming language design. Opposed to declarative programming languages. 

Object-Oriented Information Sources at Geneva 

Opal (University of Washington)
Related to: Mach
Opal is a single-address-space operating system for 64-bit architectures. All Opal threads execute with a single global address space. The existence of a single address space simplifies sharing of complex (pointer-rich) data among cooperating applications, as well as persistent storage of that data, because pointers have the same meaning to all threads for potentially all time. Opal provides protection in the single address space; each thread executes within a protection domain that defines which pages it has the right to access.

OpenBSD
Yet another  BSD derivative. This group splintered off of the NetBSD project. Only a reunited BSD  would have any chance against Windows or even Linux.

OpenSTEP (Apple Computer Corporation)
Related to: Mach
Steve Jobs' brain child after Apple, all that is left of NeXT is the remarkably good NeXTSTEP/OPENSTEP Operating System, a mach-based mostly UNIX with a very good user interface and programmer environment. It's now available for the x86 PC, and many people really like it. OpenSTEP may be the basis of the next Mac OS, Rhapsody.

Open Source  or why BSD-license is so important
Eric Raymond coined "open source" in exchange to  "free software" in his "Cathedral and Bazaar" in February 1998. 

Open Source Code and the Early Development of Unix 
     Since the Unix programming environment was used by the researchers themselves, they came to learn its weaknesses and problems and were encouraged to make needed improvements. Contributing to the value of Unix during its early development, was the fact that the source code was open and available. It could be examined, improved, and customized. In an article "Can UNIX Survive Secret Source Code?", Mike Lesk,  then a Bell Labs researcher, observes how only when computer source code is open and can be modified, will it be developed and vibrant.  He gives the example of COMIT, the string processing language. At one point, its owners decided there would no longer be any modifications in the code, and so only distributed it in  binary form. "You haven't heard of COMIT since," he notes. He describes how the same fate befell TRAC, a language close to FORTH. "Software is more attractive to hackers," Lesk maintains, "if it can be changed. As more and more UNIX suppliers restrict access to source code, fewer and fewer advanced research shops  will be attracted to UNIX."(Michael Lesk, "Can UNIX Survive Secret Source Code?", Computing Systems, vol 1 no 2, Spring, 1988, p. 189.) 
     Commenting on the importance of open source code in the early years of Unix development at Bell Labs, Thompson and Ritchie write, "Because all source programs were always available and easily modified on-line we were willing to revise and rewrite the system and its software when new ideas were invented,  discovered, or suggested by others."(D. M. Ritchie and K. Thompson, "The UNIX Time-Sharing System," p. 1927.) 
     Not only was the source code open and available to the Bell Labs researchers developing the system, but the Labs also made the sources available on tape at the request of academic colleagues. Robert Fabry of the University of California at Berkeley was able to get a tape of Version 4 Unix and that began the long and important role played by faculty and students at the University of California at Berkeley in the development of  Unix.(Marshall Kirk McKusick, "A Berkeley Odyssey", Unix Review, January 1985, p 30.) 
     Source code tapes were made available to interested researchers in the academic and computer science community for a nominal fee. For example, when John Lions, a Professor of Computer Science at the University of New South Wales in Australia read a paper published by Thompson and Ritchie in mid 1974, he wrote them for a copy of the Unix tape. After signing a license agreement with the Labs, and a token payment of $110 Australian ($150 U.S.), the Unix Edition 5 tape and manuals arrived, "as a late Christmas present," in December, 1974, remembers John Lions.(See Peter Ivanov, "Interview with John Lions," UNIX Review, October, 1985, p. 51.) 
      While Bell Labs made the tape and manuals available,  they did so with no support. Berkley Tague explains the release was "`caveat  emptor' -  i.e. dollars on the table up front and no support promised." 
      Henry Spencer, a Unix pioneer from the University of Toronto in Canada, and one of the programmers of C News, describes how early users of Unix in the academic community had to provide their own support. He explains: 
 
    "It was very common at the time. This was in the 
    days when UNIX was still treated by the Bell System 
    as, `Oh, just something we happen to do for our own 
    internal use. You can have a copy if you want, but if 
    you got problems, don't bother us.' And the result 
    was if you wanted UNIX support you did it yourself 
    or it didn't happen." 
("Interview with Henry Spencer: On Usenet News and C News," The Amateur Computerist, vol 5 no 1-2, Winter/Spring 1993, p. 5.) 
 
    Lions agrees, "We needed help," he notes, "but we couldn't get any from outside sources so we ended up  generating our own expertise."("Interview with John Lions," p. 51.) Not only did those working on Unix implementation at the University of New South Wales have access to the code, but Lions explains how Ian Johnstone, the tutor working with him in his Operating Systems class, suggested making some of the code for the Unix kernel available to the students in his class. "I think it was in 1975," remembers Lions, that Ian Johnstone asked, "`Why don't we run off a few of the source files for the kernel and ask the students to take a look at them? Then we can ask them some questions; maybe it will be interesting'."(Ibid., p. 52.) Lions took Johnstone's suggestion and made some of the Unix source code available to his class, but his students complained. They felt they needed to see the source code for the whole kernel in order to make sense out of any part. 
      Taking their suggestion, Lions decided to make a large part of the source code available to his class. "The following year," he recounts, "I prepared a booklet containing the source files for a version of Edition 6 UNIX that could then run on a PDP-11/40 system." Lions followed the book of source code with a book of "explanatory notes that was intended to introduce students to the code."(Ibid.) Lions explains that working on his book, "`A Commentary on the UNIX Operating System' was a real learning experience. By slowly and methodically surveying the whole kernel he notes, "I came to understand things that others had overlooked."(Ibid.) 
      When he read the manual and wasn't quite certain about his interpretation, Lions would read the code. Through this process, he was able to determine that the manual was "really quite accurate in its description of what a program actually does. In the Thompson/Ritchie era," he observes, "words were carefully chosen."(Ibid., p. 53.) Lions writes, "In our opinion, it is highly beneficial for students to have the opportunity to study a working operating system in all its aspects."(John Lions, A Commentary on the UNIX Operating System, The University of New South Wales, (nd), p. 5.) 
      "Moreover," he adds, "it is undoubtedly good for students majoring in computer science to be confronted at least once in their careers with the task of reading and understanding a program of major dimensions."(Ibid.) Lions found that, "On the whole the authors of UNIX, Ken Thompson and Dennis Ritchie, have created a program of great strength, integrity and effectiveness," which he urged his students to "admire and seek to  emulate."(Ibid., p. 9. A short time later, in "Unix Implementation", The Bell System Technical Journal, vol 57, no 6, part 2, July-August 1978, Ken Thompson described how a goal in writing the Unix kernel was to write exemplary source code that others would emulate. Thompson writes: "What is or is not implemented in the kernel represents both a great responsibility and a great power. It is a soap-box platform on `the way things should be done.' Even so, if `the way' is too radical, no one will follow it. Every important decision was weighed carefully. Throughout, simplicity has been substituted for efficiency. Complex algorithms are used only if their complexity can be localized."(pp. 1931-32)) Not only did students in Lions' class read and study the Unix source code and Lions' Commentary on the source code, but Lions describes how he sent more than 200 copies of his book to Bell Laboratories. Eventually, the Labs took over distribution of the book. 
      Tague relates how Lions' book of commentary and the Unix source code were used at AT&T "as part of the documentation package for those who wanted to understand or modify the UNIX(r) source code that the USG [Unix Support Group] shipped."("Automating Telephone Support Operations: An Interview with Berkley Tague," Amateur Computerist, vol 6 no 1, p. 10.) Even after Unix V6 had been replaced by Unix V7, Tague explains that Lions' Commentary continued to be useful as an introduction to Unix. Tague writes: 
 
     "It outlined the conceptual architecture, very clearly in 
     the short form of the system before it had accreted all the 
     minor changes and feature additions that disguised the 
     original clarity of its structure. All new people were given 
     a copy when they joined the USG. And I suspect most 
     development groups did the same." 
(Ibid. Also, Mike Blake-Knox describes how he did development work for Bell-Northern Research (BNR), which was the Bell Labs equivalent for Northern Electric (which is now Northern Telecom). He reports that he had a copy of Lions' book and used it to do Unix kernel modifications. (from e-mail correspondence Feb. 13, 1994)) 
 
     Pioneers like Henry Spencer describe how important it was to those in the Unix community to have the source code. He notes how having the sources made it possible to identify and fix the bugs that they discovered, "There is something the UNIX community has always been fairly strong on," he explained during an interview, "admitting things you know don't work about the software." Even in the late 1970's and early 1980's, remembers Spencer, "practically every UNIX site had complete sources."("Interview with Henry Spencer," p. 4.) 
      One of the early functions of Usenet, the early online community of Unix systems begun in 1979, according to Spencer, was to provide cooperative software support for the Unix community. He elaborates: 
 
     Well, for one thing, Usenet predated a lot of company bbs's 
     and the like. It was basically a cheap way to hear about 
     things fast and this was at a time when practically every 
     UNIX site had complete sources and so a bug report often 
     came with a fix. It was a way of finding out what people had 
     discovered and what fixes they'd worked out for it. Quickly 
     and easily. And for that matter, if you ran into something 
     that you couldn't solve yourself, putting out an inquiry to 
     a bunch of fairly bright people who were fairly familiar 
     with the code, often got a response, `O Yeah. We solved that 
     one' or `You're right. There's a bug. Here's how to fix it' 
     or sympathy even if no one had a fix for it." (Ibid.) 
 
    Another Unix pioneer, Dick Haight, corroborates the important role open source code played for those in the Unix community: 

     "That by the way, was one of the great things about UNIX in 
     the early days: people actually shared each other's stuff. 
     It's too bad that so many sites now have purposefully turned 
     off the read privileges in order to keep their ideas from 
     being stolen. Not only did we learn a lot in the old days 
     from sharing material, but we also never had to worry about 
     how things really worked because we always could go read the 
     source. That's still the only thing that matters when the 
     going gets tough." 
(Marc Rochkind, "Interview with Dick Haight," Unix Review, May, 1986, p. 65.) 
 
     Unix was continually used and improved by its creators. A growing community of programmers, system administrators, and users, both at Bell Labs and at academic and research sites outside the Labs, also used, developed and debugged the code. The fact that the source code was open and available made this possible. The result was the creation of Unix as a powerful and flexible programming environment. 
     Though Unix was primarily designed to "help build research  software," Bell Labs software developers soon found that, "what worked well in the programming laboratory also worked well on modest projects to develop minicomputer-based systems in support of telephone company operations."(M.D. McIlroy, E.N. Pinson, and B. A. Tague, "Foreward", Bell System  Technical Journal, vol 57, no. 6, July-August, 1978, part 2, p.  1902.) 
(On the Early History and Impact of Unix. Tools to Build the Tools for a New Millenium, Chapter 9 of  Ronda & Michael Hauben's "Netizen's Netbook") 
 

Thomas Scoville, OSS Europe: Open Source™ . Continental Savoir-Faire 
"If the pundits are right, it won't be surprising if this paradigm shift is accompanied by a shift of regional strength -- in the software industry, at any rate -- from the United States to Europe. It is clear Europe is already well ahead of the United States in Open Source utilization, culture, and awareness. A disproportionate number of Open Source development efforts are based there. Businesses, universities, and individuals on the continent are committing to Open Source offerings in relative numbers far exceeding their American counterparts." 
 
 

Openvms

Open VMS was ported to Intel Itanium http://www.hp.com/products1/evolution/alpha_retaintrust/openvms/

You can view the OpenVMS roadmaps http://h71000.www7.hp.com/openvms/roadmap/openvms_roadmaps.htm
 

OS9 (Microware Systems Corporation)
OS-9 was a real-time, multiuser, multitasking operating system developed by Microware Systems Corporation. It was modular, allowing new devices to be added to the system simply by writing new device drivers, or if a similar device already exists, by simply creating a new device descriptor. All I/O devices can be treated as files, which unifies the I/O system. In addition, the kernel and all user programs are ROMable.

OS/2 Warp (IBM) 

Mulitasking OS introduced in 1988.

If IBM had taken in the late 90'ths the decission to give OS/2 into the public domain, this could have been a potential competitor to Windows. As it is, OS/2 plays no role at all. 

Microsoft had been developing IBM's new graphical operating system, OS/2 (which would have replaced Microsoft's cash-cow DOS as well), but in 1990 Microsoft withdrew from that work in favor of concentrating on its release of Windows 3.0 the same year- a relatively amicable separation from IBM that would lead, through IBM missteps, to Microsoft domination.
     Part of the problem was that OS/2 was aimed at higher-power machines not generally available, while Microsoft still understood better than IBM how to leverage developer support and third-party software into acceptance of an operating system. And Microsoft was not loathe for a little hardball even against former ally IBM, threatening at one point to pull Microsoft's sponsorship of an industry exposition if IBM's top OS/2 executive was allowed to speak.
(Nathan Newman, From Microsoft Word to Microsoft World: How Microsoft is Building a Global Monopoly. A NetAction White Paper, 1997)  
 
OS/2 e-zine 

OS/360 (IBM)  (outdated)
was considered as the first real OS, developed around 1962. Sold 1964 as product. Programmed in assembler. JCL batch system/non time-sharing.

OS/400  (outdated)

OSE
OSE is a full-featured family of high quality, reliable and high performance real-time operating systems from Enea OSE Systems, Sweeden. There is an OSE kernel for every need, from OSE Basic (for Z80, i8051 and others) up to OSE Delta (for M68k, PPC and others). OSE Delta is also the first RTOS to be certified according to the software quality standard IEC 1508. OSE Delta supports runtime configuation, runtime program loading, multi-CPU systems and TCP/IP.

OSF/1 
IBM, DEC and HP joined to build the OSF -- die Open Software Foundation.

Motiv,  Microkernel-version on the basis of  Mach
    

OSI (Open Systems Interconnection) 
ISOs magic 7 layer of the net. Not a OS, a reference model. 
 

OSKIT (see also FLUX)

The OSKit is a framework and set of modularized components and library code, together with extensive documentation, for the construction of operating system kernels, servers, and other OS-level functionality. Its purpose is to provide, as a set of easily reusable modules, much of the infrastructure “grunge” that usually takes up a large percentage of development time in any operating system or OS-related project, and allow developers to concentrate their efforts on the unique and interesting aspects of the new OS in question. The goal is for someone to be able to take the OSKit and immediately have a base on which they can start concentrating on “real” OS issues such as scheduling, VM, IPC, file systems, security, or whatever. Alternately they can concentrate on the real language issues raised by using advanced languages inside operating systems, such as Java, Lisp, Scheme, or ML--instead of spending six months first writing boot loader code, startup code, device drivers, kernel printf and malloc code, a kernel debugger, etc. With the recent addition of extensive multithreading and sophisticated scheduling support, the OSKit also provides a modular platform for embedded applications.

Although it can provide a complete OS environment for many domains, the primary intention of this toolkit is not to “write the OS for you”; we certainly want to leave the OS writing to the OS writer. The dividing line between the “OS” and the “OS toolkit,” as we see it, is basically the line between what OS writers want to write and what they would otherwise have to write but don’t really want to. Naturally this will vary between different OS groups and developers. If you really want to write your own x86 protected-mode startup code, or have found a clever way to do it “better,” you’re perfectly free to do so and simply not use the corresponding code in our toolkit. However, our goal is that the toolkit be modular enough that you can still easily use other parts of it to fill in other functional areas you don’t want to have to deal with yourself (or areas that you just don’t have time to do “yet”).

As such, the toolkit is designed to be usable either as a whole or in arbitrary subsets, as requirements dictate. It can be used either as a set of support libraries to be linked into an operating system kernel and/or its support programs, or it can be used merely as a collection of “spare parts”: example source code to be ripped apart and cannibalized for whatever purpose. (Naturally, we prefer that the toolkit be used in library fashion, since this keeps a cleaner interface between the toolkit and the OS and makes them both easier to maintain; however, we recognize that in some situations this will not be practical for technical or political reasons.)

The toolkit is also intended to be useful for things that aren’t kernels but are OS-related, such as boot loaders or OS-level servers running on top of a microkernel.

All about OSs