The little book about OS development
littleosbook.github.io
littleosbook.github.io
OS dev can be great fun and gives you a level of understanding about how computers actually work that is hard to gain from other sources. I have frequently found myself using the knowledge I gained from building the OS when working on other projects. It has been particularly useful when it comes to understanding performance issues. I would highly recommend it to anyone that is even remotely interested.
Other superb resources to help you get started include the OSdev wiki[1], along with this document[2] from the University of Birmingham, UK.
[0] http://www.hydros-project.org
[2] https://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures...
[1] https://en.wikipedia.org/wiki/High_availability#Percentage_c...
[2] https://en.wikipedia.org/wiki/Erlang_(programming_language)#...
In general, my experience has been that OS dev is a topic that is best approached through the study of a variety of different documents, simultaneously. For example, you would do well to read both the originally posted 'little book...', as well as the University of Birmingham text. Then it might be a good idea to look at the OSdev wiki pages for the specific tasks that you want to work on.
> but it seems dead and no one has taken the time to fix such issues
Unfortunately, there seem to be few /completed/, and high-quality texts available. It is certainly a shame that there is not a modern, high-quality book about OS development (that I know of), but the motivated student can certainly find the needed information. Good luck and have fun!
Two small notes: the website is down (it's quite old and I'd be sad if the owner has a bit of bus-syndrome), you can find it on the waybackmachine
It's the best tutorial out there for an x86 based OS
The website's working just fine for me, but in case it doesn't work for someone else or if it goes down again: https://web.archive.org/web/20161223021815/http://www.broken...
HTML version: http://littleosbook.github.io/
Source: https://github.com/littleosbook/littleosbook
2015 Discussion: https://news.ycombinator.com/item?id=8866912
reddit: https://www.reddit.com/r/programming/duplicates/2rx3wq/the_l...
Well an operating system talks to hardware and allocates resources, right? The motivation to write a non-toy operating system must be some strong ideas about how to do those things, and they'd have to be pretty fundamental to give up on the vast advantages of interoperability and pre-existing software that would come from just implementing your ideas on top of Linux or whatever.
Past motivations for writing OSes might be expressed as licensing (GNU/Linux), disagreements about fundamental architecture of operating systems (microkernels), need for hard real-time (vxWorks), or the belief that you have the sheer resources and market power to start again and build something better (Windows NT). Security seems like another likely motivation (There's probably a better example than OpenBSD because I don't think they started from scratch).
I quite like the idea that hardware intended for autonomy might benefit from being implemented on bare metal. Devices that AREN'T general-purpose computers, but communicate only with their own hardware and with the outside world by their actions and by communications protocols, well why shouldn't they run on a custom and highly stripped-down OS? You'd expect to get benefits in performance and a smaller codebase for potential security holes. But I don't think the industry is actually headed in that direction.
Some embedded OSes work by basically writing your application as an extension of the OS. So you're essentially running on bare metal there. Usually even for simple devices you want more than one thread/process....and then you start wanting OS stuff.
There's probably a better example than OpenBSD
Kaspersky's new OS is built for exactly that reason.
Also, for completeness, the osDev wiki has a list of OSes built for various reasons....some serious, some for research: http://wiki.osdev.org/Projects
How about some new idea that hasn't been tried before? Maybe you'll find a better way of doing things.
>Maybe I need to keep posting it when people ask these questions if it consistently has such an effect
That's what I do. It seems to usually work.
My unix box handles the day-to-day, but the future is coming, and I can't wait.
Additionally theres a few features I would prefer from a security user experience standpoint
- symlinks are indexed anD the move or deletion of the target would trigger a "would you like to change/delete the symlink as well?"
- all applications run in a container
- the application can never touch os filesystem or know about other apps but themself and what the user allows
- requests for hardware trigger permission dialog
- requests for files are handled outside the container
- shared folders are mounted to the container that the user knows are vulnerable
- some folders are an aggregate of the applications folders but the application only views its own
- deletion of an applications folder will permanently delete all if its data. No messy installations or artifacts
- system monitor shows cpu, memory and network usage per application
- applications require permission to use network and outward calls can be captured before being made
Additionally there are features from a dev standpoint
- there is a discoverability system for modified and alternative applications
- there is a focus on ensuring all parts of the os are easily found and modified
- changes to the os filesystem creates forces the user to create a virtual machine, make changes to that then "commit" those changes in bulk
- the user can make these patches available online along with keywords, problem and a tutorial inorder to recreate for discoverability
- heavy focus on user interfaces that can be reused in terminal and gui. Applications that only are available in one or have different experiences will be flagged as such.
But I canonly make this if I know how
Patch your coreutils. Difficulty: easy.
Most of your other needs can be addressed by making a specialized Linux distro (difficulty: hard), rather than writing a kernel that does all of this (difficulty: max). Build your packages to be containerized by default. I suggest using chroot containers and writing some kind of FUSE filesystem to mount in the container and provide controlled access to user files. You'll also want to write or modify a Wayland compositor to suit your needs. You can have this provide the permission prompts and similar things. Difficulty: hard, but very much doable.
Skills to learn: Linux, thoroughly. You should be comfortable making packages, running things in containers, and writing C before you embark on this.
You should definitely build this. I'm working on something similar but my design appeals to fewer people. Feel free to reach out to me if you have questions with anything, email is in my profile.
I guess writing a new kernal is more for rasberry pi/odroid/dev boards? In that case having a detailed explaination on it would be nice
https://github.com/beevik/MonkOS
In particular, the bootloader:
https://github.com/beevik/MonkOS/blob/master/boot/loader.asm
I included some other resources I consulted in the README. The OSDev wiki (http://wiki.osdev.org/Main_Page) is also good, although I found some of it to be dated or incorrect.
Good luck on developing your OS. Even though I'm not finished, it's been an extraordinarily valuable and educational process.
Thank you! Good luck with finishing yours, as though these things are ever finished :)
(Plus, a bunch of people there are interested in Rust, but only 1-2 with Rust OS projects, so your Rust expertise would be appreciated. ;-) )
You can find the partially developed but documented code here: https://github.com/mindentropy/s3c2440-mdk
The board I use is the mini2440 single board computer. You can bring up the same on a beagle bone with some minor modifications when you are dealing with the peripherals.