Copyright (C) 2010 Meng Sun <email@example.com>
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
A C++ implementation of
Small, Reliable, Compact, Object-Oriented, Portable RTOS(Real-Time Operating System)
with POSIX compatibility(*).
(*) To be discussed.
For both developers/contributors and users,
This project is providing an operating system, which can be run under any critical
environment, with reliability(**) and efficiency.
(**) WITHOUT ANY WARRANTY
In order to provide a small system, there is no planning to support user interface
or file system at this moment. Those fancy functionality will be provided in the
future and in module's style. Now, you can consider this operating system looks
the same as a static-linked library.
For developers/contributors *ONLY*,
In order to achieve this target, I hope all developers(contributors) working on
Please move your editor's cursor forward carefully and seriously. In China there
is an idiom says "A journey of a thousand miles always starts beneath under
your current feet". Let's start our steps firmly, and keep it firmly in the future.
Here are also other important points should be kept in mind:
1) Documents have the same importance as source code.
2) For every task, document and discussion should be placed prior than coding.
3) Put users in center location, not us developers.
4) Use graphics in project document for illustration. It's much more
easier to understand than text, at lease from my own viewpoint.
5) Basic structure of this project should NOT be changed quite fast and quite
often. Maybe you said this point violates freedom. But "Freedom" means one
has freedom to do anything, meanwhile he/she shouldn't stop others' freedom.
If we change our structure frequently, who will protect our users' freedom?
6) Keep our dependency list as short as possible. Try to find the most reliable
and stable dependency packages. Even though in the future we will empty our
dependency list for security reason and maintenance effort.