DOSPR
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook V4.2//EN">
<book>
<bookinfo>
<title>DeforaOS Project Reference</title>
<author>
<firstname>Pierre</firstname><surname>Pronchery</surname>
<affiliation>
<address>
<email>pierre@defora.org</email>
</address>
</affiliation>
</author>
<copyright>
<year>2004</year>
<holder>Pierre Pronchery</holder>
</copyright>
</bookinfo>
<preface>
<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>
<chapter>
<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>
<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)
-->
</chapter>
<chapter>
<title>Implementation process</title>
<!--
- 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
* graphics: graphical server, graphical mode toolkit
* servers: network services engines and interfaces
* posix compliant environment: unix apps
eventually, write the environment as an application engine, where usual apps are different interfaces...
-->
</chapter>
</book>