Commit 3ed354ad authored by Ticki's avatar Ticki
Browse files

Merge pull request #36 from ogryzek/minor-edits

Minor edits to first 2 chapters
parents 1f500021 3451d5d5
How Redox compares to other operating systems
=============================================
We share quite a lot with quite a lot other operating systems.
We share quite a lot with quite a lot of other operating systems.
Syscalls
--------
......@@ -29,12 +29,12 @@ Having vastly smaller amounts of code in the kernel makes it easier to find and
It should be noted that the extra lines are simply based outside of kernel space, making them less dangerous, not necessarily a smaller number.
The main idea is to have components and drivers that would be inside a monolithic kernel exist in user space and follow the Principle of Least Authority (POLA). This is where every individual component is:
* Completely isolated in memory and as separate user processes.
* The failure of one component does not crash the other components.
* Allows foreign and untrusted code to not expose the entire system.
* Bugs and malware cannot spread to other components.
* Has restricted communication which each other.
* Doesn't have Admin/Super-User privileges.
* Completely isolated in memory and as separate user processes
* The failure of one component does not crash other components
* Allows foreign and untrusted code to not expose the entire system
* Bugs and malware cannot spread to other components
* Has restricted communication with other components
* Doesn't have Admin/Super-User privileges
* Bugs are moved to user space which reduces their power
All of this increases the reliability of the system significantly. This would be useful for mission-critical applications and for users that want minimal issues with their computer systems.
......@@ -10,15 +10,17 @@ The goals of Redox
We want to be able to use it, without obstructions, as a alternative to Linux on our computers. It should be able to run most Linux programs with only minimal modifications.
We're aiming towards a complete, safe Rust ecosystem. This is a design choice, which hopefully improves correctness and security (see `Why Rust?`).
We're aiming towards a complete, safe Rust ecosystem. This is a design choice, which hopefully improves correctness and security (see [Why Rust]).
We want to improve the security design when compared to other Unix-like kernels by using safe defaults and disallowing insecure configurations where possible.
The non-goals of Redox
----------------------
We are not a Linux clone, or POSIX-compliant, nor are we crazy scientists, who wishes to redesign everything. Generally, we stick to the well-tested and proven correct designs. If it ain't broken don't fix it.
We are not a Linux clone, or POSIX-compliant, nor are we crazy scientists, who wish to redesign everything. Generally, we stick to well-tested and proven correct designs. If it ain't broken don't fix it.
This means that a large number of standard programs and libraries will be compatible with Redox. Some things that do not align with our design decisions will have to be ported.
The key here is the trade off between correctness and compatibility. Ideally, you should be able achieve both, but unfortunately, you can't always do so.
[Why Rust]: why_rust.html
Why Redox?
==========
A natural question this raises is: why do we need yet another OS? There are plenty out there already.
A natural question this raises is: Why do we need yet another OS? There are plenty out there already.
The answer is: you don't. No-one _needs_ an OS.
The answer is: You don't. No-one _needs_ an OS.
Why not contribute somewhere else? Linux? BSD? MINIX?
-----------------------------------------------------
......@@ -17,7 +17,7 @@ Take Linux for example:
- Legacy until infinity: Old syscalls stay around forever, drivers for long-unbuyable hardware stay in the kernel as a mandatory part. While they can be disabled, running them in kernel space is unnecessary, and can be a source of system crashes, security issues, and unexpected bugs.
- Huge codebase: To contribute, you must find a place to fit in to nearly _25 million lines of code_, in just the kernel. This is due to Linux's monolithic architecture.
- Restrictive license: Linux is licensed under GPL2, preventing some use cases that we would like to allow. More on this in `Why MIT?`.
- Restrictive license: Linux is licensed under GPL2, preventing some use cases that we would like to allow. More on this in [Why MIT?].
- Lack of memory safety: Linux has had numerous issues with memory safety throughout time. C is a fine language, but for such a security critical system, C is difficult to use safely.
### BSD
......@@ -26,24 +26,26 @@ It is no secret that we're more in favor of BSD, than Linux (although most of us
BSD isn't quite there yet:
- It still has a monolithic kernel. This means that a single buggy driver can crash, hang, or, in worst case, cause damage to the system.
- It still has a monolithic kernel. This means that a single buggy driver can crash, hang, or, in the worst case, cause damage to the system.
- The use of C in the kernel makes it probable to write code with memory safety issues.
### MINIX
And what about MINIX? It's microkernel design is a big influence on the Redox project, especially for reasons like [reliability](http://wiki.minix3.org/doku.php?id=www:documentation:reliability). MINIX is the most in line with Redox's philosophy. It has a similar design, and a similar license.
And what about MINIX? Its microkernel design is a big influence on the Redox project, especially for reasons like [reliability](http://wiki.minix3.org/doku.php?id=www:documentation:reliability). MINIX is the most in line with Redox's philosophy. It has a similar design, and a similar license.
- Use of C - again, we would like drivers and the kernel to be written in Rust, to improve readability and organization, and to catch more potential safety errors. Compared to monolithic kernels, Minix is actually a very well-written and manageable code base, but it is still prone to memory unsafety bugs, for example. These classes of bugs can unfortunately be quite fatal, due to their unexpected nature.
- Lack of driver support - MINIX does not work well on real hardware, partly due to having less focus on real hardware.
- Less focus on "Everything is a File" - MINIX do focus less on "Everything is a File" than various other operating system, like Plan9. We are particularly focus on this idiom, for creating a more uniform program infrastructure.
- Less focus on "Everything is a File" - MINIX does focus less on "Everything is a File" than various other operating systems, like Plan9. We are particularly focused on this idiom, for creating a more uniform program infrastructure.
The Need for Something New
--------------------------
We have to admit, that we do like the idea of writing something that is my own (Not Invented Here syndrome). There are numerous places in the MINIX 3 source code where I would like to make changes, so many that perhaps a rewrite in Rust makes the most sense.
We have to admit, that we do like the idea of writing something that is our own (Not Invented Here syndrome). There are numerous places in the MINIX 3 source code where I would like to make changes, so many that perhaps a rewrite in Rust makes the most sense.
- Different VFS model, based on URLs, where a program can control an entire segmented filesystem
- Different driver model, where drivers interface with filesystems like network: and audio: to provide features
- Different file system, RedoxFS, with a ZFS implementation in progress
- Userspace written mostly in Rust
- Orbital, a new GUI
[Why MIT?]: why_mit.html
......@@ -20,7 +20,7 @@ Our [BDFL](https://en.wikipedia.org/wiki/Benevolent_dictator_for_life) is [Jackp
- [Magnet](https://github.com/redox-os/magnet): The package manager.
- [Sodium](https://github.com/redox-os/sodium): The text editor of Redox.
- [The implementation of ZFS](https://github.com/redox-os/zfs): ZFS for Redox (originally written by [Tedsta](https://github.com/tedsta))
- [libextra](https://github.com/redox-os/libextra): Stuff libstd lacks of.
- [libextra](https://github.com/redox-os/libextra): Stuff libstd lacks.
- [Binutils](https://github.com/redox-os/binutils): Utilities for manipulating binary files.
- [Extrautils](https://github.com/redox-os/extrautils): Extra utilities for Redox.
- [games-for-redox](https://github.com/redox-os/games-for-redox): Funsies.
......
......@@ -22,7 +22,7 @@ We also have three utility distributions, which are collections of small, useful
What tools for fitting in the Redox distribution?
-------------------------------------------------
Some of these tools will in the future be moved out of the default distribution, into seperate optional magnet packages. Example of these are Orbital, OrbTK, Sodium, and so on.
Some of these tools will in the future be moved out of the default distribution, into seperate optional magnet packages. Examples of these are Orbital, OrbTK, Sodium, and so on.
The listed tools fall into three categories:
......@@ -30,7 +30,7 @@ The listed tools fall into three categories:
2. Tools, which are "nice" to have and are inherently simple.
3. Tools, which are there for establishing consistency within the ecosystem.
The first category should be obvious: an OS without certain core tools is an useless OS. The second category contains the tools which are likely to be non-default in the future, but nonetheless are in the official distribution right now, for the charm. The third category is there for convenience: namely for making sure that the Redox infrastructure is consistent and integrated (e.g., Magnet, OrbTK, and libextra).
The first category should be obvious: an OS without certain core tools is a useless OS. The second category contains the tools which are likely to be non-default in the future, but nonetheless are in the official distribution right now, for the charm. The third category is there for convenience: namely for making sure that the Redox infrastructure is consistent and integrated (e.g., Magnet, OrbTK, and libextra).
It is important to note we seek to avoid non-Rust tools, for safety and consistency (see [Why Rust]).
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment