ae1cf31045f5b991c142b33148bf142bc22ab07a — neauoire 2 years ago c3ad889
1 files changed, 59 insertions(+), 39 deletions(-)

M slides
M slides => slides +59 -39
@@ 371,17 371,6 @@ HEAD Learning to maintain a boat has`advised how we build software.
	- Everything comes at a cost. When sailing, when no one around depending on others for security is dangerous.
	- We like to think that things we learnt working on the boat, we can now carry with us into application development.

NAME [toy] 5.1 Learning to repair computers
GOTO 0c,00
PICT media/uxnexploded.tga
GOTO 04,17
HEAD Design for`disassembly

	- Learning to repair, and maintain a boat has advised the way we build software now.
	- We found endless parallels between software maintenance and sailboat maintenance.
	- TODO..

NAME [rek] 6.0 Resilience boat
GOTO 00,00
PICT media/grindereating.tga

@@ 431,15 420,24 @@ PICT media/grinder.tga
GOTO 04,08
HEAD Nothing should be`miniaturized.

	- For software...
	- A font editor ought to makes fonts, should not be nestled into a raster software along with 3d tools, and heavy libraries.
	- As little dependencies as possible.
	- No minified code.
	- No package managers.
	- Good documentation for all the moving parts.
	- Portable toolchain that can be taken from one device onto another easily.
	- Standard file formats, plain-text whenever possible.
	- Printed copies of the documention helps, esp assembly.
	- If we consider software designed to work offline and to be repaired:
		- Good documentation for all the moving parts.
		- Code cannot be minified or compressed.
		- Cannot rely on online documentation, or use a language that does.
		- It should have as few dependencies as possible, and the dependencies should follow the same rules.
		- The environment should be portable and easily replicable on another machine.
		- Standard file formats, plain-text whenever possible.
	- We found that software that try to do too much, breaks in unexpected ways.
	- We found that simple languages with a spec that fits on a few printed pages the best.
		- For example: We carried the whole of 6502 assembly documentation on a handful of printed pages.

	- Learning to repair, and maintain a boat has advised the way we build software now.
	- We found endless parallels between software maintenance and sailboat maintenance.
	- Ideally hardware would come with a maintenance manual, not only a downloadable pdf
		- you never have the pdf when you need it, sometimes you need the computer to get to the pdf..
	- When this is not possible, we try redundancy, 
		- we carry aboard many raspberry pi devices, which we can swap would one become defective.
		- we carry spare parts, chargers, keyboards, batteries when we're outside of delivery range.

NAME [rek] 7.0 Documentation boat

@@ 489,16 487,20 @@ TEXT Context creates empathy,`Offline wiki used as reference,`Collecting knowled
	- Documentation of projects just as important as projects themselves.

NAME [toy] 8.0 Freedom
GOTO 00,00
GOTO 08,00
PICT media/onward.tga
GOTO 04,04
TEXT When sailing in the ocean, no road to follow
HEAD No roads to follow.

	- Move away from conflict
	- Follow the weather
	- Learn about ourselves
	- Make time for slow activities
	- Limits the noise, propaganda, distraction
	- The boat gives us the freedom to:
		- Move away from conflict.
		- Limits the noise, by living at an arm's length from the internet.
		- Make time for slow activities.
	- We've adapted our software around the limitations of our vessel
		- instead of increasing the limits.
	- We learn to appreciate these limits and think that it makes our work better.
		- We often consider that using slow devices is a practical way to write efficient software.

NAME [toy] 9.0 Uxn
GOTO 00,00

@@ 506,23 508,41 @@ PICT media/garden.tga
GOTO 04,05
TEXT Uxn is a virtual machine that allows us to bring software onto any platform that we wish

	- After Electron disapointment and software lost to bitrot, looking for alternatives.
	- Even writing graphical C applications, portability issues working from plan9.
	- Building C graphical applications is heavy and slow comparing to assembling NES rom.
	- Inspired from Another World & Flash
	- 32 opcodes, virtual machine designed to make portable roms.
	- A single rom, works on all emulators
	- Encourages re-use of old devices
	- 64kb of memory
	- Lean toolchain, we can exchange assets
	- Importance of play***
	- After loosing our older software to the bitrot of one disapointing ecosystem to the next, 
		we decided to try to build our own.
	- We found that writing graphical applications(even in C), has a lot of portability issues.
		- For example: One of our device is a plan 9 workstation.
	- But even beyond portability, building a C graphical applications is much heavier and slower 
		comparing to simply assembling rom.
	- After experimenting with virtual machines like Another World & Flash
		- and building games for the NES.
	- We decided to build our own little vm as a target to build our tools for.
	- It has 32 opcodes, it's implemented in about a 100 lines of C89.
		- The emulator front-end is about a thousand, we have emulator for nearly every portable handheld and system.
	- It has only 64kb of memory, but we found that this is enough for most things
	- Small memory, means small assets, simple storage, easy versioning.

NAME [toy] 9.1 Uxn Practical
GOTO 0c,00
PICT media/uxnexploded.tga
GOTO 04,17
HEAD Designed for`disassembly

	- For example: 
		- When I do shows now, my setup is a little program written in a forth like language, 
		- that assembles to a 12kb rom, 
		- that runs on each of our device.
	- The specs of this computer is often called a one-page computer
		- the mathematical definition of the vm fits on a napkin or on a t-shirt.
	- We spend less time messing with environments, and more time to play.

NAME [rek] Outro
GOTO 0b,00
PICT media/niche.tga
GOTO 04,10
TEXT Less competition in niche interests.`Creating a polyculture of tools.`
GOTO 04,18
HEAD A polyculture`of tools.

	- If have specific interest, chances are someone else shares this interest
	- Tempting to pursue popular interests.