Compile Linux kernel to wasm. So it can run inside a browser with a very nice performance.
Write FS drivers to enable seamless caching and remote data storage, so you can shutdown your system on PC and boot from laptop. Or even some kind of hibernate mode, so you can just continue from where you left off.
Write graphics drivers using WebGPU and other technologies, enabling very nice performance. May be not perfect for AAA games, but for anything less demanding it'll work.
So basically make a proper Linux port for browser and then reuse all the applications already built.
Rather than the "easy" way of porting an x86 emulator to WASM, I've been trying to natively port the Linux kernel to WASM.
UML[0] and LKL[1] prove that running the kernel in a process is viable. μClinux efforts like NOMMU and binfmt_flat prove that you don't need memory-management nor ELF to run the kernel.
Both my own independent experiments and WALI[2] have shown it's possible to port the Linux syscall interface and userland ecosystem to WASM.
I'm confident it's doable, but there are a number of other challenges to solve along the way (like dynamic linking, the Harvard architecture, etc). Currently I'm blocked on the fact that while the kernel supports running non-ELF binaries, it really wants to be an ELF itself.
The point would be to run the browser directly on the hardware without any intervening useless layers like X-Windows or Wayland, then implement the desktop environment in that, and when you needed to pop up a browser window on the desktop (which you always need to do frequently), or an html app like you'd usually run in Electron, simply and efficiently use the same browser that's running the desktop environment, sandboxed the way all modern browsers now already implement their renderers isolated from their chrome ui frames.
No need to run the user's browsers separately inside a slower layer of emulation, when you already have a browser implementing the desktop.
Fewer layers and less bloaty software is better. We're already stuck with the browser, and it's not going away, so use it for everything. X-Windows and Wayland are obsolete and useless, so should be flushed.
At that point, you aren't using anything on the host browser except the WASM interpreter and the canvas element, so why bother with any of its other components?
Because the other components are extremely useful for implementing a desktop user interface, and you need the other components anyway to implement the user's web browser, of course.
Why isn't this obvious? I already said "when you needed to pop up a browser window on the desktop ... simply and efficiently use the same browser that's running the desktop environment". Did you read what I wrote?
Why restrict yourself to running WASM on a canvas element? Maybe the desktop wants to draw something with html and css and svg. As they tend to do. Did you run DaedalOS? Do you think that's all implemented with WASM and a canvas element?
Go back and read what I read please. You're arguing about something I didn't say, and ignoring what I did say. I never said to implement the desktop in only WASM and canvas.
And it's not about cloning Windows 95, it's about providing a flexible extensible platform for making much better desktop user interfaces than Windows 95 and everything else.
I'm glad I was able to finally make my point. But if you're not willing or able to read and understand what we're discussing, and respond to what I'm actually writing, then please don't bother trying to participate in the discussion, so I don't have to repeat myself to somebody who won't listen. Just sit this one out. Thanks!
Edit: you just did make my point that you weren't listening, and that you have nothing to contribute to the discussion, but I'll let you have the last word since that seems to be all you want. Unless you want to pointlessly announce you're going to leave again.
Current desktop user interfaces are terrible, and we need the flexibility of a web browser to innovate and implement better ones, since Wayland is simply not up to it, because it's not extensible at runtime in JavaScript or any other language. (No, recompiling or dynamically linking in DLLs doesn't count -- that's just ActiveX.)
Web browsers are a terrible place to do innovations, a major problem being the absolute backwards compatibility they need to maintain. Web standards are massive complexity beasts which are constantly growing and basically none of that can be dropped. The dynamicity of JavaScript is actually a major problem for performance (difficult to optimize beyond a certain point), that's a major motivating factor for WASM, but that has its own problems (no direct access to DOM).
You can implement the innovations in JavaScript and WASM and other standards that are already there. Just like the subject of this discussion, a Windows-like desktop, is implemented in JavaScript and HTML and CSS and canvas and whatever else. That's all perfectly sufficient.
As complex and backwards compatible as web browsers and JavaScript are, you already need all that complexity anyway and already end up paying for it all. So why not use it to implement the desktop too?
I'm not proposing eliminating the web browser. Are you? I'm just saying use the web browser you already have all the way down, instead of re-implementing part of it.
The problem with DaedalOS is that it doesn't bother to innovate, it just implements old designs: Windows 95 or so. No pie menus, no tabs, no virtual desktops, no rooms, just old ideas.
But those old designs are not hard-coded into the browser, they're all just software you load into the browser and can change. Why not be able to change the entire actual desktop that way?
> Why not be able to change the entire actual desktop that way?
I think you need to invert and ask - why to do all this? You'll get much worse performance, many extra layers when you need more direct access to hardware etc.
> Web browsers are a terrible place to do innovations, a major problem being the absolute backwards compatibility they need to maintain.
How so? The biggest innovations in the browser in recent years have been shadow-DOM type stuff like React/Vue, plus WASM and WebGL. None of these are backwards compatible with older browsers.
Like what? Sites don't ask me to allow ActiveX or check if I have Flash installed, and CSS support across browsers is not uniform even now. JQuery did more to ensure JS compatibility across browsers than the vendors themselves.
20 years ago I had one of my most memorable dreams. I was in the bridge of a Star Trek ship. Something bad was happening. The captain gave an order. I yelled "belay that order - I'm from a higher level". The captain said "I am a level 4!" I replied that I was a level 10.
100 years before our simulation developed The Browser, Hegel wrote book about it. IIRC he predicted the World would end once the Geist would become self aware. Do we know better and tell it is just a stack overflow of recursive browser instances?
interesting. I use macos screen sharing in a similar way. it has pretty high integration with the remote desktop - allowing rich copy/paste and file drag/drop from the desktop back and forth to the remote desktop.
Another useful mishmash of technology is pikvm, a kvm based on the raspberry pi.
You connect the pi to a machine via USB and HDMI, and remotely access it through the web browser.
The pi will digitize and send you HDMI out, and relay your keyboard and mouse to the remote machine.
What's fascinating is that pikvm can also emulate a usb flash drive, so from your browser you can give it a liveusb image and boot and run it on the remote machine.
I wonder what the venn diagram is between people that want this and those that buy a new laptop every few years. Because you can say goodbye to responsive IDEs, indexing and disk performance. And when you’re on spotty WiFi you have intermittent access.
What's the trade-off? I'm giving up performance and simplicity (well, what's left of it in a kernel as complex as Linux), for what exactly? To run the same apps I can already run natively? Which apps exactly - TUI apps that can already run over an SSH connection? Electron apps that already run in a browser? Are there any native apps that are worth the effort? Emacs, GIMP, Audacity, Blender, or DaVinci are all cross-platform. Or do you have an idea for an app that would be better off targeting Linux rather than the web, but won't suffer from the performance loss?
The idea is to have your entire work space in one place. Gimp, PDF viewers, IDE (not just VS code), terminal tabs, running docker containers with your application.
Basically just what you would do with some kind of remote desktop. But it's not remote, it runs locally, with perfect latency. And it's easy to switch to another computer with any underlying host OS, without even interrupting your applications (if hibernate idea would work).
This doesn't seem quite right to me. The browser is analogous to an operating system, and tabs to applications. Embedding a whole OS into a single page could have niche uses, like software ports or "fun", but I doubt it will ever become a dominant way of using software. All that seamless session stuff is quite achievable by syncing browser state. It's already popular to sync tabs and tab groups and such, so why not JS/WASM engine state and other stateful elements of tabs?
Compile Linux kernel to wasm. So it can run inside a browser with a very nice performance.
Write FS drivers to enable seamless caching and remote data storage, so you can shutdown your system on PC and boot from laptop. Or even some kind of hibernate mode, so you can just continue from where you left off.
Write graphics drivers using WebGPU and other technologies, enabling very nice performance. May be not perfect for AAA games, but for anything less demanding it'll work.
So basically make a proper Linux port for browser and then reuse all the applications already built.