various ideas and notes floating around

os rust development

Writing an OS in Rust Work up to this after some core system has been developed! We can mock an OS and dodge requiring the development of kernel code, drivers, etc. by running JOSS off of a shell on Linux, but this doesn't feel real in the way an operating system might. (Though it might be a good idea to avoid attempting to run on bare metal, if for no other reason than to preserve sanity…). Whatever the case, this is an excuse to work on real OS development in the future - we'll see how my system evolves down the line.

permacomputing

various resources about computing long term permacomputing

• LIMITS 2021 – Workshop on Computing within Limits Very cool organization and workshop system about computing with limits - using very small amounts of resource consumption, particularly with respect to software, in order to minimize our impact on the environment - and to preserve our sense of mental sanity. Most work, software or otherwise, is built upon pervasive, systemic that is opaquely and innefectively abstracted away from the user by end user systems - every little slip of a memory leak, an unabstracted design decision in a codebase, every crack in an iphone, etc. is a consequence of this complexity - but rolling back and redesigning systems to respect core computing can empower and enhance end users of the software we do.

• XXIIVV — permacomputing Advocates for maintenance - encouraging programmers to refactor and rewrite programs to ensure that they're small and efficient. Reuse and repair of existing technology should be encouraged - preserve time and physical resources! Produces should be "designed for disassembly" - ensuring that they can be disassembled for repair and end of life so that even when the component is no longer useful, it can be reworked into other, relevant components. Lots of great resources throughout this article - become familiar with them.

• "Collapse informatics" - taking advantage of today's computing to prepare for future infrastructure breaking down. Systems should anticipate intermittent energy supply, network connectivity and small, non-global community; making core assumptions about global, internet-fueled network and communication is postulated by this article to be completely unrealistic.

• Permacomputing | viznut Computers are failing their expectations at every turn - taking advantage of people rather than empowering them, and proliferating material usage rather than allowing others to scale down their dependence on energy and the environment. Machines are supposed to be "optimizing" things for us - they should be using energy wisely! - but they do quite the opposite, abusing resources and performance as "calculation factories" to occupy lots of space and resources. It's a miracle that chip innovation seems to be beating software bloat on most counts - somehow our systems do run faster despire all of the shit we keep piling onto them. We should optimize our systems for resource efficiency and local community networks! Programmers also often don't value any total understanding or control of the target system - utilizing whatever pile of high-level abstractions that their computer's dependent on rather than understanding how to integrate with systems and metal. It's important to, at times, work on the "computer's level" rather than the level of abstraction established for you to use! It's typically important to make as many programs as dumb as possible - if programs are tools, they should be understandable, predictable, and not get out of your way or handle any "magic". (This is the article's position; to me, programming systems that inspire a sense of wonder - i.e. the type that make end users wonder how certain systems are even possible - are probably the best and most interesting thing about computing). The article postulates that smart programs often complicate core missions and waste lots of computational resources to accomplish what it seems to frame as minimal gain - or, at least, something to be skeptical of.

  Postulates that communities that use technology should develop relationships with it - technology should be flexible, not live at the "app" abstraction layer! I believe in this too - it's vital for those who use technology to understand it. Users should put as much effort into understanding their technology as they do while using it; the 'app' and choices of modern operating systems have largely killed this mindset, but it's so important to bring hacking - true hacking - and true introspection back into the computer systems we use. We need to drop the proprietary OS - not through Android or some corporate watered-down sponsorship, but seriously 'reworking the system'! Software should be introspectable and societies should support its development.

an aside: what makes a relationship work?

Eight Dates: To keep your relationship happy, thriving and lasting: Gottman, …

Analysis of different programming systems - how do we categorize them?

Programming Languages Staged Programming

I've been reading too much

Spend more time working on the system than you do reading for/about it! I have more than enough "abstract" knowledge already, and what I don't have I have to collect via practical experience. In fact - whatever system I design should encourage design by experimentation, by trial and error, by composability - and a REPL based system is perfect for this; integrated into menus, as a data analysis tool, as an end-user interface, etc. I want inline repls everywhere to play with ideas, to get feedback, to query for more data - it's impossible for a UI to show everything, so it's the role of the system itself to allow the user to ask for what they want to see rather than trying to give them all of the information right away! The end user just needs the tools to do so. End user software should be configurable, interactive, and personalized - we should be able to ask questions of it and receive valuable answers, to analyze its insides and delve as deep as we desire, to transparently explore the depths of a system. Open source is so valuable for this, but it's not flexible and only touches small segments of computing - we might be able to do better.