I feel like I have only scratched the surface :) If you take interest in this, we hang out in #dinghy on freenode. We have bursts of activity, and then long periods of silence.
But I do feel like the world is ripe for a revolution in a few directions here.
-- Browser
To your point that a conventional browser creates unavoidable complexity: I agree.
It may be possible to disrupt that stack entirely, by creating something that developers would prefer to develop for.
The new conversational interaction between whatsapp users and corporate chatbots (e.g. airline rebooking over whatsapp) shows developer and user appetite for non-HTTP internet activity. As does Slack, somewhat.
This gopher-like 'Gemini' thing that has been popping up recently is interesting.
On the Dinghy website, there is a proposal for an engine, /Limit/. It would be a Forth VM that would maintain an async connection back to a webserver-like server. Instead of having HTTP+HTML+CSS+Javascript, you would deliver sites as forth bytecode. This could be tighter yet more flexible than a web browser. An Everything-Is-A-X based overthrow of the current web browser model.
/Limit/ could be simulated in a browser (using javascript and websockets) so that people who only had a browser could browse a Limit server without adding new software.
Hypothesis: /Limit/ would have common purpose with alt-OS communities that do not have first-class browsers: Haiku, Plan9, Amiga, Suckless, people who run old SGIs for fun. Imagine if you could just recompile a C codebase, and change some headers, and get a full-featured browser-like thing running on these systems.
-- Networking
I am confident that there is a non-complex path through this problem.
Hypothesis: interaction with the systems API should be purely asynchronous, and TCP interaction will look nothing like the Berkeley sockets API.
But there is an occam-based OS, RMoX, that looks to be a demonstration of the async OS concept. I hit obstacles trying to evaluate/verify this.
On the Dinghy website, there is a paper for "Drift". This proposes an async OS for the amd64 architecture. I noticed drafting problems in this paper earlier, will revise soon.
The addition of io_uring to Linux may allow another approach: create an async API mezzanine on io_uring; regard this as your Bedrock, rather than the hardware itself.
Once io_uring is mature, it may be possible to fork Linux in order to discard /all/ syscalls except io_uring. This kernel would have ongoing Linux driver support, but with a much smaller kernel surface area.
-- Your requirements
Regarding your stated requirements, 'SD card navigation, text editor, image and audio file player, simple graphics', you could build this on top of the Maximite architecture. But it would lack networking.
Whereas the Dinghy concept goes beyond your stated requirements.
Sounds like I'd love to play with the system y'all are hoping to build. I'd also be ok with something like a web browser, but just Forth scripts being shared like you said. As long as I have text and images and a way to view them, I don't think anything else matters.
It sounds like y'all are trying to build the original internet OS (iOS, but years before Apple took the term) that Carl Sassenrath of Amiga and Rebol fame was trying to build. Rebol is a lot like both lisp and forth, and is very powerful. Carl thought users would just share Rebol scripts over the network. To give some context, a fully graphical tetris is like 3/4 a page of Rebol code. If only he had open sourced it sooner.
Thanks for your note. I have had a several bursts of play with Red, but it keeps slipping my mind. I suspect it would be an easier starting point than building up Forth from nothing.
There may be a challenge bootstrapping that ecosystem on obscure platforms. If I remember correctly, you need an existing Red or Rebol in order to build the latest Red.
I will update the Limit page with a reference to this.
No problem. Rebol is built on C I think and is an interpreted language that I would guess is similar to Ruby in speed (as in fairly slow). Red should be a lot faster, but I wonder if they'll ever get there with the project being so ambitious. I do think you currently need Rebol to build the Red binary, but it'll eventually be fully self hosted and under 5 MB in size. A Red OS would be pretty neat as in you could use the high level words in interpreted mode and throw in some Red-System level code for performance if you need it. I'm a little concerned though that some of the high performance libraries will be commercial. I don't mind paying, but licensing always gets cloudy in those cases.
But I do feel like the world is ripe for a revolution in a few directions here.
-- Browser
To your point that a conventional browser creates unavoidable complexity: I agree.
It may be possible to disrupt that stack entirely, by creating something that developers would prefer to develop for.
The new conversational interaction between whatsapp users and corporate chatbots (e.g. airline rebooking over whatsapp) shows developer and user appetite for non-HTTP internet activity. As does Slack, somewhat.
This gopher-like 'Gemini' thing that has been popping up recently is interesting.
On the Dinghy website, there is a proposal for an engine, /Limit/. It would be a Forth VM that would maintain an async connection back to a webserver-like server. Instead of having HTTP+HTML+CSS+Javascript, you would deliver sites as forth bytecode. This could be tighter yet more flexible than a web browser. An Everything-Is-A-X based overthrow of the current web browser model.
/Limit/ could be simulated in a browser (using javascript and websockets) so that people who only had a browser could browse a Limit server without adding new software.
Hypothesis: /Limit/ would have common purpose with alt-OS communities that do not have first-class browsers: Haiku, Plan9, Amiga, Suckless, people who run old SGIs for fun. Imagine if you could just recompile a C codebase, and change some headers, and get a full-featured browser-like thing running on these systems.
-- Networking
I am confident that there is a non-complex path through this problem.
Hypothesis: interaction with the systems API should be purely asynchronous, and TCP interaction will look nothing like the Berkeley sockets API.
Tanenbaum warns of the dangers of an async systems API (http://songseed.org/dinghy/tanenbaum.html).
But there is an occam-based OS, RMoX, that looks to be a demonstration of the async OS concept. I hit obstacles trying to evaluate/verify this.
On the Dinghy website, there is a paper for "Drift". This proposes an async OS for the amd64 architecture. I noticed drafting problems in this paper earlier, will revise soon.
The addition of io_uring to Linux may allow another approach: create an async API mezzanine on io_uring; regard this as your Bedrock, rather than the hardware itself.
Once io_uring is mature, it may be possible to fork Linux in order to discard /all/ syscalls except io_uring. This kernel would have ongoing Linux driver support, but with a much smaller kernel surface area.
-- Your requirements
Regarding your stated requirements, 'SD card navigation, text editor, image and audio file player, simple graphics', you could build this on top of the Maximite architecture. But it would lack networking.
Whereas the Dinghy concept goes beyond your stated requirements.