|Name||Modified||Size||Downloads / Week|
|Totals: 5 Items||138.3 kB||18|
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!