The past few days I've been thinking a lot again about one of the thought/design models most influential on my own #OpenSource practice: Frank Duffy's architectural pace layers (and Stewart Brand's subsequent extension to different contexts), their different timescales and interactions as basis for resilient system design:
1. Each layer exists & operates independently, moves at different timescales (from seconds to millennia and beyond)
2. Each layer influences and only interacts with its direct neighbors
"Fast layers innovate, slow ones stabilize." — S.Brand
I always found that model super helpful for analyzing and deciding how to deal with individual projects and components in terms of focus/effort, and asking myself which layer this thing might/should be part of. Lately though, I keep on trying to figure out how to better utilize that model to orient my own future practice, also with respect to the loose theme of #PermaComputing and how to frame and better organize my own approaches to it, incl. how to reanimate or repurpose some of the related, discontinued, but not invalid research & projects I've been doing along these lines over the past 15 years...
I understand and appreciate most of the focus on #FrugalComputing & #RetroComputing-derived simplicity as starting points and grounding concepts for attempting to build a more sustainable, personal, comprehensible and maintainable tech, but these too can quickly become overly dogmatic and maybe too constraining to ever become "truly" permanent (at least on the horizon of a few decades). I think the biggest hurdles to overcome are social rather than technological (e.g. a need for post-consumerist, post-spectacular behaviors), so I'm even more interested in Illich/Papert/Nelson/Felsenstein-inspired #ConvivialComputing, #SocialComputing, IO/comms/p2p, #Accessibility, UI, protocol and other resiliency design aspects becoming a core part of that research and think the idea of pace layering can be a very powerful tool to take into consideration here too, at the very least for guiding (and questioning) how to approach and structure any perma-computing related research itself...
Given the current physical and political climate shifts, is it better to continue working "upwards" (aka #BottomUpDesign), i.e. primarily focusing on first defining slow moving, low-level layers as new/alternative foundations (an example here would be the flurry of VM projects, incl. my own)? Or, is it more fruitful and does the situation instead call for a more urgent focus on fast-moving pace layer experiments and continuously accumulating learnings as fallout/sediment to allow the formation of increasingly more stable, but also more holistically informed, slower moving structural layers to build upon further?
It's a bit of chicken vs. egg! In my mind, right now the best approach seems to be a two-pronged one, alternating from both sides, each time informing upcoming work/experiments on the opposite end (fast/slow) and each time involving an as diverse as possible set of non-techbro minds from various fields... 🤔
Lo, thar be cookies on this site to keep track of your login. By clicking 'okay', you are CONSENTING to this.
Devine Lu Linvega
in reply to Karsten Schmidt • • •Karsten Schmidt
in reply to Devine Lu Linvega • • •@neauoire I like! Your "toward" describes it much better than my old "up/down"... That "two-pronged" approach I referred to is maybe also closer to what I've been doing with the various thi.ng projects: A kind of encircling/spiraling round-robin type gliding focus, with sometimes days or weeks between re-visiting concepts/projects, sometimes years, but usually informed by what I learned (in other contexts) in between...
FWIW We do have solar (was pre-installed and only to support hot water), we use 100% renewable electricity and we do have fibre internet, but even so we're consciously (if so far also still somewhat selectively) reducing and adjusting our limits to something much lower than those our current local situation/environment encourages. I think it's a healthy exercise to embrace and figure out what one's limits are and then also allow them to work for you (i.e. "limitation is the mother of invention"), even if those limits are not (yet) being strictly enforced as in a life on the high seas 😀
Devine Lu Linvega
in reply to Karsten Schmidt • • •Karsten Schmidt
in reply to Devine Lu Linvega • • •@neauoire 💯% agreed! Diversity & adaptability (also in approaches) is key! Also, if one is approaching this whole field truly with a longer arc of time in mind and aiming for a dynamically re-negotiable/adaptable limits, then a kind of pace layering approach could be super useful (and also needed)...
E.g. Maybe it's still somewhat hard to answer at this stage, but in your own situ, would you consider Uxn already being or becoming a (or the) foundational, slow-moving, and maybe change-tolerant, but also change-resistant pace layer (e.g. "structure" in the above model) or have you always considered Uxn as a layer which is designed to be more easily malleable/adaptable (e.g. "services" or "space plan" above)? Of course one thing is to heavily experiment, build a ton of things & FAAFO, but also think asking these kind of questions can clarify a lot of things beforehand, at least for judging the need for flexibility in the design of a thing...
(Hope that makes some sense 😀
Devine Lu Linvega
in reply to Karsten Schmidt • • •Devine Lu Linvega
in reply to Devine Lu Linvega • • •Karsten Schmidt
in reply to Devine Lu Linvega • • •@neauoire Thanks for the quick answer! Very much what I expected to hear! 😀 The learnings from standing up a small compute infra from scratch are considerable (and as you said highly transferrable), so your views are very similar to how I think about some of my projects too...
Re: Self-obviating systems - I very much like Bill Tomlinson's framing, also very relevant to your answer:
http://postgrowth.art/self-obviating-systems-En.html
FWIW For similar reasons as yours (i.e. building a small compute env and learning from "1st principles"), I spent most 2015/16 going deep into bare metal STM32 coding and ARM assembly, built several Forth VMs/kernels/REPLs and DSLs, incl. some for defining GUIs, transpiling shaders and live coding audio/music/geometry. Learned more about compilers/assemblers, modern CPUs, cache/memory/DMA, interrupts, multitasking, file
... show more@neauoire Thanks for the quick answer! Very much what I expected to hear! 😀 The learnings from standing up a small compute infra from scratch are considerable (and as you said highly transferrable), so your views are very similar to how I think about some of my projects too...
Re: Self-obviating systems - I very much like Bill Tomlinson's framing, also very relevant to your answer:
http://postgrowth.art/self-obviating-systems-En.html
FWIW For similar reasons as yours (i.e. building a small compute env and learning from "1st principles"), I spent most 2015/16 going deep into bare metal STM32 coding and ARM assembly, built several Forth VMs/kernels/REPLs and DSLs, incl. some for defining GUIs, transpiling shaders and live coding audio/music/geometry. Learned more about compilers/assemblers, modern CPUs, cache/memory/DMA, interrupts, multitasking, filesystems, USB internals and other low-level I/O protocols than during any other time in my life. Then abruptly stopped working on this all for 6+ years now, first due to getting a unique job offer in an entirely different field (generative design) and shifting gears - still, been thinking about it (esp. the Forth parts) every single day since and slowly mustering strength & ideas to return with new insights/energy...
Nothing is lost, time is circular...
Self-obviating Systems
POST GROWTH TOOLKITDevine Lu Linvega
in reply to Karsten Schmidt • • •We're crossing paths now at a time when we're ooing in different directions. I used to do motion graphics, and stage visuals for large events(Linkin Park, etc..), it was a totally different life, I've learnt a lot of things on very different aspects of computers, but it's not lesser in any way than what I do now and I also think back about that time every single day.
Time is definitely circular, the world is a playground. Have you ever listened to this?
https://www.typetheoryforall.com/2022/05/09/17-The-Lost-Elegance-of-Computation-(Conal-Elliott).html
#17 The Lost Elegance of Computation
www.typetheoryforall.comJustin Miller
in reply to Karsten Schmidt • • •Justin Miller
in reply to Justin Miller • • •Devine Lu Linvega
in reply to Justin Miller • • •