Live data from Hacker News

Managarm: Pragmatic microkernel-based OS with asynchronous I/O

github.com

31–40 of 63 posts

Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O

#31
post #17

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 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

#32
post #31
post #17

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 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.

Awesome. How is the overall experience?

Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O

#33
post #14

Earlier 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…

Thanks for debunking my answer so comprehensively. Cannot disagree.

Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O

#34

Earlier 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.

I guess I’m just a bit obsessed with Golden Age Microsoft, having grown up during that time without understanding much of what was going on. My original point, though, was that they had some very nice, perhaps thesis-chapter-worthy points that ended up buried in the specifics of (and on more than one occasion, in the same grave as) their products.

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

#35

This 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…

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.

Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O

#36
post #26

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: - 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,…

> 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.

Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O

#38

This 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 in the day this is what i would have wished for.

Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O

#39

This 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…

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.

Re: Managarm: Pragmatic microkernel-based OS with asynchronous I/O

#40

Earlier 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.

Agreed. It is a tour de force.
Post reply on HN