Cloudium OS Files

I   Introduction
Cloudium OS is being written in pure ASM, designed for speed and ease.
Having cloud computing in mind. It also is secure (without requiring constant user input
like Windows).
But, how are we going to do this? Well every os wants/says these kind of things, so to
accomplish our goals we follow these simple rules: keep it simple (that's way better then
these complex interfaces etc. almost nobody wants), generalize (this makes things easier
and more useful without extra complexity), be inventive (sometimes doing it the classical
way just doesn't work).



II  How To Install/Run Cloudium OS
To run Cloudium OS, you need an application to burn the disk-image to a CD/DVD and
then configure your BIOS/(U)EFI to boot from it. Once Cloudium has booted up you can play
around with it, but currently it doesn't feature an installer. But you can use more
professional disk utilities to copy it to a partition on your harddrive wich is currently
equivalent to installing it, however this isn't recommended as Cloudium OS is still in 
pre-alpha.



III Version History
Here are given in the following order: the full version number, the linear development
version number and the short description of changes that have been made. Also note that
only the OS version number are given, on whilst the kernel and boot-loader are versioned
separately.

A1.0.0	v01.0:	Basic boot loader made.
A1.0.2	v01.1:	New print string functionality
A1.0.3	v02.0:	Added simple debugger
A1.0.4	v02.1:	Removed all messy code
A1.0.5	v02.2:	Bugfix release
A1.0.6	v02.3:	Changed the debug architecture
A1.0.7	v02.4:	Renewed whole bootloader architecture + save DL to RAM (bootdrive number)
A1.0.8	v03.0:	Added new enable_a20 routine + gathers more envoiremental info
A1.0.9	v03.1:	Improved debugger and boot progress reporter.



IV	Planning / Milestones
The versioning is organised in two parts: the developer part and the part visible to the
end-user. The part visible to the end user is never touched because of a new development
version. For example: version 4.4 will never become 4.5 because of a new beta. The format
is this: PHASE + MAJOR + MINOR + RELEASE VERSION. And for the end user it's like this:
MAJOR + MINOR. The phase is either P (pre-alpha), A (alpha), B (beta),
R (release canidate) or F (final release). Counting starts from zero exept for the major
version number. For each version, goals are set, and we only progres to a new version once
these goals are met reather then releasing based on a time interval. The planning is
organized per planned milestone:

Milestone I: Booting [DONE]
A1.0.0
Boot-loader: A1.0.14 (basic functionality, able to bootstrap os)
Kernel: MikeOS (for testing only) / Nucleo A1.0.6 (dummy kernel)

Milestone II: Basic Kernel Functionality [DONE]
A1.0.17
Boot-loader: B1.0.1 (improved functionality, detects extra hardware feautres etc...)
Kernel: Nucleo A1.0.18 (IPC + VM)

Milestone III: Full Kernel Functionality [CURRENT GOAL]

Milestone IV: First Processes

....  More to come!