[HN Gopher] Show HN: Munal OS: a graphical experimental OS with ...
___________________________________________________________________
Show HN: Munal OS: a graphical experimental OS with WASM sandboxing
Hello HN! Showing off the first version of Munal OS, an
experimental operating system I have been writing in Rust on and
off for the past few years. https://github.com/Askannz/munal-os
It's an unikernel design that is compiled as a single EFI binary
and does not use virtual address spaces for process isolation.
Instead, applications are compiled to WASM and run inside of an
embedded WASM engine. Other features: * Fully graphical interface
in HD resolution with mouse and keyboard support * Desktop shell
with window manager and contextual radial menus * PCI and VirtIO
drivers * Ethernet and TCP stack * Customizable UI toolkit
providing various widgets, responsive layouts and flexible text
rendering * Embedded selection of applications including:
* A web browser supporting DNS, HTTPS and very basic HTML
* A text editor * A Python terminal Checkout the
README for the technical breakdown. Demo video:
https://streamable.com/5xqjcf
Author : Gazoche
Score : 296 points
Date : 2025-06-09 17:34 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| 9d wrote:
| This is _incredible_. I wonder if this will be the future of
| OSes.
|
| This readme is really, _really_ interesting to read through.
|
| Why did you use wasmi instead of wasmtime?
|
| I might actually try to use this OS inside a VM.
|
| Half of me wants to port my own reactive GUI lib to Munal.
| Gazoche wrote:
| Thanks! I tried to get wasmtime working but it was too much of
| a pain to compile in no_std mode, so I settled for wasmi
| instead.
| herobird wrote:
| Wasmi author here. Glad to see Wasmi being used in embedded
| contexts were it really shines. :)
|
| I just watched the demo video of Munal OS and am still in awe
| of all of its features. Really impressive work!
| 9d wrote:
| Yeah it's one of those projects were I'm so impressed that
| I'm saying nothing because there's nothing to say, it's
| just really impressive. I'm not sure what will come of this
| project, but it has a lot of potential to _at least_
| inspire other projects or spark important discussions
| around its innovations.
| Gazoche wrote:
| Thank you! And thanks for making Wasmi, it's a really
| impressive project and it's the reason why I decided to go
| this whole WASM sandbox route (because I could embed it
| easily) :)
| herobird wrote:
| Awww, makes me very happy to hear! :) Thank you!
| phickey wrote:
| Wasmtime maintainer here - curious to hear what went wrong, I
| and several other users of wasmtime have production
| embeddings under no_std, so it should do everything you need,
| including building out WASI preview 2 support. You can find
| me on the bytecode alliance zulip if you need help.
| lasiotus wrote:
| I'm not the OP, but I have a similar experience with Motor
| OS: wasmi compiles and works "out of the box", while
| wasmtime has a bunch of dependencies (e.g. target-lexicon)
| that won't compile on custom targets even if all features
| are turned off in wasmtime.
| 9d wrote:
| But if this benchmark is right, then wasmtime is 5x
| faster than wasmi for it:
|
| https://github.com/khvzak/script-bench-rs
| herobird wrote:
| Wasmtime, being an optimizing JIT, usually is ~10 times
| faster than Wasmi during execution.
|
| However, execution is just one metric that might be of
| importance.
|
| For example, Wasmi's lazy startup time is much better
| (~100-1000x) since it does not have to produce machine
| code. This can result in cases where Wasmi is done
| executing while Wasmtime is still generating machine
| code.
|
| Old post with some measurements: https://wasmi-
| labs.github.io/blog/posts/wasmi-v0.32/
|
| Always benchmark and choose the best tool for your usage
| pattern.
| 9d wrote:
| That's a good point I didn't think about.
|
| I guess it's like v8 compared to quickjs.
|
| Anyway all this talk about wasm makes me want to write a
| scriptable Rust app!
| phickey wrote:
| Not sure how to help with this much information but I've
| built and run wasmtime on some pretty squalid
| architectures (xtensa and riscv32 microcontrollers among
| others) but the right collection of features might not be
| obvious. We can help you find the right configuration on
| the Bytecode Alliance zulip or the wasmtime issue tracker
| if you need it.
| lasiotus wrote:
| > Not sure how to help with this [...]
|
| I guess not much can be done at the moment: dependencies
| are often the primary obstacle in porting crates to new
| targets, and just comparing the list of dependencies of
| wasmtime vs wasmi gives a pretty good indication of which
| crate is a bit more careful in this regard:
|
| https://crates.io/crates/wasmtime/33.0.0/dependencies
| https://crates.io/crates/wasmi/0.47.0/dependencies
| phickey wrote:
| Wasmtime has many capabilities that wasmi does not, and
| therefore has more optional dependencies, but the
| required set of dependencies has been portable to every
| platform I've targeted so far. If anything does present a
| concrete issue we are eager to address it. For example,
| you could file an issue on target-lexicon describing how
| to reproduce your issue.
| lasiotus wrote:
| > If anything does present a concrete issue we are eager
| to address it.
|
| That's great to hear! I think it is a bit too early to
| spend extra effort on porting Wasmtime to Motor OS at the
| moment, as there are a couple of more pressing issues to
| sort out (e.g. FS performance is not yet where it should
| be), but in a couple of months I may reach out!
| Gazoche wrote:
| I think I was a bit spooked by the examples (https://github
| .com/bytecodealliance/wasmtime/tree/main/examp...), and the
| need to implement platform dependencies in C code (which
| would have complicated the build process). Makes sense
| since it's a more complex and mature project, but Wasmi on
| the other hand was just a pure Rust dependency that only
| required a single line in the Cargo.toml. So in short I
| went the lazy route :)
| phickey wrote:
| All of the C primitives there implemented in (unsafe)
| Rust, but we built that example for an audience that
| already had some platform elements in C. We'll try to
| improve the example so that both integrating with C, and
| using pure Rust, are covered.
| dmitrygr wrote:
| > I wonder if this will be the future of OSes.
|
| SPECTRE and MELTDOWN enter the chat
| 9d wrote:
| What the DLL, Dmitry. Don't be a buzzkill.
| DoctorOW wrote:
| I don't understand how those vulnerabilities affect WASM OSes
| more than native ones.
| fsflover wrote:
| > I wonder if this will be the future of OSes.
|
| If you are talking about the app isolation through
| virtualization, then I've been living in this future for quite
| some time with Qubes OS. The isolation there is also extremely
| reliable.
| 9d wrote:
| Mostly I meant WASM as a platform (waap?) which seems so
| futuristic to me. I hope one day all OSes can natively run
| WASM code, though I'm not sold on WASI since then we're back
| to square one with security it seems.
| MisterTea wrote:
| The future happened in the 90's:
| https://en.wikipedia.org/wiki/Inferno_(operating_system)
|
| I'd like to see an Inferno with a WASM runtime that
| utilizes a Plan 9 like ABI/API instead of WASI. Node9 did
| similar but with Lua: https://github.com/jvburnes/node9
| apitman wrote:
| I wouldn't say square one. It's still way simpler to
| control what a program can do. The host runtime decides
| what's on the other side of those WASI calls.
| 9d wrote:
| > The downside of course is that each step of the loop is not
| allowed to hold the CPU for arbitrary amounts of time, and must
| explicitly yield for long-running tasks.
|
| Seems to me that a bigger downside is that the more apps you have
| open, the slower each one will become. I don't remember ever
| having more than like 10 open, but I've definitely had 30 tabs
| open, so if they're each separate procs then wouldn't that slow
| each one down by 30x? I guess if the whole computer is fast
| enough that's fine, but _intense_ processes like video renderers
| would slow down noticably, even if not fast, even if just going
| from 1sec to 30sec. But in any case this is a really, really
| clever shortcut for the general case to get _a whole operating
| system_ working, which is no small feat, and really exciting!
| jdiff wrote:
| As long as they all finish their jobs in time, they shouldn't
| run any slower at all. They run, they complete, they wait for
| the next frame. If resources are constrained enough to shrink
| that wait to 0 or below, then yes, everything slows down, and
| somewhat less gracefully than with a more fair and more complex
| scheduling system. But it sounds like each program yields
| explicitly when it's ready for the upcoming frame, so if a
| program doesn't have much to do, its "share" of the time is
| free real estate.
| bionhoward wrote:
| Great job! Congrats on shipping, this looks like a big project
| herobird wrote:
| > Every iteration of the loop polls the network and input
| drivers, draws the desktop interface, runs one step of each
| active WASM application, and flushes the GPU framebuffer.
|
| This is really interesting and I was wondering how you
| implemented that using Wasmi. Seems like the code for that is
| here:
|
| https://github.com/Askannz/munal-os/blob/2d3d361f67888cb2fe8...
|
| It might interest you that newer versions of Wasmi (v0.45+)
| extended the resumable function call feature to make it possible
| to yield upon running out of fuel:
| https://docs.rs/wasmi/latest/wasmi/struct.TypedFunc.html#met...
|
| Seeing that you are already using Wasmi's fuel metering this
| might be a more efficient or failure proof approach to execute
| Wasm apps in steps.
|
| An example for how to do this can be found in Wasmi's own Wast
| runner: https://github.com/wasmi-
| labs/wasmi/blob/019806547aae542d148...
| 9d wrote:
| Not OP, but I'm confused how this would be helpful. You're
| saying for example, he can use this function to create a
| coroutine out of a function, begin it, and if the function
| fails by e.g. running out of memory, you can give the module
| more memory and then resume the coroutine? If so, how is that
| different than what naturally happens? Does wasm not have
| try/catch? Also, wouldn't the module then need to back up
| manually and _retry_ the malloc after it failed? I 'm so lost.
| herobird wrote:
| Great question!
|
| Wasmi's fuel metering can be thought of as is there was an
| adjustable counter and for each instruction that Wasmi
| executes this counter is decreased by some amount. If it
| reached 0 the resumable call will yield back to the host (in
| this case the OS) where it can be decided how to, or if, the
| call shall be resumed.
|
| For efficiency reasons fuel metering in Wasmi is not
| implemented as described above but I wanted to provide a
| simple description.
|
| With this, one is no longer reliant on clocks or on other
| measures to provide each call its own time frame by providing
| an amount of fuel for each Wasm app that can be renewed (or
| not) when it runs out of fuel. So this is useful for building
| a Wasm scheduler.
| 9d wrote:
| > Great question!
|
| Thanks! I have lots more too. Are there directions in
| space? What kind of matter is fire made of? If you shine a
| laser into a box with one-way mirrors on the inside, will
| it reflect forever? Do ants feel like they're going in
| regular motion and we're just going in slow motion? Why do
| people mainly marry and make friends with people who look
| extraordinarily similar to themselves? How do futures work
| in Rust? Why is the C standard still behind a paywall? Let
| me know if you need any more great questions.
| lukan wrote:
| "If you shine a laser into a box with one-way mirrors on
| the inside, will it reflect forever?"
|
| No, because each reflection comes at a cost (some light
| transformed to heat)
|
| "Why do people mainly marry and make friends with people
| who look extraordinarily similar to themselves?"
|
| To not get so much surprises and have a more stable life.
| (I didn't choose that path.)
|
| (But I feel it would be too much OT answering the other
| questions and don't want to distract from this great
| submission or the interesting Wasmi concept)
| 9d wrote:
| No, I do not accept this. There must be a way. What if
| the mirror box has a high enough heat? Would it work
| then? The box could be made of a heat resistant material,
| like fiberglass.
| Bjartr wrote:
| It's not that the mirror or box is damaged by heat, it's
| that each bit of heat energy comes from a bit of light
| energy. Eventually the light bounces enough times that
| there's no energy left in it.
| 9d wrote:
| I understand, but what I mean is, what if there is no
| more opportunity for the light to emit heat, because the
| surrounding environment is already saturated with so much
| heat that it can't accept more? Is this a possible way to
| prevent the light from emitting heat and therefore
| prevent the light from decreasing its luminousness? There
| _must_ be a way!
| lukan wrote:
| Are you aware of that old concept and why it doesn't
| work?
|
| https://de.wikipedia.org/wiki/Perpetuum_mobile
|
| Same principle.
|
| Basically, what you propose negates the nature of
| reality. There is always friction/energy loss into heat
| (increased chaotic movement). Only way to deal with it,
| if you want permanent cycles, is constantly add energy in
| the same amount that is lost.
| Bjartr wrote:
| Why _must_ there be a way?
|
| A few notes: * There's no such thing as "absolute hot"
| state that meansno more heat can be added * Blackbody
| radiation means that above a certain temperature,
| regardless of what you make your mirror out of, it will
| be spontaneously emitting visible light at all times.
| lukan wrote:
| Indeed. There is only an absolute zero, that cannot get
| colder, but more heat is always possible as more heat
| means more rapid movement of elements. While absolute
| zero at 0 K means no movement.
| coolcoder613 wrote:
| Flame is what you see when gases burn in the air. As the
| material burns, it breaks down and releases flammable
| gases, which burn too, giving the effect of flame. If you
| have ever tried burning fine-grade steel wool, you will
| have seen that it burns without any flame because the
| iron burns directly without making gases first.
| 9d wrote:
| I was told it was plasma. Who is wrong, them or you?
| Either way, I can't trust _one_ of you...
| coolcoder613 wrote:
| Perhaps you should look it up yourself? Plasma is not
| found in flame, but it is in lightning.
| pimeys wrote:
| We used fuel metering with wasmtime, but that made
| everything quite slow, certain things veeery slow.
|
| How is the performance when using fuel with wasmi?
|
| We are considering to use epoch counter, but for now we
| just turned fuel off.
| 9d wrote:
| I had no idea what fuel is until this discussion.
|
| What's the rationale? Just preventing infinite loops from
| hanging the host?
|
| If the inefficiency is the counter, what if you just
| calculated an instruction offset - start < threshold
| every once in a while?
|
| This probably makes no sense, ignore it, I'm way in over
| my head.
|
| [1]
| https://github.com/bytecodealliance/wasmtime/issues/4109
|
| [2] https://github.com/bytecodealliance/wasmtime/blob/mai
| n/examp...
| herobird wrote:
| Yes, rational is to provide a pragmatic and efficient
| solution to infinite loops.
|
| There is a variety of ways to implement fuel metering
| with varying trade-offs, e.g. performance, determinism
| and precision.
|
| In this comment I roughly described how Wasmi implements
| its fuel metering:
| https://news.ycombinator.com/item?id=44229953
|
| Wasmi's design focuses on performance and determinism but
| isn't as precise since instructions are always considered
| as group.
| conradev wrote:
| I first encountered this with gas in the Ethereum VM. For
| Ethereum, they price different operations to reflect
| their real world cost: storing something forever on the
| blockchain is expensive whereas multiplying numbers is
| cheap
|
| I'm not sure what it's used for in this context or how
| instructions are weighted
| pimeys wrote:
| Let's consider that you create a serverless platform
| which runs wasm/wasi code. The code can do an infinite
| loop and suck resources while blocking the thread that
| runs the code in the host. Now, with a fuel mechanism the
| code yields after a certain amount of instructions,
| giving the control back to the host. The host can then do
| things such as stop the guest from running, or store the
| amount of fuel to some database, bill the user and
| continue execution.
| herobird wrote:
| I don't know how fuel metering in Wasmtime works and what
| its overhead is but keep in mind that Wasmi is an
| interpreter based Wasm runtime whereas Wasmtime generates
| machine code (JIT).
|
| In past experiments I remember that fuel metering adds
| roughly 5-10% overhead to Wasmi executions. The trick is
| to not bump or decrease a counter for every single
| executed instruction but instead to group instructions
| together in so-called basic blocks and bump a counter for
| the whole group of instructions.
|
| This is also the approach that is implemented by certain
| Wasm tools to add fuel metering to an existing Wasm
| binary.
| phickey wrote:
| Wasmtime's epoch system was designed specifically to have
| a much, much lower performance impact than fuel metering,
| at the cost of being nondeterministic. Since different
| embeddings have different needs there, wasmtime provides
| both mechanisms. Turning epochs on should be trivial if
| your system provides any sort of concurrency: https://git
| hub.com/bytecodealliance/wasmtime/blob/main/examp...
| 112233 wrote:
| Is it deterministic? I.e. would running the same function
| "time out" at the exactly same state, if run in different
| environments?
| jazzyjackson wrote:
| Possibly answered one sibling next to you,
| https://news.ycombinator.com/item?id=44230721
| herobird wrote:
| Yes, Wasmi's fuel metering is deterministic.
| Gazoche wrote:
| Thanks again for making Wasmi :)
|
| > It might interest you that newer versions of Wasmi (v0.45+)
| extended the resumable function call feature to make it
| possible to yield upon running out of fuel:
|
| That is really interesting! I remember looking for something
| like that in the Wasmi docs at some point but it must have been
| before that feature was implemented. I would probably have
| chosen a different design for the WASM apps if I had it.
| herobird wrote:
| I am really sorry I have waited so long to extend Wasmi's
| resumable calls with this very useful feature. :S Feel free
| to message me if you ever plan to adjust your design to make
| use of it.
| Gazoche wrote:
| Please don't take it as a reproach! Not your fault at all,
| and at least it forced me into creative problem-solving ;)
| apitman wrote:
| It's awesome that Wasmi is fast enough to run GUI apps. I'm
| working on an app runtime for making highly portable GUI apps.
| I'm targeting wasm because it seems to strike a good balance
| between performance and implementation simplicity. Ideally it
| would be possible to run apps on a runtime hacked together by a
| small team or even a single person. The fact that an
| interpreted (if highly optimized) wasm runtime like Wasmi is
| clearly capable of running GUI apps is exciting.
| baq wrote:
| Fun project. The grey beards will gladly read how is it
| qualitatively different from early Windows or maybe even AmigaOS
| Workbench? The dinosaurs will probably point to bytecode
| interpreters mixed with OSes like Lisp machines or smalltalk
| environments, could be an interesting comparison, too.
| Ericson2314 wrote:
| This is a very good bucking of conventional wisdom. Good job!
|
| Now that Redox aims to support WASI too, it would be interesting
| to see if the syscall interfaces of these two can grow together
| other time, even as the implementation strategy remains radically
| different.
| catapart wrote:
| This is so interesting!
| geoctl wrote:
| Great work. I've always wondered if WASM could actually be used
| as a more generic alternative alternative to eBPF where you could
| actually do more complex logic than the average eBPF program at
| the kernel level and still have customized and restricted access
| to the kernel APIs and data structures like you're actually
| developing a typical kernel module.
| jauntywundrkind wrote:
| I can't wait to see what attempts like this might look like after
| wasm components start becoming real(-er).
|
| I have huge respect for unikernel designs, and this looks
| amazingly festureful. & Yet... I don't know why it matters to me
| as much as it does, but I want so very much for wasm to be useful
| for more than one big precompiled app.
|
| There's all sorts of work going into wasi preview3 right now, to
| allow sync and async code to co-exist. Once that happens, it
| feels like wasm will finally have all the necessary ingredients
| down to be an everything runtime (although I'd hoped the host-
| object bridging was going to get more love too, & it's not clear
| to me that there's any itnent to go beyond js-based bridges like
| rust web-sys, on and on).
|
| I hope we see more interest in wasm runtimes being used to host
| more dynamic sub environments, to host not just one amazing
| process but many processes. The promise of wasm components is to
| give us: standard, portable, lightweight, finely sandboxed,
| cross-language, compositional module (according to the wonderful
| talk linked below), and it seems so near, but this status quo of
| it being used so extensively in unikernel like applications,
| needing everything compiled ahead of time, feels like the area I
| want to see wasm expanding into not as a specification (the spec
| seems there!) but as a practicable doable thing, like what I want
| wasm components to be good for. Not just a distribution format
| but a runtime capability.
|
| _What is a Component (and Why)_ https://youtu.be/y3x4-nQeXxc
| 9d wrote:
| I started on a Rust app that uses SDL3 and lets you script it
| via embedded V8[1]. But I'm _very seriously_ tempted to fork it
| and embed wasmtime or wasmi and let you script it in _anything_
| , and include a few wasm compilers into the app for convenience
| so you just give it a file and it does the rest. Mainly because
| of the speed of wasmtime and wasmi compared to alternatives[2].
| But my biggest concern is that this isn't adding any real
| convenience. You still have to set up whole code environments,
| which defeats the purpose of _scripting_ it. Still, it 's such
| a neat idea that I don't want to not do it, and I just might.
|
| [1] https://sdegutis.github.io/blog/dear-everyone-hire-me-to-
| mak...
|
| [2] https://github.com/khvzak/script-bench-rs
| apitman wrote:
| Did you mean to link to this one perhaps?
| https://www.youtube.com/watch?v=tAACYA1Mwv4
| simonw wrote:
| Wow, this thing even has its own web browser!
| https://github.com/Askannz/munal-os/tree/master/wasm_apps/we...
|
| You can see a snippet of it running (and rendering Hacker News)
| in the demo video.
| apitman wrote:
| I love this because it shows what we've lost in the push to add
| JS, CSS, and endless features to web browsers. Certainly we've
| gained a lot as well, but there's a cost. And that cost is a
| small browser like this with minimal dependencies can't render
| much of the web in a useful form.
|
| I think we need a cleaner split between the content web and the
| app web. The content web should need a minimal HTTP client and
| HTML parser. Web apps could actually run on something quite
| similar to this OS here: wasm + some GUI plumbing 5-10 hardware
| APIs for the most common things. Please just make sure it has
| UDP.
| pjmlp wrote:
| /rant mode on
|
| Every few years since Xerox PARC, we get yet another attempt to
| bytecode userspace.
|
| So far only IBM i, ChromeOS and Android managed to stick around,
| mostly thanks for their owners having the "my way or the highway"
| attitude, with management willing to support the teams no matter
| for how long it takes.
|
| /rant mode off
|
| Anyway, all the best for the project, looks cool.
| 9d wrote:
| ChromeOS only uses V8 by happenstance, being an OS that's just
| a browser.
|
| Android could have used anything and it would have been
| successful, even C++.
|
| These were both successful purely because they're cheap, not
| because technology.
| pjmlp wrote:
| What matters is what is available for developers on
| userspace, regardless if they like it or not.
|
| Great technology sadly wins on merit.
|
| Technology wins on either being cheaply available, in a worse
| is better fashion, as devs rather drink free lemon juice
| instead of nice costly orange one, or by having companies
| with willingness and deep pockets to push it no matter what.
| n42 wrote:
| You seem to frequently appear in threads involving WebAssembly.
| Each time you do, I see you point out how bytecode VMs have
| been done before. And, every time, it doesn't contribute
| anything interesting to the conversation.
|
| I don't mean this in a hostile way, however, it has become
| frustrating finding this predictable and low effort comment
| from you every time I open an HN thread on WebAssembly -- and,
| frankly, I've begun collapsing comments whenever I see your
| username.
|
| Every iteration on the concept brings different approaches and
| tradeoffs made from lessons learned from previous attempts.
| This is just how engineering, and our industry, works.
|
| I don't mean disrespect. I assume you are probably speaking
| from a place of experience. I would be so much more interested
| hearing your thoughts on the minutiae than basic pattern
| recognition.
| pjmlp wrote:
| And yet you decided to spend around 5 minutes writing to me,
| instead of collapsing the comment.
|
| Here is tip for you as well, learn from the past, before
| doing any kind of WebAssembly marketing of how innovative it
| happens to be, versus JVM as if there was never anything else
| done.
| n42 wrote:
| Yes, rather than ignore you, this time I chose to spend
| five minutes of my life writing a well meaning piece of
| critical feedback. Whether that was a waste of my time is
| left to you.
| apitman wrote:
| I recommend not engaging. I've tried once or twice, and when
| I shared a concrete example[0] of a real problem wasm solves
| for me that I'm not aware of another way to do, pjmlp just
| stopped responding. I'm not sure what their motivations are
| but it's too bad they choose to distract from someone's
| awesome project the person has spent years working on.
|
| [0]: https://github.com/lastlogin-net/decent-auth
| int_19h wrote:
| The idea is so obviously beneficial that we'll keep having them
| until one manages to get entrenched firmly enough to become the
| standard.
|
| wasm is likely to be that thing for the simple reason that it
| actually pursues this goal. JVM notionally does (or did? what
| does Oracle say these days?), but its bytecode is so much more
| high-level that it's not even in the same ballpark.
| knowitnone wrote:
| this is very impressive. I really like that you have a browser
| which is almost mandatory for a desktop OS now. You should write
| down your TODO list and I hope you keep working on this. I think
| there is room for many OSes especially ones written in Rust.
| IshKebab wrote:
| Apart from the cooperative scheduling, I think Spectre probably
| kills the security model, and I can't understand how this could
| work efficiently without virtual memory. How do you implement
| `memory.grow`? Do you have to `memmove` an entire app's memory
| when it wants to grow by 10 kB and another app is in the way? Is
| that even possible?
|
| Still, very impressive project!
| 9d wrote:
| Could you elaborate?
| IshKebab wrote:
| Virtual memory serves two purposes:
|
| 1. To isolate processes - physical memory used by one process
| is only mapped into that process's virtual memory space. No
| other processes can read it. (Except for shared memory.).
| Using WASMs isolation instead means you don't need this so
| much (ignoring Spectre) but you still need...
|
| 2. To handle memory fragmentation - each process expects to
| see a contiguous block of memory available to it (more or
| less). Especially in WASM, you just get a big linear memory
| array that you can grow and shrink as you like.
|
| If these blocks have to be physically contiguous blocks in
| memory it's going to be really hard to organise them,
| especially because you don't know how much memory they use in
| advance.
|
| For example you run two apps and they initially say they need
| 100MB each. So you allocate app A at [0, 100MB) and app B at
| [100, 200MB). How app A says "I need 1 extra MB please!".
| Well since you don't have virtual memory that has to be at
| the _physical_ address 100MB, which is already occupied by
| app B. So you have a few bad options:
|
| * Leave space between apps in case they want to grow. But
| it's not obvious how much space, and also this would be
| extremely inefficient since you're literally wasting physical
| RAM.
|
| * Don't allow apps to grow their memory. I think the very
| first versions of WASM didn't support this. Again this is
| obviously inefficient because apps have to allocate enough
| memory for their maximum memory usage even if they rarely use
| that.
|
| * Shuffle apps around in physical memory when you need some
| space. I think this is possible but it would be really slow
| and lead to weird random pauses while GBs of memory is
| copied.
|
| Virtual memory solves those issues. I think you could
| probably still build a system with these limitations for some
| use cases, e.g. kiosk/Point of Sale terminals. But for
| general purpose use it seems impossible unless I've missed
| some trick...
| 9d wrote:
| Why not just give apps chunks of non-contiguous memory and
| let them deal with that fact? Then like realloc, the memory
| they need stretched may just be moved first.
| int_19h wrote:
| Because wasm virtual machine has contiguous linear
| memory. So if you do this, you're no longer running wasm.
|
| Besides, why would you design around the lack of a MMU?
| Even in embedded space it's often there.
| 9d wrote:
| No I mean what if we updated the wasm spec to allow it?
| apitman wrote:
| > I think Spectre probably kills the security model
|
| What's the threat model exactly? As far as I can tell all the
| apps are compiled directly into the kernel, and the web browser
| doesn't run JavaScript. So I don't see any way to get untrusted
| code into the thing.
| jasonthorsness wrote:
| Incredible that it's a client OS! I think this kind of design can
| have immediate use server-side because it eliminates quite a bit
| of security boundary by making the kernel much smaller and
| eliminating all other libraries and applications besides the
| thing you are running. I think a key/value store for example
| would be an excellent candidate to run like this.
|
| Is it possible to achieve decent network performance with this IO
| model? Can it play any tricks with memory to eliminate some of
| the copies required when hosting WASM in most programs?
| rollcat wrote:
| The radial menu is brilliant.
|
| It is reminiscent of how basic team communication works in
| StarCraft 2. You alt-click to ping the minimap (draw allies'
| attention to something in that general area). If it's something
| more specific, you can hold alt, and drag-click to open a
| directional menu, from which you can choose one of four orders:
| attack, defend, retreat, and OMW. Some pings are also context-
| sensitive: click on the minerals/gas to say "I want to gather
| these resources", useful for establishing expansion patterns,
| strategy in the early game (macro/rush), tech transitions (ping
| your hydralisk den to say "I'm gonna make hydras"). All of this
| is key in a game with hundreds of APM and split-second reaction
| times.
|
| It's a similar story with GUI actions. Power users appreciate
| good key shortcuts more than almost anything. If you do something
| thousands of times a day, it needs to be near-instant. The mouse
| is often disregarded, and IMHO that's because nobody is really
| doing any serious research in that area. Radial menus pack a lot
| of actions (where three mouse buttons fall short), exploit Fitt's
| law, muscle memory, etc. They are also discoverable and provide
| immediate visual feedback (contrary how "mouse gestures" work in
| some applications).
|
| Couple notes on the current implementation (from what I've
| gathered from the video):
|
| - Settle on how many actions *at most* do you want available in
| the menu (4? 6? 8?), divide the menu accordingly, and display
| those divisions regardless of whether there's an actionable item.
| This will help develop muscle memory. If you need more than say 8
| actions, the menu might already be getting more crammed than
| you'd find useful.
|
| - When figuring out where to place stuff, I would suggest
| prioritising the four cardinal directions for the most common
| actions, starting with the horizontal positions. "Surprising" or
| destructive actions (even if un-doable) should be placed at the
| harder-to-reach positions.
|
| - Keep the actions as consistent as possible between different
| contexts, e.g. left on the document closes the document, left on
| the title bar closes the window, but not: left on an icon deletes
| the file.
|
| Questions worth considering:
|
| - I'm not sure if a launcher is a good use for this model; once
| you have a dozen apps (or more than 3-4 windows to switch
| between), it's gonna get awkward. Maybe a more traditional list-
| menu, and/or a dock? But I'd be intrigued if you come up with
| something original.
|
| - What happens when you open a menu too close to the screen edge?
| It's an interesting case to consider. Warping the pointer might
| be an option (the physical mouse can keep moving, after all).
|
| - Is this going to work well with a trackpad? Maybe use a
| two/three finger swipe, but that depends on how precise is your
| hardware.
|
| - What about a trackpoint, or die-hard keyboard users? Perhaps
| you can trigger the menu by holding down the space key?
|
| Anyway, this is really inspiring.
| diskzero wrote:
| Marking Menus [1], Pie Menus, Radial Menus and friends have
| been around for a while. There is good body of research on
| them, with some recent research done on their use in multi-
| touch environments. [2]
|
| While working at DreamWorks, I would often watch artists
| navigate complex marking menu hierarchies and invoke a command
| before the menu items themselves could actually be read by a
| non-trained user. In our custom lighting tool, you could
| execute the marking menu command by invoking the menu command
| and making them mouse movement before the menu actually drew.
|
| 1. https://www.billbuxton.com/MMUserLearn.html 2.
| https://damassets.autodesk.net/content/dam/autodesk/research...
| int_19h wrote:
| It was used in some games to great effect as well, e.g.
| Neverwinter Nights. Same story there - once you memorize
| where the commands are, each invocation effectively becomes a
| mouse gesture performed without even looking at the bubbles.
|
| https://www.gamerguides.com/assets/guides/192/neverwinter_ni.
| ..
| baudaux wrote:
| Once wasm wasi runtime for exaequOS is ready (I hope soon) I will
| have a look for running munal OS app in the browser
| senkora wrote:
| I have to ask, were you influenced at all by the talk "The Birth
| and Death of Javascript" from Pycon 2014?
|
| https://www.destroyallsoftware.com/talks/the-birth-and-death...
|
| It describes a hypothetical future where operating systems use
| asm.js (precursor to wasm) sandboxes as an alternative to virtual
| memory protection. I always thought it was a cool idea, and it
| seems to be a key part of your design.
| nextaccountic wrote:
| It's more likely this was influenced by Midori, a research
| operating system from Microsoft active around 2008 to 2015
|
| https://www.siberoloji.com/understanding-microsoft-midori-th...
| n42 wrote:
| This is just so inspirational and cool. I've had so many of these
| concepts floating around in my head, without the critically
| necessary capability, or followthrough. I'm sure others have as
| well. It's very cool to see someone execute on it.
|
| I wonder about operating systems with isolated applications like
| this providing some kind of attestation.
|
| Is it even possible to do that in a non-user hostile way?
|
| The use case I daydream about is online competitive gaming. It's
| a situation where a majority of users are willing to give up
| software freedom for a fair community. Consoles used to be a
| locked down way to guarantee other users were participating
| fairly, but this increasingly less the case as cheaters become
| more advanced. Solving this problem necessarily locks down access
| to software and hardware, as far as I can figure it. From a game
| theory perspective I can't see any other approach. Enter "kernel
| level anticheat"; aka rootkits, depending on who you ask.
|
| So I guess I wonder if virtualization at a level like this can
| somehow be a part of the solution while preserving software
| freedom, user privacy and security where the user still wants it
| apitman wrote:
| Don't want to derail from the interesting technical
| conversation, so feel free to ignore.
|
| This is maybe more of a philosophical answer, but IMO the
| answer is to play games with people you trust. I've recently
| redicovered the joy of LAN parties (both Halo and AoE2) and
| man, it's so much better than the countless hours I spent
| getting pissed at faceless strangers in online games.
|
| I wish there were more games designed for local multiplayer.
| n42 wrote:
| I think that's an interesting observation. It seems to be a
| philosophical discussion on social trust.
|
| Anticheat is an attempt to control the behavior of the
| community. Your solution is to just control who is in your
| community.
|
| In a way, I think it's the same lessons learned from social
| networks. You see it in the trends moving away from global
| communities back toward smaller online communities; private
| Discord servers, BlueSky follow/block lists, and so on.
| jadbox wrote:
| Very cool. This project needs something like a native control
| library interface into the wasm apps so that there can be UX
| uniformity.
| beansbeansbeans wrote:
| This is amazing. Congrats on the project! I initially started
| learning rust a few years ago specifically for it's support for
| compiling to webassembly, as I found it so interesting. This
| project and the discussion on the post makes me want to get back
| to it :D
| jasonfrost wrote:
| Reminds me of project mempo from like 10 years ago
| nnx wrote:
| > It's an unikernel design that is compiled as a single EFI
| binary and does not use virtual address spaces for process
| isolation.
|
| Are you able to quantify what kind of performance improvement to
| expect from such a design?
|
| My understanding is that this can completely skip overhead of
| syscalls and TLB, but I have no idea of how much performance
| benefits can it result in practice.
| bjackman wrote:
| Pretty cool!
|
| > The reliance on VirtIO means Munal OS does not support running
| on real hardware yet
|
| I think if you wanted to run it on HW, instead of running adding
| drivers to it a cool strategy would be to build a Linux-based
| system that acts as a bootloader and then starts a minimal
| hypervisor. Then you could keep the "virtio is the platform"
| thing.
|
| It would be quite cool how you end up using VirtIO as the
| platform for the OS in the same way that you use WASM as the
| platform for applications.
|
| For what it's worth, as a platform security nerd, unfortunately I
| do think we need to use the MMU. But, a cool realisation with
| your design is that it doesn't mean we need virtual memory, you
| could keep the identity mapping and just use the protection bits.
| Unfortunately that still takes away a big part of your
| simplification since now you need multiple set of pagetables,
| need to manage TLB flushes, etc.
| jeroenhd wrote:
| > I think if you wanted to run it on HW, instead of running
| adding drivers to it a cool strategy would be to build a Linux-
| based system that acts as a bootloader and then starts a
| minimal hypervisor. Then you could keep the "virtio is the
| platform" thing.
|
| That's what I did with my last hackintosh attempt and it works
| pretty well. The downside: without real GPU events to respond
| to, you'd be stuck with whatever resolution Linux decided upon
| in whatever screen configuration Linux decided to boot.
|
| If this thing can run as a UEFI executable rather than a real
| OS, you might be able to use the UEFI video drivers to get
| video working relatively easily without having virtio graphics,
| but I'm not sure if it's even possible to pull that off while
| doing real OS things.
| LYK-love wrote:
| Not an export in OS. Can op explain the project motivation and
| high-level design a bit? The readme file seems to be a feature
| introduction and barely touches the motivations, i.e., what
| problem does it aim to solve, is it designed for any specific
| domain or it's a general purpose OS, what gain could those
| feature bring in practice?
___________________________________________________________________
(page generated 2025-06-10 23:01 UTC)