Very neat project! It appears to run on qemu. Can someone tell me at the 30,000' view what's required to get it running on actual hardware? I'm imagining something like signed boot manager, hard disk drivers, etc. They seem to have a ton of USB stuff working which seems amazing to me, but I've been out of the low-level PC loop for a couple decades and don't know what prevents working on bare metal in 2024.
I've got a hobby OS that runs on real hardware (sometimes, on some hardware). Mostly it's just patience and debugging effort to get things going. qemu defaults to doing some things quickly instead of accurately, so it's easy to do things wrong as an OS and if you don't test regularly, you can end up with a lot of breakage.
I don't have a boot manager, my OS is multiboot compatible, so I can boot with qemu's multiboot support or PXElinux, or grub or whatever. IMHO, with the multiboot standard, there's no need to write a boot loader if you want to build an OS, and no need to write an OS if you want to build a boot loader.
Looks like this OS has a good selection of storage drivers, so should be good to go there.
At 30,000' I'm not seeing anything that would prevent this from booting on hardware. It seems to have a reasonable complement of modern, real-world drivers. On the other hand, physical hardware tends to have bugs, quirks and diversity that VMs don't have, so hobby operating systems may have trouble with it if they aren't tested on it.
I have managarm installed on a partition on my testing ThinkPad. The steps needed to get it set up were creating the partition, copying over the sysroot, and adding an entry to my grub configuration.
Theoretically, since it has a few real world drivers, it may be possible to run on real world hardware, but in practice, Managarm tends to get hung up very low level, at Eir or Thor (the two components of the microkernel). Since basically all the testing is currently done on QEMU, real world testing isn't really a thing for Managarm
Is this a hobby project or intended for real applications? How does it compare performance-wise to Minix 3 or the L4 family (one of which, Hazelnut, was also written in C++)?
people always say that C++ is not a good fit for kernels, but so far this is the only language I know where small teams or individuals are regularly able to create non-trivial hobby OSes from scratch that go from zero to GUI:
Hi, author of axle here - thank you for the shout out! It’s been a wonderfully fun and enriching project to work on over the years. I’m now working on XNU at Apple, so won’t be working further on axle for the foreseeable future.
Is the kernel really the differentiator there? seL4 is a Proven microkernel that is some 9000 lines of C. This ancient SO post[0] claims Linux is 140k lines. The kernel is just a tiny component of the many things required to get an OS up and running. I suspect most projects just peter out as the enormity of the complexity becomes apparent.
You are seeing a creation date bias. And it doesn't help that there just aren't that many systems programming languages.
Until Rust in 2010, there basically was almost no motion in the "system programming space". Even afterward, there needs to be enough uptake to actually have critical mass. Only then can people start using it for projects.
Side note: D actually predates a lot of this by being from 2001, but, sadly, never seemed to get any traction. It seems like it had the misfortune of being about 10 years too early and that programmers just weren't ready for a new systems programming language at that point.
> Side note: D actually predates a lot of this by being from 2001, but, sadly, never seemed to get any traction. It seems like it had the misfortune of being about 10 years too early and that programmers just weren't ready for a new systems programming language at that point.
I was only a kid starting my university degree at that time, but I had been coding since I was 9 and I was very excited about D. What I remember is that getting it up and running was a cumbersome, fully manual process. The compiler was closed-source, delivered as a tarball without any kind of installation script, ditto for the libraries. I wrote some little programs and I liked the language, but in the end I gave up.
On the other hand, Rust has rustup and Cargo which are just amazing. I am sure that a big part of Rust's popularity comes from Cargo.
There have been a number of OS-type systems in Ada/SPARK, though at least mainly in the embedded space. E.g. the Muen verified separation kernel: https://muen.sk/
The two counter-examples I can think of with plain C:
* GTK+, though honestly speaking I think quality has dipped over the decades where C++ equivalents have flourished.
* Old school Win32 style. Counter to the bad reputation, I find it easy to be productive with in plain C once you adjust your mental model to its expectations. Though it's probably better from C++ than C, for a few convenience features to reduce boiler plate.
Old Win32 style received less attention than it deserves, I think. It's an object system in its own right—a Smalltalkish one, at that, with an (admittedly muddled) E-style separation of synchronous and asynchronous calls!—but one rarely sees it mentioned in the same sentence as Objective-C, C++, and GObject/Vala. Part of the blame for that undoubtedly rests on Microsoft’s incompetence at documenting concepts, but whatever the causes I’d definitely like to see that corner of the object-system design space explored more, with or without GUIs.
OOP is especially good for making UI toolkit. If you look at GTK+ and Win32 closely, you’ll notice that they all sport some kind of a homegrown class system, complete with inheritance and polymorphism.
It’s popular to dunk on OOP and its concepts nowadays, but I think that languages that straight away shun them because “OOP sucks” are an example of their authors overreacting to OOP’s dominance back in 1990s-early 2000s and tendencies to shove OOP into every nook and cranny, with a notion that if you don’t do it, or do not enough of it, your solution is inferior.
Holy hell. Linux kernel is object-oriented. Because it’s damn convenient for a lot of things.
It's probably more accurate to say that C++ devs are more common than C devs, and they are more interested / motivated to create operating systems than programmers in other languages. It has little to do with C++ as a language.
It's interesting to consider "what next" once an OS project reaches this stage. There are soo many directions a team can take, but also, none of those direction lead to a clear path towards massive user adoption.
There are obvious holes/gaps in what mainstream OSes offer today, however it is not clear how a project goes from here to addressing those gaps, and even if those were to be addressed, it is not clear how it could displace mainstream OSes.
We are clearly better off having projects like this, that give us options in case something were to go horribly wrong with mainstream OSes. However, what is the incentive to keep projects like this alive when the path ahead is soo unclear?
How does one disrupt the operating systems market?
Motor OS (https://motor-os.org) attempts to do exactly that, by focusing on a rather narrow, from a "mainstream OS", point of view, niche. Kind of "do this one thing better" approach.
rather than displace mainstream os's what id rather have is some way to easily switch os depending on my task, gaming? windows, anything else? linux (for now), and have that run directly on the hardware with little interference... like a meta task switcher os.
someone is going to come on here and tell me we already have this (i hope).
ive been out of computing for so long i dont know if this reliably exists, but back in the day this is what i would have wished for.
and since i dont trust windows to host my work os securely, and performance of games would be abysmal with the hosting roles reversed, what i really need is 2 boxes and a kvm switch!. the question now becomes, are there physical systems that turn on and off at the same time... i.e. share a psu but host different os's!
suppose i could build my own
am i looking at building a rack mounted system? heh, think i just found a project for myself.
1 psu, 1 gpu (for gaming), 1 kb/monitor, 2 hdd, 2 motherboards, 1 kvm switch, build my own rack out of wood, done! so the only extra cost really should be the 2nd motherboard and the kvm switch.
Readit News
I don't have a boot manager, my OS is multiboot compatible, so I can boot with qemu's multiboot support or PXElinux, or grub or whatever. IMHO, with the multiboot standard, there's no need to write a boot loader if you want to build an OS, and no need to write an OS if you want to build a boot loader.
Looks like this OS has a good selection of storage drivers, so should be good to go there.
Managarm: August 2022 Update - https://news.ycombinator.com/item?id=32515546 - Aug 2022 (3 comments)
The Managarm Operating System - https://news.ycombinator.com/item?id=24689727 - Oct 2020 (1 comment)
- Serenity (https://github.com/SerenityOS/serenity) - not really a small team, but it managed to get to GUI as pretty much a one-man-show
- Skift (https://github.com/skift-org/skift)
- hhu: https://github.com/hhuOS/hhuOS
- MaxOS: https://github.com/maxtyson123/MaxOS
- MorphiOS: https://github.com/syedtaqi95/morphiOS
- Macaron: https://github.com/MacaronOS/Macaron
- Ghost: https://github.com/maxdev1/ghost
most big ones in C don't manage to get to the GUI level, except toaruos: https://github.com/klange/toaruos
Axle[2] is a one-man project with a GUI that the author has been gradually transitioning from C to Rust.
Among C++ projects, I think Essence[3] also merits a mention.
[1] http://www.helenos.org/
[2] https://github.com/codyd51/axle
[3] https://gitlab.com/nakst/essence
[0] https://unix.stackexchange.com/questions/223746/why-is-the-l...
Until Rust in 2010, there basically was almost no motion in the "system programming space". Even afterward, there needs to be enough uptake to actually have critical mass. Only then can people start using it for projects.
Side note: D actually predates a lot of this by being from 2001, but, sadly, never seemed to get any traction. It seems like it had the misfortune of being about 10 years too early and that programmers just weren't ready for a new systems programming language at that point.
I was only a kid starting my university degree at that time, but I had been coding since I was 9 and I was very excited about D. What I remember is that getting it up and running was a cumbersome, fully manual process. The compiler was closed-source, delivered as a tarball without any kind of installation script, ditto for the libraries. I wrote some little programs and I liked the language, but in the end I gave up.
On the other hand, Rust has rustup and Cargo which are just amazing. I am sure that a big part of Rust's popularity comes from Cargo.
The two counter-examples I can think of with plain C:
* GTK+, though honestly speaking I think quality has dipped over the decades where C++ equivalents have flourished.
* Old school Win32 style. Counter to the bad reputation, I find it easy to be productive with in plain C once you adjust your mental model to its expectations. Though it's probably better from C++ than C, for a few convenience features to reduce boiler plate.
It’s popular to dunk on OOP and its concepts nowadays, but I think that languages that straight away shun them because “OOP sucks” are an example of their authors overreacting to OOP’s dominance back in 1990s-early 2000s and tendencies to shove OOP into every nook and cranny, with a notion that if you don’t do it, or do not enough of it, your solution is inferior.
Holy hell. Linux kernel is object-oriented. Because it’s damn convenient for a lot of things.
Deleted Comment
It's interesting to consider "what next" once an OS project reaches this stage. There are soo many directions a team can take, but also, none of those direction lead to a clear path towards massive user adoption.
There are obvious holes/gaps in what mainstream OSes offer today, however it is not clear how a project goes from here to addressing those gaps, and even if those were to be addressed, it is not clear how it could displace mainstream OSes.
We are clearly better off having projects like this, that give us options in case something were to go horribly wrong with mainstream OSes. However, what is the incentive to keep projects like this alive when the path ahead is soo unclear?
How does one disrupt the operating systems market?
someone is going to come on here and tell me we already have this (i hope).
ive been out of computing for so long i dont know if this reliably exists, but back in the day this is what i would have wished for.
suppose i could build my own
am i looking at building a rack mounted system? heh, think i just found a project for myself.
1 psu, 1 gpu (for gaming), 1 kb/monitor, 2 hdd, 2 motherboards, 1 kvm switch, build my own rack out of wood, done! so the only extra cost really should be the 2nd motherboard and the kvm switch.
Deleted Comment
Dead Comment