xjix @xj-ix.luxe


@xjix does not follow you (they may not see your replies!)

Recent Twts

Recent twts from xjix

@prologic @johanbove@johanbove.info (#nntdibq) we just don’t program in ways that work well for human minds. i reckon we have to throw out the majority of all software that was ever written to get to a sane place. assuming we come up with adequate tools that act as more effective force multipliers than the bullshit we use today. i have some thoughts on this, but as it usually goes its something of a research problem. i think APL is an important precursor. gemini://xj-ix.luxe/posts/2019-10-17-programming-for-the-next-billion/


it also remains to be seen how a greenarray-based uxn runtime would work in the first place, but my back-of-envelop calculation is that a uxn instance would use 8-12 F18A machines (18bit 64 word ram per machine) + one 256k FRAM module. additional machines would be used to handle IO to peripherals, but these can be shared between instances so it’ll be a fixed overhead.


i keep debating this in my head. i reckon the comrade’s display device should be modular anyway, the display buffer is just that. doesn’t matter if there’s a TFT or an e(ink|paper) display on the other side. multiplexing uxn displays would be cool, but that would mean adding a display buffer cache for every instance and i don’t know if i want to have that much memory dedicated to swapping displays. i’m on board with using uxn as a common runtime, but FRAM modules have six pins and top out at 256k (afaik). i only have 88 pins to work with so i’ll have to place some hard limits on how many display devices the runtime allows.


now that the doom is apparent, i’ve noticed that’s all people can talk about. its a good thing in some respects, i was never able to light a fire under anyone to mobilize a preemptive strategy. the question now is whether i can channel this energy into something productive in time to be effective. a lot rests on my shoulders, but i’ll take it if that’s what it takes to protecc my family.