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.
Managarm: Pragmatic microkernel-based OS with asynchronous I/O
31–40 of 63 posts
Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O
#32Very 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 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.
Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O
#33Earlier quoted context omitted.
> Part of the blame for that undoubtedly rests on Microsoft’s incompetence at documenting concepts I mean Charles Petzold did that so successfully redoing it would be superfluous
Kind of. He stops somewhat short of admitting that Win16/32 windows are objects and their graphical representation is mostly incidental. That’s not a bad thing—the book is introductory on many topics, in a good way, and just dropping such an idea somewhere in the beginning portions would be more confusing than helpful for the intended audience. That audience would almost certainly not be helped by the observation tha…
Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O
#34Earlier quoted context omitted.
Kind of. He stops somewhat short of admitting that Win16/32 windows are objects and their graphical representation is mostly incidental. That’s not a bad thing—the book is introductory on many topics, in a good way, and just dropping such an idea somewhere in the beginning portions would be more confusing than helpful for the intended audience. That audience would almost certainly not be helped by the observation tha…
Completely amazed that you could write this comprehensive reply just like that.
Windows’s, well, windows as a object/concurrency system are one (even if the Win32 transition to multithreading is IMO conceptually botched). The actor model admittedly already existed at that point, but Mark Miller et al.’s work on E (the only other source I know for having separate synchronous and asynchronous sends) hadn’t even started at that point. (There are innumerable papers on various versions of actors, though, so I might have missed it.)
COM aggregation is another. It would probably have been much more successful had they used fat pointers, and there are a couple of old papers pointing this approach is a viable way to do implementation (as opposed to interface) inheritance. But I know of no precedent in the literature for the inside-out way WinRT builds its allegedly more conventional inheritance mechanism on it. (I guess I would’ve referenced BETA if I were writing a paper on it?)
DCOM’s “causality IDs” for reentrancy control are yet another. You can basically have calls to your object guarded by a recursive mutex whose ownership is passed along with any remote calls that that object itself makes. I’m not sure they are a good idea (recursive mutexes are perilous in the simplest of situations, and this is most definitely not one of those), but I’m almost certain it’s an original one.
That’s it, for now, but I’m almost certain I could find more, if only I knew where to look.
Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O
#35This is mostly a note to myself. 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…
Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O
#36people 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: - 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:…
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,…
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.
Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O
#37Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O
#38This is mostly a note to myself. 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…
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.
Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O
#39This is mostly a note to myself. 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…
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…
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.
Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O
#40Earlier quoted context omitted.
Kind of. He stops somewhat short of admitting that Win16/32 windows are objects and their graphical representation is mostly incidental. That’s not a bad thing—the book is introductory on many topics, in a good way, and just dropping such an idea somewhere in the beginning portions would be more confusing than helpful for the intended audience. That audience would almost certainly not be helped by the observation tha…
Completely amazed that you could write this comprehensive reply just like that.