A completely-from-scratch hobby operating system
github.com
github.com
Strange, but welcome, to see it on the frontpage! :)
Still kind of amazes me that given the number of signatories I got nobody thought "hey, maybe this isn't going to work" but it turned into an excellent mutual support resource for those of us moving instead: https://gist.github.com/shadowcat-mst/998cea12794768bdb3da2d...
https://github.com/klange/toaruos/tree/9f34619078f92bd7d9815...
I wonder if the web server is hosted on toarus?
My intended audience is hobbyists who are looking for a reference for writing their own OS - the sort of people we often find on osdev.org, or the #osdev channel on Libera, who have stumbled through an old tutorial on x86 bring-up and want some example of how "the next steps" work.
And why we are there, why not a safer microkernel, keeping everything in userspace? Questions over questions.
Also signals. With a microkernel you won't need signals
It depends on the goal. If you want to compile pre-existing software for it, or if you want to really "start anew".
But at the same time, it does make me sad that most hobby OSes end up seeking POSIX compatibility, because that means being destined to essentially either be another unix-variant or develop a unix-variant inside some subsystem of your OS.
Yes, being unix-like means you gain access to a trove of software and libraries that makes porting applications much easier, but it also limits the potential be truly different and experiment, as your end result will look like "yet another unix" with misc. improvements.
Since I think the enjoyment of building something like this comes from the satisfaction of building an OS from the ground up, I don't think it matters, but it would be cool to see more hobby OSes try more exotic ideas and runtimes.
Because existing desktop applications can be ported to ToaruOS
>why not a safer microkernel, keeping everything in userspace?
This is a design choice, microkernels aren't necessarily better than hybrid, they're slower, harder to debug and process management can be complicated
The current #1 (Fugaku) uses IHK/McKernel as kernel for the actual payload. The previous #1 (IBM Summit) seems to use RH Linux though. Perhaps, since the most performance critical part is run by and within the GPGPU(s), the actual OS doesn't matter all that much (for performance -- it matters of course for programmer's comfort/efficiency).
Full disclosure: I maintain QNX toolchain.
If you want to support the lion's share of desktop applications, it would actually be better to implement the Win32 API...
Any other OS recommendations base on my ignorant, but wishful, reqs above? I realize there are some others in Rust too. Thanks!
Nevertheless, the first thing after defining a new OS interface must be writing a POSIX API translation layer, to be able to use without modifications the huge number of already existing programs.
Writing a new OS is enough work, nobody would have time to also write file systems, compilers, a shell, a text editor, an Internet browser and so on.
After having a usable environment, one can write whatever new program is desired, which would use the new native OS interface, but it would not be possible to replace everything at the same time.
Besides having a POSIX translation layer, which can be written using as a starting point one of the standard C libraries, where the system calls must be replaced with the translation layer, some method must be found for reusing device drivers made for other operating systems, e.g. either for Linux or for one of the *BSD systems.
Nobody would have time to also write all the needed device drivers. So there must exist some translation layer also for device drivers, maybe by running them in a virtual machine.
The same as for user applications, if there is special interest in a certain device driver, it should be rewritten for the new OS, but rewriting all the device drivers that could be needed would take years, so it is important to implement a way to reuse the existing device drivers.
> So there must exist some translation layer also for device drivers, maybe by running them in a virtual machine.
> ... but rewriting all the device drivers that could be needed would take years, so it is important to implement a way to reuse the existing device drivers.
I'd think most people making a hobby OS specifically want to do these things.
I also think most don't care about wide hardware compatibility.
The volume of work for rewriting all these is many times larger than writing from scratch all the core of a new OS.
Rewriting them requires studying a huge amount of documentation and making experiments for the cases that are not clear. Most of this work is unlikely to present much interest for someone who wants to create an original OS, so avoiding most of it is the more likely way leading to a usable OS.
Not every hobby OS needs or even wants networking, gpu support, even storage I/O, etc. See TempleOS.
The goal typically isn't to make a fully featured OS.
For dedicated embedded computers, the purpose for an OS becomes completely different and compatibility with anything does not matter any more.
Not only personal computers cannot be used without a huge amount of device drivers, but even for a very simple server, e.g. an Internet gateway/router/firewall or a NAS server, the amount of work for writing the device drivers, the file systems and the networking part would be much more work than writing the core of a new OS.
Only for embedded computers the work needed for device drivers can be smaller than for the base operating system.
I disagree. POSIX sucks. Build a hypervisor so people can run their applications in a VM and insist that native programs use the non-garbage API. It's the only way you'll ever unshackle yourself.
If you do all your normal work in a virtual machine, what will you use your new OS for?
Writing any useful application program in a complete void, without standard libraries and utilities, would take a very long time and unless it is something extremely self contained it would not be as useful as when it can exchange data with other programs.
It is much easier to first write a new foundation, i.e. the new OS, with whatever novel ideas you might have for managing memory, threads, security and time, and then start to use the foundation with the existing programs, hopefully already having some benefit from whatever you thought you can improve in an OS (e.g. your new OS might be impossible to crash, which is not the case with any of the popular OSes), and then replace one by one the programs that happen to be important for you and that can benefit the most from whatever is different in the new OS.
For the vast majority of programs that you might need from time to time it is likely that it would never be worthwhile to rewrite them to use the native interfaces of the new OS, but nonetheless you will be able to use them directly, without having to use complicated ways to share the file systems, the clipboard, the displays and whatever else is needed with the programs run in a virtual machine.
Implementing some good methods for seamless sharing of data between 2 virtual machines, to be able to use together some programs for the new OS with some programs run e.g. in a Linux VM, is significantly more difficult than implementing a POSIX translation layer enabling the C standard library and other similar libraries to work on the new OS in the same way as on a POSIX system.
You write replacements for or properly port your every-day workflow to the new OS. You already wrote a whole new OS for some reason even though there are hundreds to choose from, presumably there is value in replacing your tools to take advantage of whatever you put all that effort into or else why bother? The VM is for things you haven't ported yet or less important workflows.
Besides, people run windows and do all their work in WSL all the time.
> Writing any useful application program in a complete void, without standard libraries and utilities, would take a very long time [...]
So does writing an OS and you've already decided that was worth the effort, yet you balk at rewriting some commandline utilities[0] and a standard library? Please.
> It is much easier to first write a new foundation [...] then start to use the foundation with the existing programs [...] and then replace one by one the programs that happen to be important for you and that can benefit the most from whatever is different in the new OS.
Any reason not to just do that with a VM? Forcing POSIX compatibility into your OS is going to constrain your choices (not to mention your thinking) to the point that you'd probably be better off just modifying an existing OS anyway.
> For the vast majority of programs that you might need from time to time it is likely that it would never be worthwhile to rewrite them to use the native interfaces of the new OS, but nonetheless you will be able to use them directly, without having to use complicated ways to share the file systems, the clipboard, the displays and whatever else is needed with the programs run in a virtual machine.
A: it isn't that complicated. B: if you can use them so directly without having to deal with the separation provided by a VM, it's likely you didn't improve their security situation anyway. Again, why not just modify an existing POSIX OS in this case?
> Implementing some good methods for seamless sharing of data between 2 virtual machines, to be able to use together some programs for the new OS with some programs run e.g. in a Linux VM, is significantly more difficult than implementing a POSIX translation layer enabling the C standard library and other similar libraries to work on the new OS in the same way as on a POSIX system.
I doubt it is as hard as, say, writing a brand new OS that's actually in some way useful. Why go through the effort of the latter only to throw away a bunch of potential by shackling yourself with a set of barely-followed standards from the 1970s?
[0] POSIX does nothing to help you with anything GUI.
For an example of how things like this can be done incrementally, you can look at io_uring on linux.
it looks pretty cool, although the url thing seems yet to prove its utility. they seem to be playing around a bit with using the protocol component (net, disk, etc), but it's unclear what this adds over just using paths. although maybe if they used the protocol to describe the encoding of the data, it would add something?
I was basically on board, but how are they harder to debug? I'd think being able to run components in userspace would make debugging way easier.
[0] possibly resorting to UML, but still
...
Other interesting alternatives to c or rust might be vlang or zig.
As for the microkernel bit, this might sound like circular reasoning but I didn't go for a microkernel because no one really uses microkernels. It's not that I think microkernels are a bad idea, ToaruOS does push plenty of stuff into userspace. Rather, my main goal at the moment is to provide an educational resource that more accurately models the way "real" OSes work than the typical academic OS projects.