UOS Frequently asked questions

How is the UOS development project organized?
I am the project leader. As such, I determine what is included in the software and what is in the specification. This is necessary to ensure that the result remains consistent. Other than that, people can submit ideas, corrections, and code. In fact, they are encouraged to do so. As long as it works and is compatible with the specification, I'll almost certainly be okay with it.

What makes you think that you could design a better O/S than what is available?
I spent many years as a Systems Administrator for minicomputers running RSTS/E, VMS (now OpenVMS), and Unix. I read all the documentation, did systems programming, and was a resource to other programmers who needed to know how to accomplish tasks using the resources provided by the O/S. I spent time reading up on the internals of these O/Ses, as well as upgrading, migrating, and maintaining their performance and security. In addtion, I've spent a lot of time programming and using other systems, such as MSDOS, Windows, and Linux. I have a BS in Computer Science, which included classes on such things as Operating System design. As a consequence, I've become very familiar with Operating Systems in general, and some of them in detail. I have rejoiced in well-designed aspects and been appalled at those areas that prevent me from accomplishing my goals. From this background, I've formed an idea of how a good Operating System should work.

What is the expected/hoped-for market penetration of UOS?
Although this is not a commercial enterprise, UOS will eventually compete for market share with other Operating Systems - as do all Operating systems running on modern consumer hardware. I've taken note of several projects that aimed to compete with Windows and, as I predicted, they completely failed. It is madness to think that one person, or a small group, could somehow compete with the billions of dollars of manpower and equipment that a company like Microsoft throws at Windows development. Some projects, realizing this, aim to create a incompatible product. But, honestly, how many people are going to abandon all their favorite games, browsers, compilers, and other applications for something new, even if it were demonstratably superior (although I would argue that the incompatibility itself is an inferority)? I think the best approach, in fact the only approach, that will result in large-scale adoption of UOS is the approach taken by RSTS/E. Before RSTS/E was released, DEC had several other operating systems that ran on the PDP-11 line of computers. Two of the most popular were RT-11 and RSX. Rather than forcing customers to abandon the applications that were written for RT-11 and RSX, DEC made RSTS/E compatible with them by providing Run-Time Systems (RTS) for RT11 and RSX. Programs associated with RT-11 were run using the RT11 RTS and those for RSX were run with the RSX RTS. What an RTS did was intercept the calls from the program to the operating system, and then translate them into native RSTS/E calls. This happened seamlessly. The programs had no idea they weren't running on a real RT-11 system. The RTS also provided a shell that worked like the corresponding O/S shell. For all intents and purposes, the user was running RT-11. Something similar is done with Linux with the WINE program - it emulates the Windows environment on Linux. However, there are some issues with how well it integrates with the Mac OS, due to the fact that the Mac OS doesn't directly support the emulator or have a flexible-enough (or well-documented enough) interface to allow WINE to better integrate into the Mac environment. UOS is built to support O/S emulation from the hardware up so that everyone's favorite Windows applications can run on UOS. We are not going to be Microsoft or Mac or Linux bigots here - the idea is to build an Operating System that is flexible enough to meet a wide variety of needs, including those of Windows and Mac users.