My operative system programmed in Rust from scratch and without crates
Go to file
ShyanJMC 99a75bf9e7 Added rune manual and deleted other files because I will change the organization of many documentations. 2023-11-12 10:31:29 -03:00
.github Create FUNDING.yml 2023-02-24 06:55:07 +00:00
Documentation Added rune manual and deleted other files because I will change the organization of many documentations. 2023-11-12 10:31:29 -03:00
images New assets 2023-10-01 12:11:22 -03:00
source_code Rune - minor change for _list and _help. No enhances or fixes. 2023-11-12 10:17:09 -03:00
.gitignore show v0.8.0, ls v0.4.0, libstream 0.1.0 and libconfarg 0.1.0 2022-10-03 01:21:51 -03:00
COPYING Added GPL v3.0 license 2022-10-22 11:38:32 -03:00
LICENSE Added GPL v3.0 license 2022-10-22 11:38:32 -03:00 README - Update to latest version 2023-10-01 12:11:39 -03:00


Image created with Stable Diffusion 2.1

RanvOS, (from norwegian; raven), is a operative system programmed in Rust. Aims to be; minimal, stable, secure and modern ( this maybe you know as; state-of-art ).

Is my personal project to make from scratch an operative system, take this project as a hobby, nothing professional.


The objetive of RavnOS is make an operative system minimalist, self hosted, stable and secure.

Think in this situation; you are in a wood or in another place, working with critical systems and without the time or resources to fix issues in the compilation process or fixing regretion issues. RavnOS fix that isolating the system and the user parts.


Huginn v0.1.0
Rune v0.43.19
Search v0.6.1

Run over existing OS

To run the system over an existing OS, the kernel must have support for POSIX (specially file, vector, hashmap and threads).


The pillars of RavnOS are;

  • Minimalism

Nothing of bloatware inside the code or system. Just the necessary to do the job (maximum viable product).

Also the minimalism affects the system's scope, check that point.

  • Stability and security over features

Will have absolute priority the stability and security of the system over X feature.

  • Isolation and portability

Each part of system must be portable over Rust supported platforms.

Each part of system must be self hosted, no external crates (over internet) are allowed. All must be local, how can you be sure that the remote dependency is secure? how can you be sure that the remote dependency will be developed to the end of times? how can you be sure that the remote dependency will not break the compatibility?

Each part of system distributed in binary form must be done as static, at 2022 the best way for this is use MUSL standard C library.

  • Keys - Data

The information is printed in screen and worked with syntax;

[key] {

This allow work with data grouped by keys and avoid issues trying to extract data when it have "", '', \, \, and others characters.

  • OS Image - Container

The final distribution must use the 'OS image' schema; the base system is immutable and the mutable part is used trough containers schema.


  • Rustc

  • A terminal

  • Cargo with the target toolchain you want/need:

    This is not mandatory but will help you to build with one just command.

  • Musl target:

    This is not mandatory, but I recommend it to build as static. MUSL only is available for linux, for the rest use glibc.


The versioning schema for releases follows Semantic Versioning v2 ( ), here a resume;

Given a version number MAJOR.MINOR.PATCH, increment the:

    MAJOR version when you make incompatible API changes
    MINOR version when you add functionality in a backwards compatible manner
    PATCH version when you make backwards compatible bug fixes

Additional labels for pre-release and build metadata are available
as extensions to the MAJOR.MINOR.PATCH format.

A change from early development is; each MINOR version also indicate each new / existing feature inside internal programs. And performance patches go to "PATCH" section instead "MINOR" section.

With this versioning schema you know that whiting each MAJOR version the system is always compatible with the oldest versions.


The files with documentation (like features, issues, etc) are;

  • Documentation/

Contains information about each program and features.

  • Documentation/

Contains information about each patrons in each month.

  • Documentation/

Contains information about each issue fixed.

  • Documentation/

Contains information about each system part.


Right now the OS is in alpha, so right now you can only test it another OS.

There are two ways for build RavnOS. ;

  • Cargo

Remember replace; [x86_64/aarch64] and [linux/windows/etc] for your case.

I recommend use this configuration inside "~/.cargo/.config";

target= "[x86_64/aarch64]-unknown-linux-musl"
rustflags = ["-C","opt-level=2","-C","debuginfo=0","-C", "target-feature=+crt-static","-C","target-cpu=native"]

Add the target built with musl;

rustup target add [x86_64/aarch64]-unknown-[linux/windows/etc]-musl

To build;

cargo build --release --target [x86_64/aarch64]-unknown-[linux/windows/etc]-musl

All binaries will be in "target/[TARGET]/release".

If you have space requirements, do "strip" to the final binaries. This is because even with "--release" target I still found debug symbols in the final binary.

  • Rustc

For each RavnOS's lib you must first build them as object file and then can be used inside compilation process;

rustc --crate-type=rlib --crate-name libconfarg [PATH_TO_LIBCONFARG]/src/ -o libconfarg.rlib
rustc --crate-type=rlib --crate-name libstream [PATH_TO_LIBSTREAM]/src/ -o libstream.rlib
rustc --crate-type=rlib --crate-name libfile [PATH_TO_LIBFILE]/src/ -o libfile.rlib

Then you can link into the binary build;

rustc --target=[x86_64/aarm64/etc]-unknown-[linux/windows/etc]-musl -C opt-level=2 -C target-feature=+crt-static --extern libconfarg=libconfarg.rlib --extern libfile=libfile.rlib --extern libstream=libstream.rlib [COMPONENT]/src/ -o [final_name]

with above command, you will the final binary of [COMPONENT] in static final form (aka; statically linked) with optimization level 2 and specific libs (crates).

As with cargo, I recommend do "strip" to the final binaries to delete debug symbols.

Before - After strip binary

Before strip;

f: ls 	[10/4/2023 10:44:0 UTC-0]	["sticky bit", "rwx", "r-x", "r-x"]	[uid=1000(shyanjmc) gid=1000(shyanjmc)] 4M

After strip;

f: ls 	[10/4/2023 10:49:11 UTC-0]	["sticky bit", "rwx", "r-x", "r-x"]	[uid=1000(shyanjmc) gid=1000(shyanjmc)] 542K

The strip command clean the debug symbols, which are the 86.45% of space.


I, Joaquin Manuel 'ShyanJMC' Crespo, am the main developer and creator of this project.

  • 2023-02-13; I have the signed copyright disclaimer agreement with my employer in which they (the company) waive the copyright on this.

  • 2023-02-13; I am in the process of registering the software at my name in República Argentina.

  • 2023-03-13; This project is registered in República Argentina at my name.


RavnOS and all parts are licensed under GPLv3.


If you want contact me, you can do it trough:



Contributions and support

For now I am the main and only dev in this project, maybe in the future I will allow collaborations.

If you want support this project you can;

Join my patreon;

Donate me crypto;

  • DAI (ERC-20) - The preferred stablecoin;


  • Bitcoin (BTC);


  • Ethereum (ETH);


And if you know me personally, let me know that you have donated, since that moment we will share a beer (or mead if you are man/women of honor).