> 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:
> 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.
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.
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.
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.
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://github.com/bytecodealliance/wasmtime/blob/main/examp...
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.
This is really cool stuff. I've always wanted fuel-based work with a high level programming languages. Having a language compile to wasm with wasmi now seems like a nice way to achieve that.
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
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.
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.
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.
"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)
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.
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.
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!
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.
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.
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.
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.
> 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.
> 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.
I am skeptical that the UEFI drivers would be up to the job. I worked on EDK2 drivers many many years ago and things were not really optimised for speed. Mostly we just did the simplest thing that would boot Linux without any unnecessary delays.
Plus they are very often gonna be buggy and there's not much you can do about buggy UEFI FW.
> 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!
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.
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.
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?
> 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.
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...
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.
But why would we do that when the hardware already has everything that's needed to present the app with a flat contiguous memory space? Why push unnecessary complexity at every single wasm app out there?
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.
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.
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) :)
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.
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.
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 :)
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.
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.
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.
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:
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.
> 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!
There’s now an interpreter in wasmtime called Pulley. It’s an optimizing interpreter based on Cranelift, which generates interpreter opcodes which are more efficient to traverse than directly interpreting the Wasm binary.
I have run wasmtime on the esp32 microcontrollers with plenty of ram to spare, but I don’t have a measurement handy.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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
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.
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.
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.
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?
> 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.
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.
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?
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.
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.
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
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.
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.
> 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...
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.
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.
Please don't take it as a reproach! Not your fault at all, and at least it forced me into creative problem-solving ;)
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.
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.
Is it deterministic? I.e. would running the same function "time out" at the exactly same state, if run in different environments?
Possibly answered one sibling next to you, https://news.ycombinator.com/item?id=44230721
Yes, Wasmi's fuel metering is deterministic.
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.
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://github.com/bytecodealliance/wasmtime/blob/main/examp...
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.
This is really cool stuff. I've always wanted fuel-based work with a high level programming languages. Having a language compile to wasm with wasmi now seems like a nice way to achieve that.
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/main/examp...
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.
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
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.
> 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.
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.
I was told it was plasma. Who is wrong, them or you? Either way, I can't trust one of you...
Perhaps you should look it up yourself? Plasma is not found in flame, but it is in lightning.
"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)
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.
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.
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!
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.
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.
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.
> Does wasm not have try/catch
Not currently. There's an accepted proposal, but its in progress.
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.
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.
> 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.
Nice!
I am skeptical that the UEFI drivers would be up to the job. I worked on EDK2 drivers many many years ago and things were not really optimised for speed. Mostly we just did the simplest thing that would boot Linux without any unnecessary delays.
Plus they are very often gonna be buggy and there's not much you can do about buggy UEFI FW.
> 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!
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.
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.
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...
I had not heard of it, but sounds pretty interesting.
I watched that talk a long time ago, but maybe on some level! Though I don't think the idea is particularly novel.
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!
> 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.
Could you elaborate?
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...
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.
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.
No I mean what if we updated the wasm spec to allow it?
But why would we do that when the hardware already has everything that's needed to present the app with a flat contiguous memory space? Why push unnecessary complexity at every single wasm app out there?
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
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
Did you mean to link to this one perhaps? https://www.youtube.com/watch?v=tAACYA1Mwv4
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.
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.
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!
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) :)
Awww, makes me very happy to hear! :) Thank you!
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.
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.
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 :)
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.
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.
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.
> 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
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.
> 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!
Is that wasmtime in interpreter mode? I didn't see a rv32 backend to wasmtime (in cranelift) or did I not look in the right place.
What are the min memory requirements for wasmtime/cranelift?
There’s now an interpreter in wasmtime called Pulley. It’s an optimizing interpreter based on Cranelift, which generates interpreter opcodes which are more efficient to traverse than directly interpreting the Wasm binary.
I have run wasmtime on the esp32 microcontrollers with plenty of ram to spare, but I don’t have a measurement handy.
That is amazing news! Thank you.
https://github.com/bytecodealliance/wasmtime/blob/main/pulle...
But if this benchmark is right, then wasmtime is 5x faster than wasmi for it:
https://github.com/khvzak/script-bench-rs
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.
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!
> 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.
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.
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
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.
> I wonder if this will be the future of OSes.
SPECTRE and MELTDOWN enter the chat
I don't understand how those vulnerabilities affect WASM OSes more than native ones.
What the DLL, Dmitry. Don't be a buzzkill.
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.
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.
/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.
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.
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
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.
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.
I can assure you it was a waste of your time.
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.
Since 1958 there were a few more bytecodes to chose from, yet another comment talking only about JVM.
How many of them were portable yet specifically designed to be compilable to sandboxed low-level native code?
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.
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.
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?
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
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.
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.
For sure. I wonder if it's a pendulum that will keep swinging, or if most things will go small and stay there.
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.
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?
> 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.
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.
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.
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...
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...
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
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.
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.
This is so interesting!
Great job! Congrats on shipping, this looks like a big project
Very cool. This project needs something like a native control library interface into the wasm apps so that there can be UX uniformity.
Once wasm wasi runtime for exaequOS is ready (I hope soon) I will have a look for running munal OS app in the browser
Reminds me of project mempo from like 10 years ago