commit 6eba759128ccb0da4fe35c5afedc2693082e1697
parent 498f132ff857d555fc0a3c7f9f44e32c52e02c01
Author: Ville-Matias Heikkila <viznut@low.fi>
Date: Sat, 25 Jun 2022 14:39:24 +0300
Merge branch 'master' of bleu255.com:/var/www/git.bleu255.com/repos/permacomputing
Diffstat:
21 files changed, 133 insertions(+), 40 deletions(-)
diff --git a/C.mdwn b/C.mdwn
@@ -33,3 +33,4 @@ Compilers:
* [Open Watcom](http://www.openwatcom.org/) is a C/C++/Fortran compiler usable for targeting legacy x86 operating systems such as [[DOS]].
* [Tiny C Compiler](https://bellard.org/tcc/) is a small (100+ KB) standalone C compiler for "modern" x86 and ARM targets (i.e. [[Linux]] but not [[DOS]]).
* [vbcc](http://www.compilers.de/vbcc.html) is an optimizing C99 compiler particularly suitable for some legacy targets such as [[68000]] and [[6502]].
+ * [cproc](https://sr.ht/~mcf/cproc) and [other compilers](https://c9x.me/compile/users.html) based on [the QBE compiler backend](https://c9x.me/compile).
diff --git a/Lua.mdwn b/Lua.mdwn
@@ -0,0 +1,9 @@
+[**Lua**](https://www.lua.org) is a general-purpose high-level language created since the 1990s at [PUC Rio de Janeiro](https://en.wikipedia.org/wiki/Pontifical_Catholic_University_of_Rio_de_Janeiro).
+
+Lua provides a sweet spot along three axes:
+
+* high-level dynamic syntax with anonymous functions and closures
+* reasonably high performance by compiling to a virtual machine's bytecode
+* small and approachable implementation with no dependencies beyond C
+
+Lua also provides a framework for graphical applications called [LÖVE](https://love2d.org). LÖVE depends on the host OS for graphics. On Unix-descended systems, that is approximately the [SDL2](https://www.libsdl.org) library.
diff --git a/Mu.mdwn b/Mu.mdwn
@@ -0,0 +1,16 @@
+[**Mu**](https://github.com/akkartik/mu) is a minimalist stack of languages built up from machine code. It requires a processor from the x86 family, and builds up to a memory-safe language without any additional dependencies (though it can also be bootstrapped from a C implementation).
+
+Like [[Forth]], Mu was intended to enable people to build interesting programs while being able to hold the entire system in their head. Unlike [[Forth]], Mu does so while being well-typed and providing good guardrails that make programs easier to debug. 2/3rds of the LoC are devoted to automated tests.
+
+Performance is not a priority; Mu achieves its goals by focusing on very basic hardware support. It only supports one screen resolution (1024x768 with 256 colors) and has only one font (albeit with extensive Unicode support). There's just one device driver for hard disk storage: ATA disks in the inefficient PIO mode.
+
+Mu is different from more retro computers like [[Uxn]] in assuming lots of RAM and disk. It uses a 32-bit address space and avoids space-saving tricks in favor of straightforward code.
+
+Mu is currently dormant. You can create graphical programs that run without an external OS (albeit only emulated on Qemu so far). You can also create text-mode programs for Unix-descended systems. It's currently stalled in need of expertise debugging real hardware and implementing networking. The mouse driver also needs work.
+
+Since Mu depends on no features of x86 newer than SSE, it runs on any x86 processor built in the 21st century. Programs built on Mu are also expected to be resistant to bitrot since they require fairly basic emulation capabilities. It currently serves as a time capsule to test these hypotheses.
+
+See also:
+
+* [An academic paper about Mu](http://akkartik.name/akkartik-convivial-20200607.pdf)
+* [A summary of the Mu compiler on a single page.](http://akkartik.github.io/mu/html/mu_instructions.html) It's built in machine code so [needs to be really simple](https://github.com/akkartik/mu/blob/main/linux/stats.txt).
diff --git a/Niklaus_Wirth.mdwn b/Niklaus_Wirth.mdwn
@@ -1,26 +1,11 @@
-**Niklaus Wirth** (born 1934 in Switzerland) is one of the most prominent
-computer scientists, mostly known for developing Pascal and several other
-programming languages.
+**Niklaus Wirth** (born 1934 in Switzerland) is one of the most prominent computer scientists, mostly known for creating Pascal and several other programming languages.
-A lot of Wirth's work is related to concretely proving that [[bloat]] is not
-a necessity and that smaller and more elegant computing is possible:
+A lot of Wirth's work is related to concretely proving that [[bloat]] is not a necessity and that smaller and more elegant computing is possible:
-The **Lilith** workstation, the design of which started in the late 1970s,
-was Wirth's idea of a personal computer. It was inspired by the
-[[Xerox Alto]] but particularly aimed at students with the aim of being
-powerful and simple at the same time. Lilith is thoroughly built around the
-Modula-2 programming language, even the microcode is compiled from a variant
-of Modula-2. The [[stack-based]] instruction set architecture reached
-competitive speeds particularly thanks to the high code density, and it also
-helped keep the Modula-2 compiler fast and simple.
+The **Lilith** workstation, the design of which started in the late 1970s, was Wirth's idea of a personal computer. It was inspired by the [[Xerox Alto]] but was particularly aimed at students. It was designed to be powerful enough while being simple enough to be understood by a single person (such as a computing student). Lilith is thoroughly built around the
+Modula-2 programming language, even the microcode is compiled from a variant of Modula-2. The [[stack-based]] instruction set architecture reached competitive speeds particularly thanks to the high code density, and it also helped keep the Modula-2 compiler fast and simple. Unfortunately, Lilith was a commercial failure, and less than 200 were built.
**[[Oberon]]** is an operating system centered around the
-[[object-oriented]] Oberon programming language, with the guiding principles
-of clarity and simplicity. A major reason to its existence was proving that
-a full graphical and modern operating system with a software development
-environment is possible in a moderate size (a couple of hundred kilobytes).
-It has also been used as Wirth as an example of **lean software**. Oberon is
-still being developed and maintained, largely by Wirth himself.
+[[object-oriented]] Oberon programming language, with the guiding principles of clarity and simplicity. A major reason to its existence was proving that a full graphical and modern operating system with a software development environment is possible in a moderate size (a couple of hundred kilobytes). It was also used by Wirth as an example of **lean software**. Oberon is still being developed and maintained, and Wirth himself is still involved with the project.
-**Wirth's law** is Wirth's variant of the [[Jevons paradox]]: Software
-is getting slower more rapidly than hardware is getting faster.
+**Wirth's law** is Wirth's variant of the [[Jevons paradox]]: Software is getting slower more rapidly than hardware is getting faster.
diff --git a/Small_File_Media_Festival.mdwn b/Small_File_Media_Festival.mdwn
@@ -1,5 +1,5 @@
-The Small File Media Festival works in defense of the tiny image.
+The **Small File Media Festival** is a film festival in Canada, focused on short films with file sizes less than five megabytes.
-Size matters, and small is better, tiny is best, which is not merely to argue for a different aesthetics or narrative structures (that too) but also for an understanding that all media is media ecology – and as such, directly related to infrastructures with environmental costs.
+According to their website, SFMF works in defense of the tiny image. Size matters, and small is better, tiny is best, which is not merely to argue for a different aesthetics or narrative structures (that too) but also for an understanding that all media is media ecology – and as such, directly related to infrastructures with environmental costs.
-* [Official website](https://smallfile.ca), sadly, they have a poorly optimized website that fails almost entirely to display on slow-bandwidth and old browsers.
+* [Official website](https://smallfile.ca), sadly, they have a poorly optimized website that fails almost entirely to display on slow-bandwidth and old browsers. The fact that the main page is more than half the size of a five-megabyte film somewhat ruins the point of their activism.
diff --git a/Teliva.mdwn b/Teliva.mdwn
@@ -0,0 +1,5 @@
+[**Teliva**](https://github.com/akkartik/teliva) is a text-mode platform for disseminating sandboxed applications. In this respect it resembles a web browser (without markup or a DOM for documents). The sandboxing model is more flexible than web browsers. It tries to nudge computer owners to think about what permissions they should grant untrusted applications, and to learn a little bit of programming to do so. It also encourages owners to look inside application code and provides a trivial edit-run debug cycle to help them make changes to untrusted applications.
+
+See also:
+
+* [A talk on Teliva](https://archive.org/details/akkartik-2022-01-16-fosdem)
diff --git a/Uxn.mdwn b/Uxn.mdwn
@@ -17,7 +17,7 @@ This stack-machine has 32 opcodes, no registers, Program Counter(PC), Memory(M),
07 a b c b 0f a b {rs.c} 17 a {D[c8]=b} 1f a b>>c8l<<c8h
2x a16 b16+c16 4x a b c {rs.b+rs.c} 8x a b c b+c
-The [[C]] implementation of the virtual machine is about 100 lines. A self-hosted assembler for the Uxntal assembly language is about 400 lines of Uxntal, and assembles to a 1200 bytes rom.
+The [[C]] implementation of the virtual machine is about 100 lines and depends on the [SDL2](https://www.libsdl.org) library. A self-hosted assembler for the Uxntal assembly language is about 400 lines of Uxntal, and assembles to a 1200 bytes rom.
Relationship to permacomputing:
diff --git a/bedrock_platform.mdwn b/bedrock_platform.mdwn
@@ -1,5 +1,15 @@
A **bedrock platform** is a [[hardware]] platform or a universal [[virtual machine]] that can be expected to remain compatible with any [[software]] that has ever been written for it. Bedrock platforms can be used to prevent [[software rot]].
+Note that this is **not** a "shopping list" or a list of "allowed" hardware. Bedrock platform support is simply a way of maximizing the probability that a program can be run in an indefinite future and a way to keep its [[dependencies|dependency]] reliable. The concept of bedrock platform is **not** relevant to e.g. embedded-system-type projects that are designed for a very specific hardware, or the kind of software that is known to have a short lifespan.
+
+A simple bedrock platform guide based on the IBM PC line:
+
+* Can you compile and run the program in FreeDOS?
+ * If yes, you have the bedrock support (just make sure that the compiler and other needed tools are archived somewhere).
+ * If not, can you create an x86 operating system image that compiles and runs the program without accessing any external resources?
+ * If yes, you have the bedrock support (just archive the image and/or everything you've put in it).
+* If you can only run it in these environments but not compile it, it is still far better than nothing.
+
Some possible criteria for bedrock hardware:
* The hardware has been popular and commonly available at some point of history (and preferably remains that way).
diff --git a/calculation_factory.mdwn b/calculation_factory.mdwn
@@ -0,0 +1,5 @@
+A **calculation factory** is a computer that works like a factory: it has a relatively static material and energy requirements with very little concern or flexibility in regards to the environment they are part of.
+
+Mainframe computers in particular have thought as factories since the 1950s, including the idea of minimizing their idle time by having their operators work in multiple shifts. This kind of thinking carried over to the Internet server world.
+
+Even small computer systems tend to inherit some characteristics from calculation factories. They often have very poor means to adjust their operation to the changes in physical conditions. This kind of environment-reactivity is an area permacomputing is interested to develop.
diff --git a/hardware.mdwn b/hardware.mdwn
@@ -7,17 +7,20 @@ When assessing hardware, we should pay attention to possible problems preventing
The world is full of abandoned computer hardware, therefore we shouldn't be too picky, and find creative ways to work with even the lousiest pieces of hardware. We shall approach their problems as something to be fixed with hacking, reverse-engineering and activism.
-Efforts to create new hardware components in biosphere-compatible and/or local ways may be worth supporting, although that goal is still very far away.
+Efforts to create new hardware components in biosphere-compatible and/or local ways are worth supporting (although that goal is still far away for microchips). We are particularly interested in what it requires to build specific types of component with minimal industrial dependencies without destroying the biosphere. Links to succesful DIY projects are welcome.
Types of hardware components:
-* [[Processors]] (including [[SoC]]s)
-* [[Displays]]
-* [[Batteries]]
-* [[Input devices]]
-* [[Storage devices]]
-* [[Radio devices]]
+* [[IC]]s
+ * [[processors]] (including [[SoC]]s)
+ * [[memory]]
+ * [[FPGA]]
+* [[displays]]
+* [[batteries]] (including [[supercapacitor]]s)
+* [[input devices]]
+* [[storage devices]]
+* [[radio devices]]
See also:
-* [[Bedrock platform]]
+* [[bedrock platform]]
diff --git a/history.mdwn b/history.mdwn
@@ -6,7 +6,7 @@ imagined.
Since permacomputing envisions a long-term future of the
computing that, it needs to tell the **history of computing**
-in ways that make it relevant.
+in ways that make permacomputing and similar alternative ways of thinking more relevant.
Problems of mainstream computing history
----------------------------------------
diff --git a/index.mdwn b/index.mdwn
@@ -42,6 +42,7 @@ Around, nearby and beyond
-------------------------
* [[Communities]] that (may) have compatible goals and interests;
+* More fine-grained [[properties]] of software built using permacomputing principles, and how they're shared by neighboring communities;
* [[Damaged Earth Catalog|DEC]] covers concepts and movements related to permacomputing.
diff --git a/index/discussion.mdwn b/index/discussion.mdwn
@@ -1,3 +1,7 @@
The flower graphics should probably be hosted locally, I've only put it there so it could be transferred over. - [[@neau|neau]]
+
+* Thanks, I've made it local. By the way, the PNG is in truecolor colorspace, making it paletted made it much smaller. [[viznut]]
+
+Ah yes! Good call, it was originally cyan, I totally forgot about the color profile. - [[@neau|neau]]
diff --git a/lines.love.mdwn b/lines.love.mdwn
@@ -0,0 +1,7 @@
+[**lines.love**](http://akkartik.name/lines.html) is an editor for plain text where you can also draw simple line drawings.
+
+It's not something you can program, but it's permacomputing-adjacent in the following ways:
+
+* It does something useful to non-programmers. It's not just a research project, it's intended to be supported over the long term.
+* It illustrates a graphics stack (C+Lua+LÖVE) that runs on just about any computer or OS, is easy to compile, reasonably performant, and has fairly parsimonious dependencies.
+* It is designed to be easy to modify. It always ships with source code, it's easy to modify using the exact same tools used to run it, and the source code includes lots of automated tests to protect newcomers.
diff --git a/media_minimization.mdwn b/media_minimization.mdwn
@@ -28,5 +28,6 @@ minimization. Ideally, the result of media minimization should resemble
careful artisan work and look better than the original.
See also:
+
* [[Demoscene]]
* [[Small File Media Festival]]
diff --git a/permacomputing_in_the_arts.mdwn b/permacomputing_in_the_arts.mdwn
@@ -4,14 +4,16 @@ Permacomputing in the Arts
About
-----
-The permacomputing in the arts workshop series is part of a postdoc research from [[ugrnm]] exploring to what degree the concept of permacomputing can be broadened and applied to critically revised, sustainable ways of making computing part of art and design education and professional practice. This research will be embedded in the design curriculum of Willem de Kooning Academy, Rotterdam, NL, focused on redefining the role of artists and designers to contribute to future modes of sustainable organisation and production.
+The permacomputing in the arts workshop series is part of a postdoc research from [[ugrnm]] exploring to what degree the concept of permacomputing can be broadened and applied to critically revised, sustainable ways of making computing part of art and design education and professional practice. This research will be embedded in the design curriculum of Willem de Kooning Academy, Rotterdam, NL, focused on redefining the role of artists and designers to contribute to future modes of more sustainable organisation and production.
+
+It is part of a larger research and effort to develop new curricula to support artists and designers materialise and contribute to alternative modes of organisation and production based on strong ecological and cooperative/collaborative values. It seeks to reflect on, experiment and engage with such alternatives while bringing the urgency of the climate crisis and climate justice to art and design education, while remaining critical of technosolutionism and the language of circularity and sustainability.
Problem
-------
For the past decades, art academies have expanded their curricula from traditional fine art practices, such as painting and sculpture, to work with computer technology. It can take the form of an installation, a performance, a graphic design, a data visualisation, and will often use computer technology for the making, publishing, and circulation of the work. However, artists and designers are not educated to assess to which degree their practice could be environmentally problematic and extractive. This is an issue by itself and gets worse once entering both speculative and applied practices that have the ambition to engage with environmental issues.
-For instance, a graphic designer can be commissioned to program an interactive website to explain the energy impact of digital media. If the website is programmed in a way that requires resource-intensive computing in data centres and drains the batteries of the visitor's phone or laptop, then instead of being an exemplary and innovative contribution, it risks to remain symbolic, or in a performative contradiction to its stated goal. At worst, it may even be an alibi for environmentally harmful practices and technologies. This is a problem because it seriously weakens and undermines the interdependent relation between the cultural sector, art and design education, and policymaking. It is also a missed opportunity to showcase forward-looking practices that could be both creative and more sustainable.
+For instance, a graphic designer can be commissioned to program an interactive website to explain the energy impact of digital media. If the website is programmed in a way that requires resource-intensive computing in data centres and drains the batteries of the visitor's phone or laptop, then instead of being an exemplary and generative contribution, it risks to remain symbolic, or in a performative contradiction to its stated goal. At worst, it may even be an alibi for environmentally harmful practices and technologies. This is a problem because it seriously weakens and undermines the interdependent relation between the cultural sector, art and design education, and policymaking. It is also a missed opportunity to showcase forward-looking practices that could be both creative and more sustainable.
Permacomputing could promote a transition from a system where creative practitioners use the latest digital tools and media, regardless of environmental consequences, to a more strategic system in which digital tools and media of all generations, are carefully combined, crafted and used to form a less extractive practice.
diff --git a/projects.mdwn b/projects.mdwn
@@ -23,6 +23,9 @@ The people behind the following projects have *not* used the term permacomputing
* [[Collapse OS]]
* [[Chifir]]
* [[Civboot]]
+* [[lines.love]]
+* [[Mu]]
+* [[Teliva]]
Projects whose relevance has not yet been fully assessed:
diff --git a/properties.mdwn b/properties.mdwn
@@ -0,0 +1,18 @@
+More fine-grained properties of permacomputing systems
+======================================================
+
+[[Permacomputing]] is a broad idea that encompasses many concerns. This page is an ongoing attempt to enumerate concerns shared by Permacomputing and/or related [[communities]]. They're all beneficial. Different communities may strive to get to them in different orders.
+
+Human use of computing will be more sustainable if:
+
+* **accessible**: is well documented and adaptable to an individual's needs.
+* **compatible**: works on a variety of architectures.
+* **efficiency**: uses as little resources(power, memory, etc) as needed.
+* **flexible**: is modular, portable, adapts to various use-cases.
+* **resilient**: is repairable, descend-friendly, offline-first and low-maintenance.
+
+Some additional concerns are of indirect interest because they impose costs on the entire end-to-end process of software creation. Software will be more minimalist if:
+
+* it's always bootstrapped from machine code without circular reasoning (bootstrappable builds)
+* it's obvious what source code went into it (reproducible builds)
+* it's easy to audit its source code, including all dependencies
diff --git a/solarpunk.mdwn b/solarpunk.mdwn
@@ -1,3 +1,12 @@
-Solarpunk is movement centered on using and being affected by the use of renewable resources with a focus on [[decentralization]], [[community activism]], social justice and civic empowerment. A recognition that economic, social, and ecological injustices are all deeply inter-connected.
+**Solarpunk** is a movement centered on using and being affected by the use of renewable resources with a focus on [[decentralization]], [[community activism]], social justice and civic empowerment. A recognition that economic, social, and ecological injustices are all deeply inter-connected.
Embracing approachable, personal technology and envisioning a world in which the detritus of consumer culture is appropriated and repurposed toward the reconstruction of a devastated ecology.
+
+Solarpunk imagery, with a lot of plantlife in a carless urban environment, is getting more and more recognizable. Since permacomputing is concerned about many difficult topics such as resource use minimization, scarcity and even collapse, it may be a good idea to compensate this by allying with Solarpunk and its bright and hopeful outwards esthetics.
+
+When embracing Solarpunk, however, there are some pitfalls. First, it is important to separate it from [[greenwashed|greenwashing]] technofuturism (which looks more sterile and corporate but is nevertheless often called Solarpunk). Second, one should perhaps not look too closely into the technological details of Solarpunk works (that may have standard sci-fi tropes such as screens projected in the thin air) but rather take it as a general mood and mindset.
+
+See also
+--------
+
+* [A Solarpunk Manifesto](https://www.re-des.org/a-solarpunk-manifesto/)
diff --git a/stack-based.mdwn b/stack-based.mdwn
@@ -1,6 +1,20 @@
-Stack machines are arguably the simplest kind of computer architecture. Their LIFO structure is quite suitable for block-oriented languages. The code size for a stack machine can be very compact because most instructions have no operand field.
+**Stack machines** are arguably the simplest kind of computer architecture. Their LIFO structure is quite suitable for block-oriented languages. The code size for a stack machine can be very compact because most instructions have no operand field.
-## Primitives
+[[Forth]] (from around 1970) is perhaps the most succesful stack-based programming language, based on a machine model consisting of a data stack and a return stack. Stack-oriented languages are a large subset of concatenative programming language (with the Om language being a rare example of a non-stack-oriented concatenative programming language).
+
+Many [[virtual machine]]s used as compilation targets of higher-level programming languages ([[Java]], [[Lua]], etc.) are stack-based.
+
+History
+-------
+
+Reverse Polish notation was separately invented since the 1950s by several matematicians and computer scientists. GEORGE (1957) was the first practical programming language based on RPN.
+
+Stack-based instruction sets were used by many mainframe computers of the early 1960s (notably, the Burroughs B5000 and the English Electric KDF9), but the idea was later marginalized by register-based architectures such as the IBM S/360. Still, some later stack-based computers (such as [[Niklaus Wirth]]'s Lilith) proved to be quite competitive in terms of speed, particularly thanks to the high code density that reduced their need for memory bandwidth.
+
+Example
+-------
+
+Primitives:
* POP Remove an item at index, closing the hole left in the stack.
* ROLL Remove an item at index, push it on top of the stack.
diff --git a/time-sharing.mdwn b/time-sharing.mdwn
@@ -43,7 +43,7 @@ Sharing of computers
This refers to the use of a single personal computer by several
people. This may be a computer shared within a family or a
-community, or a public computers/terminals located in a place
+community, or a public computer/terminal located in a place
like an Internet Cafe, a computer classroom or a public
library.
