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
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
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.)
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
Is a server required for exaquOS functionality? Beyond serving it of course, I'm excited to run all this stuff locally and requiring a server normally defeats the point of something running in a browser.
The server is used for serving the files (mostly) and a few commands for netfs file system (in php at the moment). On my laptop, i have a local server in nodejs. Later on, the server will be used for the IP stack
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].
> 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.
> 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.
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!
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.
> 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...
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?
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!
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.
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.
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.
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)
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.
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.
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.
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
I assumed "ip" was the tool from the iproute2 package, but typed in "ip a" out of curiosity to see if this really set up some kind of virtual devices, and it has hung ever since, not dropping me back to the shell. crtl-c doesn't seem to do anything. There is no /etc/passwd or /etc/groups files, so whoami and groups can't map the ids to names. The login is weird if everyone is root. Why not just drop straight to the shell? It seems to exist only to be able to set the environment variable for a user name, but it's not actually a username.
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?
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
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.
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.
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.
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.
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.
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
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.
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:
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
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.
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.