Hello all,

The goals I have my eyes on for v12 aren't very difficult, so I brought dog-
fooding back on the table, that is, force myself to develop this release from
within Dusk OS.

This constraint allows me to see where tooling needs improvement and do those
improvements on the fly.

It's not the first time I want to take that dive, and I did in the past, but
only to come back to linux when the goal at hand became too difficult to add
the constraint of limited tooling on top of it. Because I have the habit of
nerd sniping myself with difficult goals, I often sling myself back to linux.

Dusk has a lot of nice features, but it needs better tooling. For example, it
should be easier to perform in-system upgrades[1].

So as I was deciding that v12 would be dog-fooded, I of course pondered about
the conditions needed to be able to say that I'd dog-food all of the upcoming
Dusk development. All I need is to avoid nerd sniping myself. And if I do, maybe
have the discipline to postpone that difficult development until Dusk's tooling
allow me to meet that challenge, dog-food style.

Discipline is not my forte, but with some luck, who knows, it might happen.

Then I made myself think of an upcoming big challenge to have an idea of the
tooling development involved, to end up with the m68k port in mind, which made
me think of the subject of emulators.

So far, my stance on emulators is that they are good development tools that I
wish to have in Dusk. My broad idea, for example in m68k's case, would be to
build a poor man's m68k emulator, just enough to build a Dusk kernel in it, then
try to deploy that kernel on one of my target machines.

I specifically never intended to add full-fledged emulators such as QEMU to be
in Dusk.

But even a poor man's emulator is very complex. Is that really the best route to
achieving a m68k port? Maybe not.

The naive alternative is to run everything on the target machine. But doing so
for a Dusk kernel likely involves a *lot* of back and forth, which will be
immensely tedious. Isn't there a better way?

Probably and I intend to try. For example, if, armed with a newly written
asm/m68k, I build a minimal monitor which would allow me to send arbitrary code
through the serial port and execute it, then that would reduce the back and
forth time by a huge amount.

Or maybe a mini forth. A forth who's kernel is much much easier to build than
Dusk's, built for the sole purpose of discovering the target machine.

All of this to say that I think I'll change my stance on the place I expect
emulators to play in Dusk. Maybe they're not as useful as I naively thought they
are.

Regards,
Virgil

[1]: compiling kernel and payload for the live system with some kind of ways to
not need another system to repair it in case of accidental bricking.

On Mon, Sep 30, 2024 at 05:53:54PM -0400, Virgil Dupras wrote:
> Dusk has a lot of nice features, but it needs better tooling. For example, it
> should be easier to perform in-system upgrades[1].
> [...]
> [1]: compiling kernel and payload for the live system with some kind of ways to
> not need another system to repair it in case of accidental bricking.

I don't know why I haven't done this before. The new xcomp/i386/pc/deploy[1] and
xcomp/arm/rpi/deploy[2] units are a joy to work with. They work very well.

For sure, I had done full rebuilding of kernel+payload in Dusk before, to prove
it was possible, but in my mind, this operation was time consuming and risky.
Using makefiles from duskos-deployments was easier, so that's what I did.

But with "rebootinto", things are really easy. You build the new kernel+payload
with a single command, then just reboot into it without risk, it works, you
build it again, commit it to disk, reboot for real. Voila!

[1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/xcomp/i386/pc/deploy.txt
[2]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/doc/xcomp/arm/rpi/deploy.txt

I was just re-reading James' email about how the collapseOS mailing list 
wasn't conductive to talking about broader topics, I was wondering if 
this was a thing I might have missed or is shared thoughts and 
experiment on the topic still welcome?

I got lots of little experiments that might be interesting to share, 
just wanted to make sure that it was fine to do so and that I haven't 
missed the memo or anything.

I spoke with Tiffany from WIRED about collapse computing today, I know 
she's contacted a couple of folks on here, I made sure to tell her that 
Virgil was working day and night to ensure that we could still make 
spreadsheets after the world caught fire ;)

Dll

AFAIK as long as you are talking about collapse-related tech you're
okay. I have a hard time believing anything 100r touches isn't gold
plated if you feel that we might be especially interested.

I guess if you have a new soundtrack for an 8bit adventure that's a
little bit of a stretch, but if you create some cool software for
creating 8-bit soundtracks that sounds completely on-point to me.

Best,
Rett

On Sat, Oct 5, 2024 at 8:11 PM Hundred Rabbits <rabbits@100r.co> wrote:
>
> I was just re-reading James' email about how the collapseOS mailing list
> wasn't conductive to talking about broader topics, I was wondering if
> this was a thing I might have missed or is shared thoughts and
> experiment on the topic still welcome?
>
> I got lots of little experiments that might be interesting to share,
> just wanted to make sure that it was fine to do so and that I haven't
> missed the memo or anything.
>
> I spoke with Tiffany from WIRED about collapse computing today, I know
> she's contacted a couple of folks on here, I made sure to tell her that
> Virgil was working day and night to ensure that we could still make
> spreadsheets after the world caught fire ;)
>
> Dll

Thanks Rett!

I'll take your word for it, if someone tells me to shut it, that's on you ;)

Aight, so I'd like to show you something kind of neat, I'm not sure 
where this lands in regards to collapse-computing, but maybe someone has 
a use for this crazy idea.

A couple years back, Conway(rip) presented this programming language 
called Fractran, here's an amazing talk that shows it off somewhat:

https://www.youtube.com/watch?v=548BH-YFT1E

The OISC runtime has 1 operation: multiply.

I know some of you are familiar with Kragen's exploration of small 
runtimes(uvc, nock, brainfuck, BLC, etc..) and systems with an eye on 
archival and software preservation, so I figured maybe this excites you. 
Here's a full implementation:

#include <stdio.h>
#define num 0
#define den 1

int
main(void)
{
	long src[] = {55, 77, 13, 11, 546, 195, 11, 39, 13, 65, 1, 13, 0, 0};
	long *f = src, acc = 131625; // x^4 y^3 mul
	while(f[den])
		if(acc % f[den])
			f += 2;
		else
			acc = acc * f[num] / f[den], f = src;
	printf("%ld\n", acc); // r^12
	return 0;
}

The accumulator is a single number, the cells in memory are fractions. 
You try multiplying the accumulator with each fraction until one gives 
you an integer, update the accumulator, and try again testing each 
fraction from the beginning.

It seems a bit like a tarpit, but with the right front-end, it isn't.

It's basically a single-cycle multiset rewriting engine, I wanted to see 
how powerful it was, and spent 4 weeks exploring it all. There's very 
little documentation on this language, and it's often overlooked, but 
it's insanely powerful.

https://wiki.xxiivv.com/site/fractran.html

It's a type of computation that's mostly unexplored, but if I had to 
imagine a different route that it could have all gone down, this might 
have been it. The only OISC computers that I've played with, or even 
things like brainfuck, aren't anywhere as comfy as fractran. So there 
might be there to explore for people interested in small malleable systems!

Have fun, let me know if you find something there that I haven't spotted :)

Dll

-- I'm not writing code this month, just drawing.

On 2024-10-05 20:10, Rett Berg wrote:
> AFAIK as long as you are talking about collapse-related tech you're
> okay. I have a hard time believing anything 100r touches isn't gold
> plated if you feel that we might be especially interested.
> 
> I guess if you have a new soundtrack for an 8bit adventure that's a
> little bit of a stretch, but if you create some cool software for
> creating 8-bit soundtracks that sounds completely on-point to me.
> 
> Best,
> Rett
> 
> On Sat, Oct 5, 2024 at 8:11 PM Hundred Rabbits <rabbits@100r.co> wrote:
>>
>> I was just re-reading James' email about how the collapseOS mailing list
>> wasn't conductive to talking about broader topics, I was wondering if
>> this was a thing I might have missed or is shared thoughts and
>> experiment on the topic still welcome?
>>
>> I got lots of little experiments that might be interesting to share,
>> just wanted to make sure that it was fine to do so and that I haven't
>> missed the memo or anything.
>>
>> I spoke with Tiffany from WIRED about collapse computing today, I know
>> she's contacted a couple of folks on here, I made sure to tell her that
>> Virgil was working day and night to ensure that we could still make
>> spreadsheets after the world caught fire ;)
>>
>> Dll