Tumble Forth | Hacker News Reader

Tumble Forth

tumbleforth.hardcoded.net

144 pointsjtoledo22 comments

Excellent list of articles. I suggest people to look more into the author's CollapseOS, their research into a post-collapse minimal operating system to bootstrap computing anew.

OSDev is such a fascinating and lost topic, due to how niche it is and how computers and hardware have become a complicated mass of abstractions only a few have full access to. Writing a OS that talks with 90% of your hardware is relatively doable, writing a GPU driver is pretty much impossible these days unless you are the manufacturer.

We need more research into alternative computing. We need to move past UNIX which has served us well but it is a local maxima, not the best we can do. We need to return to the roots somewhat (maximecb's uvm, Devine Lu Linvega's uxn, etc.) to find a way forward.

I started with OsDev at 16 [1], had to find a regular boring job for the rest of my career, but my goal right now is to bootstrap my own small "lifestyle" business to find money, time and freedom to explore the world of bare metal alternative OS again. Something Lispy and Smalltalky to power the entire thing. I wrote a bit about it in my website. [2][3]

Sorry for the tangent. I love OSDev. Many of you would too, I bet.

1: https://github.com/1player/klesh

2: https://combo.cc/posts/in-search-of-the-holy-grail/

3: https://combo.cc/posts/what-i-would-like-to-see-in-a-modern-...

I love diving into other peoples forths and checking out what trade offs they made. After figuring out the model (theaded, token etc.) I usually jump to the flags, dictionary layout and then the assembler (in forth) if it has one. My favorite is still f83 - it’s a masterpiece.

Which F83?

F83 Forth by Laxen & Perry https://github.com/ForthHub/F83

Why is F83 your favorite?

Then you might be interested in my Go implementation of Forth [1]. No assembler required, but bootstrapped and with some rudimentary internal type checking. The heap is just an `[]any` type array.

It runs in the browser via WebAssembly.

[1] https://github.com/s-macke/Forthly

As brilliant as these bootstrap efforts are, I wonder if it would be a good decision to abandon all the business and application software in a civilization collapse. Someone on the GitHub project page for collapseos made a good comment to the effect of having gone through the software and hardware limitations of the late 70s and 80s, wouldn’t it be better to get follow the best practices of the era without the patent limitations? I think as I go along, I agree more and more with mental model. Esoteric hardware aside, it would be best to come up with a base model for the era of early personal computers then figure out a way to bootstrap a freedos on top of a unix type of operating system underneath and time share on top for users to log in using terminals. But that’s just my mode of thinking. Originally collapseos seemed to follow the BASIC model then it became about forth.

See the author's own efforts under "DuskOS"

It's the geek version of prepping.

It isn't about taking prudent steps to cover yourself again likely scenarios.

It's an excuse to put a flamethrower on you pickup / write you own software stack from scratch.

> wouldn’t it be better to get follow the best practices of the era without the patent limitations?

You could gain a large amount in energy efficiency and portability over implementations from that era as well. A small pocket computer that runs well crafted software and a battery that lasts for weeks.

You could definitely argue that it would be better to build off of something like Contiki, a modern small-device OS that gained a lot of fame for its ports to old microcomputers, but is currently active in industry as well, with a new "Contiki-NG" version.

The appeal of Forth is mostly in a principled sense of, if you want Forth to be your interface, you have to build your own Forth, because Forth does as little as possible to structure you. And building your own Forth is not impractical; that's the whole point. It's wonderful as an exercise and can be productive in the right context.

But any highly developed or standardized Forth system gradually converges on being "just another platform." And once it's just another platform, it's an annoying dependency, and you end up demanding more structure for it to help tame the complexity, so the Forthiness habitually erodes.

I couldn't imagine using Forth for all of my programming, but personally I quite like the thought of underpinning a more complex system or language with a small language like a Forth or Scheme, or just something borrowing key elements. Use them to shape the basic structures at a level where they excel, and then put one or more other options on top, and interfacing with a layer far more pleasant than a bare machine.

E.g. for my experimental long-languishing Ruby compiler I bootstrapped a tiny typeless s-expression based language - not a lisp/scheme, just borrowed some syntax - to let me "escape" the warm embrace of Ruby to bootstrap the basics. It wasn't very carefully planned, and there are many things I'd like to change when I get time to play with that project again (it's been literally years, but it's not forgotten), but that aspect is part I still like, though I might like to change parts of that low-level language too.

> I wonder if it would be a good decision to abandon all the business and application software in a civilization collapse

Why do you think it will be a decision instead of something that just happens due to sudden/slowly approaching physical unavailability of required hardware?

There's no reason you can't run things like spreadsheets, databases, file managers, IDEs, drawing apps, web browsers etc on extremely low-powered hardware. As long as software is designed to work within the limitations.

What's lacking from discussions about projects like Collapse OS, Dusk OS, Uxn & similar, is discussion about peripherals. In particular: screens.

Nice you can run a small OS on a uC if needed. Bring it down to 1W, 0.1W or even less power consumption. Keyboards can be hand-wired switches if necessary.

But then what? Make do with a 16x2 character LCD? Attach 15+y old VGA monitor that consumes 30W? Attach (expensive) epaper screen that will also be thin on the ground in a collapse scenario, and can't be fabricated if technology falls away? Go back to switch frontpanels & lightbulbs?

It's easy to toss a heap of IC's & flash media into safe storage. Wiring, circuit boards, soldering iron, documentation printouts, some way to produce electricity: done. But produce OLED screens in post-collapse low tech society? Good luck with that.

Would be nice if there were at least some discussion about viable pathways there. No point having compute if you can't see what it's doing.

You bring an interesting point for Collapse OS. For Dusk OS it seems to be imagined for a period where old stuff will still be available, so there will be plenty of old computer screens or TVs around.

I wonder how much power a teleprinter consume? Or a modern version of it?

Incandescent light bulbs (combined with "light-pipes") has been used for calculator displays [0]. If we're going to even less electronic and more mechanical devices, herkons/relay switches and rotating drums (with engravings) exist. Card-punching devices could probably be an inspiration too.

But all in all, I'd imagine we'd have to settle on scraping the old equipment stocks. I bet there are piles of discarded but still useable CRTs lying around somewhere.

[0] http://www.vintagecalculators.com/html/calculator_displays.h...

Yes, this space is high on tradeoffs.

With plenty of source power, pixel grids are flexible. You can construct these from LEDs and paper, https://www.youtube.com/watch?v=QWGoC-9z2Qw. Or chain together 16x2 displays, or use flip-dot displays if you can source them.

If you are low on power, morse-code over a single LED would go a long way - low on equipment cost. Audio output and radio could also be decent low power outputs.

Seven-segment displays are workhorses. Restrict the interaction to hexidecimal characters.

Other obstacles for post-apocalyptic computing are power and storage.

For power - generation itself could be ok from a bicycle. But you need a way to buffer the power.

For storage - FeRAM should be a good option. Will not decay like conventional disks, so long as you repopulate it every few years.

Hugged to death?

Works for me but here is the archived version https://web.archive.org/web/20231107232338/http://tumblefort...

The site doesn't seem to support HTTPS, but HTTP works fine. (This might be intentional; all the links on the home page have http: URLs, not https:.)

The two linked operating systems, Collapse OS and Dusk OS have the following descriptions:

Collapse OS

> preserve the ability to program microcontrollers through civilizational collapse […]

> Runs on Z80, 8086, 6809 and 6502 machines with very little resources

Dusk OS

> Dusk OS is a 32-bit Forth and big brother to Collapse OS. Its primary purpose is to be maximally useful during the first stage of civilizational collapse, that is, when we can't produce modern computers anymore but that there's still many modern computers around.

In these scenarios it makes sense to give up on TLS. So probably that is why the author decided to serve their sites over plain HTTP only.

There's a difference between supporting unencrypted connections, and only handling unencrypted connections. Since civilization has not yet collapsed, I wish they would support both.

Reply on news.ycombinator.com