DOSPR

Back to the revision list Download file Permalink

<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.2//EN">

<book>

<title>DeforaOS Project Reference</title>

<firstname>Pierre</firstname><surname>Pronchery</surname>

<email>pierre@defora.org</email>

</address>

</affiliation>

</author>

<holder>Pierre Pronchery</holder>

</copyright>

</bookinfo>

<title>Introduction</title>

<para>

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.

</para>

<para>

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.

</para>

<para>

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.

</para>

<para>

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.

</para>

</preface>

<title>Project orientations</title>

<sect1>

<title>Open source</title>

<!--

- interoperability

- ...

- security

- conclude with community open source limitations for coordination etc

-->

<para>

</para>

</sect1>

<sect1>

<title>Usability</title>

<!--

- introduce with community open source coherence etc problem

- UNIX pros and cons (what to keep, and what not)

- coherence

- user-proof

=> developped by a small and tight team

=> remain transparent, accept external contributions

-->

<para>

</para>

</sect1>

<sect1>

<title>Technical choices</title>

<sect2>

<title>Micro kernel</title>

<para>

</para>

</sect2>

<sect2>

<title>Programming languages</title>

<para>

</para>

</sect2>

<sect2>

<title>Applications</title>

<!--

- application engine

- application interfaces

- messages

- toolkit programming interface

* same in text-mode and graphical mode if possible

* then, let applications check which mode is available ($DISPLAY, istty(), ?) and load the appropriate module for rendering

-->

<para>

</para>

</sect2>

<sect2>

<title>Graphical server</title>

<!--

- client-side toolkit?

- OpenGL only server

-->

<para>

</para>

</sect2>

</sect1>

</chapter>

<title>Detailed design</title>

<!--

- filesystem: keep what's good in UNIX, present it in a friendlier way

- sessions

* sessions manager/init => itself a session? => can log on it and set it up?

* system sessions (services)

* user sessions

- login process

* one can even login on a system service as if would join an existing session, and the setup and monitoring interfaces appear (make this possible generally from a user's session, and you've got the control panel)

-->

<para>

</para>

</chapter>

<title>Implementation process</title>

<sect1>

<title>Development tasks</title>

<sect2>

<title>Task groups</title>

<para>

It seems reasonable, if not obvious, to determine independant tasks within the huge work described before in this document. There follows a proposal.

</para>

<sect3>

<title>Global tasks</title>

<title>Programming interfaces</title>

<para>

</para>

</formalpara>

</sect3>

<sect3>

<title>Cooperation tasks</title>

<title>Documentations</title>

<para>

</para>

</formalpara>

</sect3>

<sect3>

<title>Low-level applications</title>

<para>

</para>

</sect3>

<sect3>

<title>System applications</title>

<para>

</para>

</sect3>

<sect3>

<title>End-user applications</title>

<para>

</para>

</sect3>

<sect3>

<title>Graphics</title>

<title>Graphical server</title>

<para>

</para>

</formalpara>

<title>Graphical mode toolkit</title>

<para>

</para>

</formalpara>

</sect3>

<sect3>

<title>Services</title>

<title>General purpose daemons</title>

<para>

</para>

</formalpara>

<title>Networking daemons</title>

<para>

</para>

</formalpara>

<title>Applications interfaces</title>

<para>

The only essential part of these services is their appengine/session (?).

</para>

</formalpara>

</sect3>

<sect3>

<title>POSIX environment</title>

<para>

At the moment it is not yet known if the system will be based on, or provide a native POSIX development environment.

</para>

<para>

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).

</para>

</sect3>

</sect2>

</sect1>

<!--

- determine task groups

- global tasks: designing applications programming interfaces

- cooperation tasks: writing documentations

- preliminary tasks groups attempt:

* low-level: assembler, compiler, micro-kernel, libc

* system: essential applications engines and interfaces, text mode toolkit

* applications: end user applications engines

. file browser

. web browser

. mail reader

. messaging client

-->

</chapter>

</book>