Show HN: exaequOS - a new OS running in a web browser
Comments
Really neat thing, very un-neat name though
You do not like the play on words ?
What play on words?
"Ex aequo" + OS, I think
What does this mean? Ex as in ex-parrot, right? But what's aequo supposed to mean? Google is not helping. An "aequo" that was but isn't anymore? Forgive my ignorance, English/Greek/Latin is not my first language.
I'm reading it as "execOS" but I could be wrong.
You are right : ex æquo- execute. Spelling is quite similar in French. May be same in English
https://en.wikipedia.org/wiki/Ex_aequo_et_bono
"ex" is a preposition meaning "from".
exactly
Exaequo - execute... Why ex aequo ? because everybody have same execution environment (or almost same i.e the web browser)
Nice job! I was expecting the usual "I made a window manager in JS" type of web OS, but this is an actual OS as in a kernel + userland programs that can run on it.
It seems that the file system is systematically queried over HTTP and never cached: calling `ls` multiple times does a query for each element of the PATH then for the "binary" itself (a .wasm file). It that a design choice? Like to be able to have multiple users connected on the same remote filesystem and have each access up-to-date? Or is that something that will be optimized later on?
EDIT: I see that files that I create are stored locally (and available whatever the login I choose at the beginning).
I came across a few bugs: trying to use pipes to chain commands always hang, and ^C doesn't work; using an append file redirection ">>" to add a line to a file (I tried creating a multi line file with `cat` but it failed) makes every subsequent commands fail.
There are several file systems: a virtual file system (in the resource manager), a network file system (in netfs, with a cache in RAM), a local persistent file system (in localfs, using littlefs and indexedDB). Pipe driver is there. and some signalling as well.
At the moment the project is a proof of concept, for sure a lot of things are not developed and not debugged. If it appears that the project is interesting enough, I will have to find people helping me to make it a real product
With how much stuff is moving to Electron and how many extensions to the web (like WebUSB and WebGPU) there are, I wonder if in the future, everything will run via WASM and extensions to WASM. You’ll have the Linux kernel, but only as a driver framework to allow for a completely clean, completely web-based OS on top of it.
Chrome OS is close, but it still has many native bits and pieces (window chrome, taskbar, etc.) I’m talking about going all the way.
exaequOS is a full system, a kernel with drivers and apps. You can execute several apps in parallel
I think they address some different use cases. Electron makes cross platform frontends easier (at least across desktop OSes and web), but it doesn't really address typical OS-level concerns. Most web apps don't need to go that low, they just deal with the UI and business logic. Where they need higher performance, they can also spin off individual worker threads (in WASM or JS) for compute work, without touching the OS.
Maybe high-performance web gaming? Or hardware dependent encoding etc.?
But otherwise, I think the typical web app would benefit from a shared UI framework... which is different from a shared OS. You can have one without the other, kinda like how MUI (the Material React UI kit) runs on any browser and doesn't care about the OS, while Linux runs everywhere too but never looks the same on any two machines.
Pretty cool! How do you persist storage?
Later on I will add drivers for googledrive, Dropbox, etc…
Hm. That won't afoul of Same Origin stuff? (really asking - I don't know much about web security)
There are web API for accessing Google Drive and Drop Box. So I do not think so. But I have to try for confirming this
Localfs driver uses littlefs and indexedDB
Very cool! It's always refreshing to see the "OS in the browser" projects that try and actually make something functional. I've been working on one myself for nearly 3 years now, called daedalOS (https://github.com/DustinBrett/daedalOS).
The WASM kernel idea is very cool and I hope one day to be able to add something similar to my project. I think you are onto something and I am excited to see your progress as you implement the GUI.
Thanks Dustin. Your project is very very cool and much more advanced than mine. I started height months back. I would like to include Doom ! Do you have the source code and the resources ?
Do you share some information about the software architecture ?
Thanks! My parent comment has a link to my project on GitHub which is named daedalOS. As for architecture, it's changed so much throughout the 3 years, that I am not even totally sure anymore. It's built with Next.js/React. WebAssembly is used in many places, but it's not the basis for the OS.
I am starting implementing the graphical environment even if there are still many existing bugs :-) I will develop a wayland server first. exaequOS currently supports frame buffer (you can try the fblife game: /usr/games/fblife)
Very cool, I will check it out.
This is really cool! I see you took The Birth & Death of JavaScript[1] to heart.
[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...
How do you know I saw this video ? :-)
It's a classic :) - along with Wat[1]!
Just watching it back again now - he jokingly predicts slower technological progress globally between 2020 and 2025 due to a world war. Damn.
"Boundaries" is one of the more important quick talks I know of, and I've sent it to most juniors I've worked with.
That guy's surely a genius (regardless of this prediction)
His prediction window is still open so you never know… /me shudders
More wars, fewer ads? The counterintuitive dystopia.
Chromium for exaequOS when?
Then this in chromium, recursively, ad nauseam.
I plan to put a text web browser (lynx or links). Chromium would be incredible
What do I install onto a server, to use it as desktop? is there something new? an application with better immigration towards to thin client. I can't remember the name.
You install nothing on the server. All is executed in the browser. I find it fun and I learn a lot of things. So it is not time wasting for me.
In fact, the idea is that it becomes not only an OS but also a store for web apps. Having Unix style apps that run on every web browser could be interesting. And without any prior installation
This comment's grammar is so bad that I can't actually understand it. I know English is hard, but you have some work to do before you can offer coherent criticism to others (on English-speaking sites anyway).
Maybe present your criticism in your native language, and someone can translate it for us.
Cool! If you get emacs to run in it you instantly have a huge suite of useful programs available there :)
I put uemacs (em) but not fully debugged. It is a nice challenge to put emacs ! I keep you informed
i love it, but whats up with the tomgue twister name? :)
Ex æquo is a Latin expression
All your comments are so encouraging. Thank you very much !
Interesting idea. Strange choice to pick Bash as your default shell though. If you're writing a new OS you don't have to repeat the mistakes of the past.
What’s wrong with bash? It’s fine. Of course, the first thing I do on any system is install PowerShell.
Do you think I can put PowerShell is a Unix like system ? I thought it was for Windows only
* Unstructured piping is unreliable and awkward
* It's extremely weakly typed
* It's full of gotchas and surprising behaviours
* It's extremely fragile
In short, it's extremely difficult to write Bash that is correct. Just add a space to your home directory and you'll see.
That's generally not too much of an issue for commands you're running interactively. The problem is people think "well I've got a command that seems to work for me! I'll save it in a file", and now you have a janky broken script.
Which shell are you using?
For work, Bash, because I have no choice. This project does.
What do you suggest instead? What's wrong with bash?
Feel free to propose an alternative that can be compiled in WebAssembly. I was happy succeeding to compile Bash and to make it working
Nushell seems like the obvious choice. It's modern and well designed and written in Rust so compiling to WASM should be easy. Actually it looks like they have already done it:
I have to try compiling a rust program but not sure it is so trivial integrating it into exaequOS. I use and abuse of async calls
Bash's problem, as well as its selling point, is that it is both "good enough" and "ubiquitous" (both in installations and inside the many, many brains of devs) which means that it is essentially the JavaScript of shell, and will thus never go away.
I used to try to fight it, then I decided to accept it, and things have gone better since.
I actually think something like es-shell https://wryun.github.io/es-shell/ is (or would have been) the most underrated possible replacement for bash, but oh well
As you say it is good enough. As I am doing this project alone now, it is a lot of work. If people help me in the future, why not including other shells
OS running in a browser sounds like kid driving a Walmart cart
A web browser is a perfect virtual machine
Operating system is intended to take care of tasks and hardware interactions. While browser acts recently as an OS itself, this exaequOS is at least an OS in OS in an OS.
Yes, I can call it OS cube
Similar idea that I had in my mind is to compile Linux to webassembly and run it in the browser. I don't have skills for that, however it seems to me that Linux is more mature than new operating system and webassembly surely could work as yet another architecture for Linux.
A kind of French obsession ;-)
I also immediately thought of jslinux but it's actually not the same thing: it's not Linux compiled to wasm running directly in the browser, it is a hardware emulator in JS and Linux (and a few other OSs actually) running on the emulator.
To my opinion, emulation cannot be a real ecosystem for developing web apps
You do not need a scheduler in a web browser. In exaequos, each process is an iframe
How do you do inter-process communication then?
Why not do async in the same wasm unit?
Interprocess communication is done via Broadcast channel. It is simpler I think to have one iframe per process. Then it can support pthread
> via Broadcast channel
As in via a websocket over a backend?
probably just regular iframe postmessages through a channel
true thinclient dream
indeed - a dream of possibilities, if people can get their act together and implement something that from the user perspective looks UNIFORM (see my other reply).
I have never understood the appeal of thin clients for individuals. I guess they make sense for businesses. Are you saying you want a thin client experience for yourself? If so why on earth would you want those limitations? (Eg latency and dependency on an internet connection). Modern machines like the m1 air give you excellent battery life, lightweight form factor, and quite acceptable performance. If I need access to something faster, tailscale + ssh make that easy enough to do regardless of where the faster machine is located.
What would a thin client let you do (or how would the experience be better) that a decent laptop doesn’t already do a better job at?
In fact, it is not a thin client since all is executed in the client. it is more a thin server that is just a file server. The idea is to take benefit of the power of the device (more and more powerful)
Chromebooks and smart TVs are essentially thin clients, and they do just fine for many home users, businesses, and education markets.
The idea of having to run a heavy app on your own hardware doesn't really make sense anymore unless you're a creator of some sort, whether a dev or a video or games or whatever person (and even then some of that happens in the cloud these days).
If I were going to school or doing generic office document work, I wouldn't want to chug along a $1000 machine just to be a glorified note taker. Even doing the dev work, a lot of the code workspace in the cloud services are slowly but surely maturing, and are much more reproducible than individually setting up dev machines with their own node etc environments. Docker doesn't do so well on Macs either, with larger codebases especially.
Don't get me wrong, I love my MacBook, but it's not the right tool for every person or every job.
Running GNU chess on exaequOS on Chrome on my MacBook Pro is enough powerful ;-)
But how long before we can run exaequOS inside Chrome inside Docker inside Darwin inside exaequaOS inside Chrome on your Macbook Pro?
When somebody will be enough fool to do it :-)
What's the difference between an OS and an emulator in this scenario?
Linux is not designed for being executed in a web browser. Emulation will be slow. With exaequos, applications are in webassembly. It will both an application store, a common development environment and an isolated machine
I guess it's a cool idea. No shade meant at all, as obviously you've done more than me, but this seems to be missing quite a bit.
ls /bin
bash fb ip localfs login mingetty netfs pipe resmgr sh sysvinit tty
It seems you can run shell builtins that don't depend too heavily on having real proc, dev, and sys filesystems or FHS compliance, and that's about it? Is there a way to write a file? Attempting a heredoc gave a "resource busy" error. Redirecting echo to a filename didn't complain, but there is no file present after doing it. echo $? says bad file descriptor. Is there a way to query exit status of the commands you run?
Bash knows the exit status of a program. Maybe all is not operational
Note that there's also a /usr/bin, with complete GNU coreutils (or at least most of them), and vim.
And /usr/games/ :-)
ip is the driver that we will be used for connecting the browser to the server through web socket. Then apps will be able to open TCP/UDP sockets
There is a login because I use mingetty process. For sure a lot of work remains...
For writing a file you can use ed or vim. > also works but after you are blocked
Great idea - your demo made me think that Web assembly finally permits proper Web applications with a proper UX and without abusing HTML, HTTP, XML, JavaScript and the browser.
I wish there was a new standard for that, instead of everyone brewing their own thin client app soup; perhaps now is the time to get something like that started.
On the desktop, there were CUA, MOTIF, CDE, and other proposals [2-10], and ISO has codified UI best practices in [1].
[1] https://en.wikipedia.org/wiki/ISO_9241
[2] DIN 66234 part 8 standard [1988]
[3] The Data Company's standard
[4] Apple Human Interface Guidelines [1987]
[5] Motif™ style guide [OSF 1990]
[6] "Advanced CUA" (for graphical interfaces) [IBM 1990a]
[7] "Basic CUA" (for traditional terminals) [IBM 1990b]
[8] Original CUA [IBM 1987] 340
[9] OPEN LOOK™ [Sun Microsystems 1990]
[10] Smith and Mosier [1986] guidelines
> Web assembly finally permits proper Web applications with a proper UX
> ... and ISO has codified UI best practices
Web Assembly has literally nothing to do with UI/UX.
UI in the browser can only be achieved via HTML+CSS, Canvas, WebGL, or WebGPU. And only one of them has some high-level components for UI. And none of them have any WebAssembly bindings. It all goes through Javascript APIs.
So if you want to create some UI standard for new apps, you start with a UI standard for WebGPU, or WebGL.
> I wish there was a new standard for that, instead of everyone brewing their own thin client app soup
One hundred million times THIS. It’s truly insane how much wasted human effort has gone into half-assedly recreating the same UI patterns over and over and OVER AND OVER AND OVER again. If we had this standardized from the beginning, the human race would span the solar system, there would be no war, no hunger, no famine, cancer would be cured, and things would generally be pretty rad.
But alas.
Thank you very much for your detailed comment. That is the philosophy behind exaequOS, not rewriting apps. I am porting wayland since recently
Do those older UI standards deal with responsive and touch elements?
I agree that it's high time for a set of "web app UI framework" primitives and best practices, something like Material or MUI but actually a collaborative standard. It's stupid to have to reinvent basic cards, modals, wizards etc. from scratch every time.
But the web has also rapidly evolved alongside newer needs and form factors (phones, geo stuff, real-time multiplayer, etc.) in a way that a lot of older UIs didn't explicitly account for.
And also, WASM right now doesn't really have a UI layer. And Canvas doesn't work that great with responsiveness.
Not that I disagree with what you said; it's a great goal to aim for!
> primitives and best practices, something like Material or MUI
Material is very far from best practices. Their "designers" had to conduct user studies with hundreds of people to figure out that "text fields have to look like text fields" and still failed to do that: https://medium.com/google-design/the-evolution-of-material-d...
I agree! We usually tend to modify away Material's default minimalism in favor of usability, too.
But I'm just trying to point out the difference in goals between a cross-platform OS and a cross-platform UI framework.
Why are you saying that canvas does work great with responsiveness ? Do you mean that drawing in canvas is slow ?
Doesn't, you mean?
Elements inside a canvas can't be easily reflowed around each other the way you can with divs and blocks and flex and grid etc. You basically have to reinvent the responsive UI layer that CSS has been slowly improving over the last decade or two.
Is that what you were asking, or did I misunderstand?
Yes, doesn’t work great (sorry )
You replied exactly to my question. The idea behind exaequOS is not reinventing CSS at all but to support “Classic” apps (terminal, graphic toolkit, OpenGL) and html/css apps
Oh absolutely! Sorry, that comment wasn't directed at exaequOS, but discussing some older human interface guidelines and older UX standards. Just pointing out that interfaces have evolved since then.
But that's not the point of exaequOS and that's okay!
Those already exist:
https://www.radix-ui.com/primitives
https://react-spectrum.adobe.com/react-aria/
Even MUI has one :https://mui.com/base-ui/getting-started/
-
There are some attempts for a lower level version of this at the web component level, but they tend to do nowhere
Right, exactly, but I'm saying it's too bad those things aren't part of the living WHATWG standards/guidelines, and built into HTML or some new higher-level component markup language that browsers can adopt. A "Javascript UI components framework" similar to the UI kits that native Android and iOS have.
It's silly to have to reinvent all those basics for every site/company/platform, and it's unfortunate that HTML hasn't really caught up to the app world, still thinking of itself mostly for documents.
It is an OS that is able to run Unix/Linux applications locally, in a terminal at the moment, with a graphical environment in the near future. Its microkernel is compiled from C to WebAssembly thanks to emscripten
Is this the source? https://github.com/baudaux/exa
The source of the changes I did in emscripten is also important for understanding the syscall mechanism
Yes, it is the source of the kernel. It is a POC at the moment. So please be indulgent :-)
How much OS development/effort are you able to skip by building it on a browser/WASM instead of normal hardware? I don't know if you are effectively recreating a low-level machine on top of the browser's high-level APIs, or using the high-level APIs to skip substantial parts of the implementation.
How serializable is the state of the OS? Can you freeze and move the image? What resources can't be preserved? (E.g., open sockets... but then you don't really get raw sockets on a browser anyway; still WebSockets/etc can't be transferred.)
A big effort, even if I do it during my spare time
It is a kind of micro kernel architecture. So the state is spread through resource manager and drivers. Real sockets are (will be) opened on server side. Websocket will be used for the tunnelling