Show HN: exaequOS - a new OS running in a web browser(exaequos.com)
exaequos.com
Show HN: exaequOS - a new OS running in a web browser
https://www.exaequos.com
109 comments
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
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.)
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
A big effort, even if I do it during my spare time
[deleted]
Is this the source? https://github.com/baudaux/exa
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
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
> 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.
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.
> 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.
> ... 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.
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!
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!
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
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'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...
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.
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?
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
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!
But that's not the point of exaequOS and that's okay!
ExaequOS could also run html/css/webassembly apps in order to take benefit of web ui frameworks.
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...
[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.
[1] - https://www.destroyallsoftware.com/talks/wat
Just watching it back again now - he jokingly predicts slower technological progress globally between 2020 and 2025 due to a world war. Damn.
[1] - https://www.destroyallsoftware.com/talks/wat
"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.
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.
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?
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?
As in via a websocket over a backend?
probably just regular iframe postmessages through a channel
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
A kind of French obsession ;-)
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.
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)
Very cool, I will check it out.
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 ?
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.
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.
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.
exaequOS is a full system, a kernel with drivers and apps. You can execute several apps in parallel
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.
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?
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?
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
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
Bash knows the exit status of a program. Maybe all is not operational
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
OS running in a browser sounds like kid driving a Walmart cart
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?
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.
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.
Pretty cool! How do you persist storage?
Localfs driver uses littlefs and indexedDB
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
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.
https://en.wikipedia.org/wiki/Ex_aequo_et_bono
"ex" is a preposition meaning "from".
"ex" is a preposition meaning "from".
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
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.
Maybe present your criticism in your native language, and someone can translate it for us.
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
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.
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:
https://www.nushell.sh/demo/
https://www.nushell.sh/demo/
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
What do you suggest instead? What's wrong with bash?
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
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
What’s wrong with bash? It’s fine. Of course, the first thing I do on any system is install PowerShell.
* 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.
* 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.
Do you think I can put PowerShell is a Unix like system ? I thought it was for Windows only
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.