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.)
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!
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.
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 ?
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?
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).
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.
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.
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
[+] [-] p4bl0|2 years ago|reply
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.
[+] [-] baudaux|2 years ago|reply
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
[+] [-] baudaux|2 years ago|reply
[+] [-] ianbicking|2 years ago|reply
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.)
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] kaycebasques|2 years ago|reply
[+] [-] jll29|2 years ago|reply
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
[+] [-] corytheboyd|2 years ago|reply
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.
[+] [-] troupo|2 years ago|reply
> ... 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.
[+] [-] baudaux|2 years ago|reply
[+] [-] solardev|2 years ago|reply
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!
[+] [-] DavidPiper|2 years ago|reply
[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...
[+] [-] baudaux|2 years ago|reply
[+] [-] vbezhenar|2 years ago|reply
[+] [-] baudaux|2 years ago|reply
[+] [-] peterkelly|2 years ago|reply
[+] [-] DustinBrett|2 years ago|reply
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.
[+] [-] baudaux|2 years ago|reply
[+] [-] baudaux|2 years ago|reply
Do you share some information about the software architecture ?
[+] [-] tazjin|2 years ago|reply
[+] [-] baudaux|2 years ago|reply
[+] [-] gjsman-1000|2 years ago|reply
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.
[+] [-] solardev|2 years ago|reply
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.
[+] [-] baudaux|2 years ago|reply
[+] [-] nonameiguess|2 years ago|reply
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?
[+] [-] strooper|2 years ago|reply
[+] [-] p0w3n3d|2 years ago|reply
[+] [-] baudaux|2 years ago|reply
[+] [-] hexo|2 years ago|reply
Then this in chromium, recursively, ad nauseam.
[+] [-] baudaux|2 years ago|reply
[+] [-] joshxyz|2 years ago|reply
[+] [-] baudaux|2 years ago|reply
[+] [-] baudaux|2 years ago|reply
[+] [-] throwawayxAA13|2 years ago|reply
[+] [-] jll29|2 years ago|reply
[+] [-] shortlived|2 years ago|reply
[+] [-] baudaux|2 years ago|reply
[+] [-] baudaux|2 years ago|reply
[+] [-] pmarreck|2 years ago|reply
[+] [-] baudaux|2 years ago|reply
[+] [-] teakie|2 years ago|reply
[+] [-] WolfeReader|2 years ago|reply
Maybe present your criticism in your native language, and someone can translate it for us.
[+] [-] baudaux|2 years ago|reply
[+] [-] IshKebab|2 years ago|reply
[+] [-] baudaux|2 years ago|reply
[+] [-] thelastparadise|2 years ago|reply
[+] [-] pmarreck|2 years ago|reply
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
[+] [-] fortran77|2 years ago|reply