4 ms·

Probably just an emulator if you want that to actually work. Yes, it does take decades to wrap one’s head around all that stuff, but you don’t have to in order

by zepto 6y ago

Probably just an emulator if you want that to actually work. Yes, it does take decades to wrap one’s head around all that stuff, but you don’t have to in order to have a straightforward programming experience. Take this for example: https://docs.racket-lang.org/quick/ https://docs.racket-lang.org/quick/ Almost as simple, vastly better to learn. And it’s not like we understood how graphics worked, or how the basic interpreter was built in order to type those commands anyway. Even if some of us do now, most people who used those machines never understood them. I do agree with you in essence - I want that simplicity back, but I don’t miss actually using those machines. I wrote some quite complex software in BASIC, and have no desire to return to that. I want something with the immediacy and programmability of that era, but with modern capabilities and programming concepts.

7thaccount 6y ago
Yeah, I basically want a machine with a fast CPU and lots of RAM that boots into something like LISP or Forth with a very minimal OS (SD card navigation, text editor, image and audio file player, simple graphics).
- cturner 6y ago
  We have a group that has been playing with that concept, songseed.org/dinghy, including the notion of a ‘forth workstation’. Through this, I have found networking to be a significant design pressure on the rest of the system, inviting complexity. The comparison of retrobsd and litebsd in the pic32 paper talks about this. Another conclusion - if you want the platform to be relevant on high end hardware, you must use Windows or Linux as part of your foundation due to the gpu driver situation.
  - 7thaccount 6y ago
    It sounds like you've thought this through pretty well. Once you add in networking and a web browser, it might not be possible to avoid all that complexity.
    - cturner 6y ago
      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. Tanenbaum warns of the dangers of an async systems API (http://songseed.org/dinghy/tanenbaum.html 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.

by zepto 6y ago

7thaccount 6y ago

Yeah, I basically want a machine with a fast CPU and lots of RAM that boots into something like LISP or Forth with a very minimal OS (SD card navigation, text editor, image and audio file player, simple graphics).

cturner 6y ago
We have a group that has been playing with that concept, songseed.org/dinghy, including the notion of a ‘forth workstation’. Through this, I have found networking to be a significant design pressure on the rest of the system, inviting complexity. The comparison of retrobsd and litebsd in the pic32 paper talks about this. Another conclusion - if you want the platform to be relevant on high end hardware, you must use Windows or Linux as part of your foundation due to the gpu driver situation.
- 7thaccount 6y ago
  It sounds like you've thought this through pretty well. Once you add in networking and a web browser, it might not be possible to avoid all that complexity.
  - cturner 6y ago
    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. Tanenbaum warns of the dangers of an async systems API (http://songseed.org/dinghy/tanenbaum.html 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.