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 character 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>

<!--

- for everything: pros and cons

-->

<sect1>

<title>Open source</title>

<sect2>

<title>Project licenses</title>

<para>

This section contains the major software licenses used in the project, either for application source code, documentation, or any other file contained in the system.

</para>

<para>

The choices of these licenses are explained in the next section of this document.

</para>

<sect3>

<title>Global source code</title>

<para>

The terms of this license are extracted from the "Open Source Definition", thus it should be compatible with the original terms.

</para>

DeforaOS project licensing terms

--------------------------------

Preamble

--------

"the author" in this license is myself, Pierre Pronchery.

Introduction

------------

The use of the software distributed as part of the DeforaOS project must comply

with the following criteria. The concerned software includes at least the

following (unless explictly mentionned by the author):

- every software contained in the project "DeforaOS".

- every software distributed on the DeforaOS project website,

"http://www.defora.org", belonging to the author.

1. Free Redistribution

----------------------

Anyone is free to sell or give away the software, as a component of an

aggregate software distribution containing programs from several different

sources. Not royalty or any fee is required to do this.

2. Source Code

--------------

Distribution of the software is allowed in source code as well as compiled form.

Where some form of the product is not distributed with source code, there must

be a well-publicized means of obtaining the source code, not exceeding the cost

of an average internet download. The preferred form of modification is of source

code, via the unified diff format. It is not allowed to obfuscate source code in

any way, or to use any intermediate compilation format.

3. Derived Works

----------------

Modifications and derived works are tolerated. They must be distributed

according to the terms of this license. Moreover, the author kindly asks anyone

working on such modifications or works to keep him informed of these. The aim is

to let them benefit to everyone, and keep the best version of the software, and

related works, available at the original place (as a matter of global coherence,

and ease of use).

4. Integrity Of The Author's Source Code

----------------------------------------

Any modification of the source code, must be distributed as patch files,

according to the unified diff format. Distribution of software built from

modified source code is allowed. Derived works must carry the same name, and

must modify the version number this way: "original.version.number-vendor_name".

5. No Discrimination Against Persons Or Groups

----------------------------------------------

This license doesn't discriminate against any person or group of persons.

6. No Discrimination Against Fields Of Endeavor

-----------------------------------------------

This license does not restrict anyone from making use of the software in a

specific field of endeavor.

7. Distribution Of License

--------------------------

The rights attached to the software apply to all to whom the software is

redistributed, without the need for execution of an additional license by those

parties.

8. License Must Not Be Specific To A Product

--------------------------------------------

The rights attached to the program do not depend of any other licensing rights.

9. License Must Not Restrict Other Software

-------------------------------------------

This license does not place restrictions on other software that is distributed

along with the licensed software.

10. License Must Be Technology-Neutral

--------------------------------------

No provision of the license may be predicated on any individual technology or

style or interface.

</screen>

</sect3>

<sect3>

<title>Documentation</title>

<para>

FIXME: not decided yet

</para>

</sect3>

<sect3>

<title>Other files</title>

<para>

FIXME: depends if they're already copyrighted or not, etc, else not decided yet

</para>

</sect3>

</sect2>

<sect2>

<title>Fundamental liberties</title>

<para>

FIXME: free software definition, licenses choices, ...

</para>

</sect2>

<sect2>

<title>Other considerations</title>

<para>

FIXME:

- advantages: interoperability, security, ...

- issues: coherence (in community development)

<!--

- coherence => developped by a small and tight team

- open => remain transparent, accept external contributions

-->

</para>

</sect2>

</sect1>

<sect1>

<title>Usability</title>

<sect2>

<title>Existing systems experiences</title>

<sect3>

<para>

FIXME:

- 200 distributions, few major applications per usage

- simple concepts

- light and flexible historical inheritances within more than 30 years

- sophisticated yet flexible and clear setup

- appropriate software versions handling

- localization ease

- things like they are

- different development models, including open source...

</para>

</sect3>

<sect3>

<title>Windows</title>

<para>

FIXME:

- few distributions, 200 major applications per usage

- complex concepts

- heavy historical inheritances within a few years

- registry

- DLL hell

- localization issues

- original terms renamed and appropriated

- closed and lazy development where monopoly, aggressive standards conformance policy else (and often buggy too)

</para>

</sect3>

<sect3>

<title>Others</title>

<para>

FIXME:

- so few...

</para>

</sect3>

</sect2>

<sect2>

<title>User orientation</title>

<para>

FIXME: always think like the users, and listen to them...

</para>

</sect2>

<sect2>

<title>Usage samples</title>

<para>

FIXME: a few words, and conceptual screen shots, about it would feel like to use the system...

</para>

</sect2>

</sect1>

<sect1>

<title>Technical choices</title>

<sect2>

<title>Micro kernel</title>

<sect3>

<title>Booting</title>

<para>

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.

</para>

</sect3>

<sect3>

<title>Drivers</title>

<para>

They actually are applications engines, with the appropriate memory mappings and other priviledges necessary in their very purpose.

</para>

<para>

Applications using the drivers connect to them like interfaces usually do.

</para>

</sect3>

<sect3>

<title>Virtual File System</title>

<para>

Interface proxy to the filesystems drivers. Knows the filesystems mappings. Maintains the pid/fd mappings. Only interface allowed to connect to the filesystems drivers. Sanitizes all accesses (handles and removes special path like ".", "..", etc).

</para>

</sect3>

</sect2>

<sect2>

<title>Programming languages</title>

<para>

First, I want to avoid as much as possible to use assembly code. This is for obvious portability and readability reasons. I believe the micro-kernel should be coded in both assembly and C, because it has to be written with the computer limits and inner workings in mind. Object abstraction (in the programming language) is not necessary in the case of the kernel to my mind.

</para>

<para>

I am also thinking about using C in the whole base system:

</para>

<listitem><para>Ada: no, but it could be very interesting</para></listitem>

<listitem><para>Assembly: no, long to write, too close to the machine</para></listitem>

<listitem><para>C: yes, simpler to implement (and kind of mandatory anyway), few keywords, total liberty in APIs definitions, even if lacks exceptions, and is too close to the assembly language (then again we can handle the machine limits, ...if we think each time about each possibility)</para></listitem>

<listitem><para>C++: no, bloat, hell to implement</para></listitem>

<listitem><para>C#: no, I still have to look better at it</para></listitem>

<listitem><para>D: no, doesn't look mature yet</para></listitem>

<listitem><para>Java: no (virtual machine, verbosity of the language, classes names, ...)</para></listitem>

<listitem><para>Objective C: no, though certainly interesting, but I find the syntax cryptic</para></listitem>

<listitem><para>Perl: no, interpreter</para></listitem>

<listitem><para>Python: no, interpreter</para></listitem>

</itemizedlist>

<para>

And also, as I care about coherence, the APIs in every language will be directly derived from a common definition, up to the point that every language would stick to its syntax, but could be compiled and linked against objects written in another one. If this is possible of course. Everything helping portability and interoperability will be appreciated.

</para>

</sect2>

<sect2>

<title>Applications</title>

<!--

- application engine

- application interfaces

- messages

- toolkit programming interface

-->

<para>

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.

</para>

<sect3>

<title>Sessions</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>Applications engines</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>Applications interfaces</title>

<para>

FIXME

</para>

<para>

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.

</para>

</sect3>

<sect3>

<title>Interface toolkits</title>

<para>

FIXME

</para>

</sect3>

</sect2>

<sect2>

<title>Graphical server</title>

<!--

- client-side toolkit?

-->

<para>

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.

</para>

<para>

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.

</para>

</sect2>

</sect1>

</chapter>

<title>Detailed design</title>

<sect1>

<sect2>

<title>Filesystem hierarchy</title>

<para>

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.

</para>

<para>

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.

</para>

<sect3>

<para>

It contains a sub-directory per applications group. In this sub-directory one man find the following directories:

</para>

<listitem><para>Binaries: the applications binaries</para></listitem>

<listitem><para>Engines: the applications' engines binaries</para></listitem>

<listitem><para>Libraries: the shared libraries</para></listitem>

<listitem><para>System: the applications administration binaries</para></listitem>

<listitem><para>Sources: the applications source code (a sub-directory per package)</para></listitem>

</itemizedlist>

</sect3>

<sect3>

<para>

Shared data: documentation, hosted files, ...

</para>

</sect3>

<sect3>

<title>/System</title>

<para>

System hierarchy. Contains the following sub-directories:

</para>

<listitem><para>Apps: system essential applications and libraries, containing a Apps/subdirectory like hierarchy.</para></listitem>

<listitem><para>Devices: equivalent to the /dev</para></listitem>

<listitem><para>Kernel: equivalent to the /proc on Linux</para></listitem>

<listitem><para>Sources: the associated source code (a sub-directory per entity)</para></listitem>

</itemizedlist>

</sect3>

<sect3>

<title>/Volumes</title>

<para>

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.

</para>

</sect3>

</sect2>

<sect2>

<title>Special files</title>

<sect3>

<title>Configuration files</title>

<para>

FIXME: think about a DTD for configuration files;

</para>

<para>

Configuration files contain variable names along with their values, nested inside sections. Default variables and values can be set in the global section, which name is "" (empty string). The global section is the default one. Comments are allowed on their own lines.

</para>

#this is a comment

#default session is global

variable=value

[section]

variable=value

[another section]

#another comment

variable=value

another variable=value

[]

#this is global section again

variable=value

</screen>

</sect3>

</sect2>

</sect1>

<sect1>

<title>Programming interfaces</title>

<!--

- use a table, head with prefix, describe function

- prefix actually is a namespace, it should not be an abbreviation, but then it would be a pain to develop in C with it; else we could think of tricks to implement namespaces in C in a way, like:

{

namespace_set("GToolkit");

gt_win = window_new();

namespace_set("AppEngine");

ae_win = window_new();

}

which could ease the implementation of shared libraries, though this is ugly and can be a pain sometimes...

- detail every data type

-->

<sect2>

<title>Essential classes</title>

<sect3>

<title>Buffers</title>

<para>

Prefix is "Buffer".

</para>

new()

new(Size size)

delete()

size()

size(Size size)

</programlisting>

</sect3>

<sect3>

<title>Config</title>

<para>

Prefix is "Config".

</para>

new()

delete()

load(File file)

save(File file)

get(String section, String name)

set(String section, String name, Variable variable)

</programlisting>

</sect3>

<sect3>

<title>Files</title>

<para>

Prefix is "File".

</para>

new()

new(String filename)

delete()

open(String filename)

open(String filename, FileOpenMode mode)

close()

read(Buffer buffer)

write(Buffer buffer)

position(Offset offset)

position(Offset offset, FilePositionFrom)

flush()

</programlisting>

</sect3>

<sect3>

<title>Lists</title>

<para>

Prefix is "List".

</para>

new()

new(ListType type)

delete()

type()

type(ListType type)

</programlisting>

</sect3>

<sect3>

<title>Strings</title>

<para>

Prefix is "String".

</para>

new()

delete()

size()

size(Size size)

length()

length(Size size)

</programlisting>

</sect3>

<sect3>

<title>Variables</title>

<para>

Prefix is "Variable".

</para>

<para>

This type is used for data conversions.

</para>

new()

delete()

</programlisting>

</sect3>

</sect2>

<sect2>

<title>Applications engines</title>

<para>

Prefix is "AE".

</para>

</sect2>

<sect2>

<title>Applications interfaces</title>

<para>

Prefix is "AI".

</para>

</sect2>

<sect2>

<title>Graphical toolkit</title>

<para>

Prefix is "G".

</para>

<sect3>

<title>Window</title>

<para>

Prefix is "Window".

</para>

new()

new(String title)

delete()

size()

size(Size x, Size y)

</programlisting>

</sect3>

</sect2>

</sect1>

<!--

- APIs

* C library:

. str*() => string_*() and buffer_*()

. C classes => String?, Buffer?, SList, DList, Hash, Config, ...

- sessions

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

* system sessions/engines (services)

* user sessions

- inter process communications

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

<title>Implementation process</title>

<sect1>

<title>Development policies</title>

<sect2>

<title>Communication</title>

<para>

FIXME

- decisions

- project modifications: APIs, documentations, teams, ...

- medias: IRC, mail, mailing-lists, web site, ...

</para>

</sect2>

<sect2>

<title>Code conventions</title>

<sect3>

<title>Design by contract</title>

<para>

FIXME

</para>

<para>

In debugging mode, always assert the contract.

</para>

</sect3>

<sect3>

<title>Code indentation</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>Language specific notes</title>

<sect4>

<para>

FIXME

</para>

<para>

Function names are lower case.

</para>

</sect4>

</sect3>

</sect2>

<sect2>

<title>Validation process</title>

<listitem><para>Audit</para></listitem>

<listitem><para>Optimize</para></listitem>

<listitem><para>Audit</para></listitem>

<listitem><para>Think about possible features</para></listitem>

<listitem><para>If globally accepted, add selected features</para></listitem>

<listitem><para>Audit</para></listitem>

</orderedlist>

</sect2>

</sect1>

<sect1>

<title>Development tasks</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>

<sect2>

<title>Global tasks</title>

<sect3>

<title>Communication</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>Programming interfaces</title>

<para>

FIXME

</para>

</sect3>

</sect2>

<sect2>

<title>Cooperation tasks</title>

<sect3>

<title>Documentations</title>

<para>

FIXME

</para>

</sect3>

</sect2>

<sect2>

<title>Low-level applications</title>

<sect3>

<title>Assembler</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>C compiler</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>Micro-kernel</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>C library</title>

<para>

FIXME

</para>

</sect3>

</sect2>

<sect2>

<title>System applications</title>

<sect3>

<title>General purpose services</title>

<para>

These applications only require their application engines. For an easy and safe configuration, or monitoring, they may provide user interfaces though.

</para>

</sect3>

<sect3>

<title>Text mode toolkit</title>

<para>

FIXME

</para>

</sect3>

</sect2>

<sect2>

<title>End-user applications</title>

<para>

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.

</para>

</sect2>

<sect2>

<title>Graphics</title>

<sect3>

<title>Graphical server</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>Graphical mode toolkit</title>

<para>

FIXME

</para>

</sect3>

</sect2>

<sect2>

<title>Services</title>

<sect3>

<title>General purpose daemons</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>Networking daemons</title>

<para>

FIXME

</para>

</sect3>

<sect3>

<title>User interfaces</title>

<para>

The only essential part of these services is their application engines.

</para>

</sect3>

</sect2>

<sect2>

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

</sect2>

</sect1>

</chapter>

</book>