PierrePronchery

pierre@defora.org

2004 Pierre Pronchery Nowadays mainly two conceptions of computing compete: open source and proprietary software. I believe that most software should be available with its source code, as a proof of quality, interoperability, and security, to only quote the most obvious reasons. However, most open source operating systems are based on UNIX. While this can be considered as a mature, stable and portable operating system, its use can be cryptic, and users are often facing technical inner workings of this system. Moreover, most human-computer interfaces, either in text or graphical mode, and even configuration files, are incoherent between each other, and particularly in community open source systems. It is also certainly worth thinking about a technical re-design of the UNIX system. It has been originally designed along with C, with a monokernel approach, on computers where every single characted handling avoided counted. Now the power of even 10 years old computers is far beyond this, and researchers are working on micro-kernels, and safe programming languages for instance. Today I think my ideal operating system should be open source, micro-kernel based, usable on pentium-class computers, coherent, connected, and distributed. This paper explains in detail how I would design and implement it. FIXME FIXME The system will boot with a minimal filesystem image in memory, mounting the system directory from a location hard-coded in the image, or a bootloader parameter. Additional volumes will be directly available in the volumes hierarchy, and eventually mapped to the user defined applications and data files hierarchies. FIXME FIXME Every application runs inside what's called a "session". They are split in two parts: the application "engine", and the "interface". The end-user interaction should be presented the same way in text mode or graphical mode, possibly via the same API, and using only one binary for both. FIXME FIXME FIXME The applications interfaces may detect the requested toolkit to use according to the availability of an environment variable ("DISPLAY" for instance), or by the result of an equivalent to the POSIX istty() call. Some applications may work with character streams as a fallback, typically like the UNIX filtering applications. FIXME The graphics library would be fully OpenGL compliant. It is not yet known how the clients will communicate with the graphical server. In case of a socket based communication (maybe implemented anyway to run on other OSes), instead of the current kernel based one, the network transparency will be straight-forward. It may not be efficient though... This will be decided later. About the graphical toolkit for applications, I insist that only one library will be supported, and binary compatible with the text mode toolkit. It may be more efficient to implement the toolkit on the server side, this will be decided later too. The filesystem is highly inspired from the UNIX one, but taking in consideration the user only needs to access his files, applications, volumes or shared files most of the time. Consequently, the following directories are available at top level: "Apps", "Data", "System" and "Volumes". The "System" directory could even have been called ".System" to only let the advanced users access it via the common interfaces. It could even be considered that the place of an executable in the filesystem hierarchy could determine its privileges; this can't be a security risk, since when one gains access to the filesystem, then he has already access to the full system. It contains a sub-directory per applications group. In this sub-directory one man find the following directories: Binaries: the applications binaries Engines: the applications' engines binaries Libraries: the shared libraries System: the applications administration binaries Sources: the applications source code (a sub-directory per package) Shared data: documentation, hosted files, ... System hierarchy. Contains the following sub-directories: Apps: system essential applications and libraries, containing a Apps/subdirectory like hierarchy. Devices: equivalent to the /dev Kernel: equivalent to the /proc on Linux Sources: the associated source code (a sub-directory per entity) Hard disks, CD-ROM and DVD-ROM drives, USB keys, etc, that get automatically mounted. To gain read and write access on them, one should have the necessary privileges though. Make it just work Audit Optimize Audit Think about possible features If globally accepted, add selected features Audit FIXME It seems reasonable, if not obvious, to determine independant tasks within the huge work described before in this document. There follows a proposal. FIXME FIXME FIXME FIXME FIXME FIXME FIXME These applications only require their application engines. For an easy and safe configuration, or monitoring, they may provide user interfaces though. FIXME Every application that fits on a desktop: file browser, web browser, mail and news reader, messaging application, images viewer, audio and video viewer, and optionaly games, etc. FIXME FIXME FIXME FIXME The only essential part of these services is their application engines. At the moment it is not yet known if the system will be based on, or provide a native POSIX development environment. It may be possible to write an application engine providing the POSIX system and library calls, on which the POSIX utilities would connect as usual application interfaces. We could even imagine them with a graphical interface, which would fallback as the regular UNIX commands if the graphical toolkit is denied (using stdin, stdout and stderr as usual).