Show HN: exaequOS - a new OS running in a web browser
exaequos.com
exaequos.com
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.
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
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.)
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
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.
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!
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
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.
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...
But I'm just trying to point out the difference in goals between a cross-platform OS and a cross-platform UI framework.
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
But that's not the point of exaequOS and that's okay!
> ... 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.
[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...
Just watching it back again now - he jokingly predicts slower technological progress globally between 2020 and 2025 due to a world war. Damn.
Why not do async in the same wasm unit?
As in via a websocket over a backend?
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.
Do you share some information about the software architecture ?
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.
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.
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?
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
Then this in chromium, recursively, ad nauseam.
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?
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.
"ex" is a preposition meaning "from".
Maybe present your criticism in your native language, and someone can translate it for us.
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
* 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.