It always saddens to me when people only think of the extremes, while perfectly good options exist!
If your develop for highly locked device (iPhone) which requires the very latest version of huge dev environment -- maybe choose some other development target which does not evolve quite as much. Qt, Java, etc.. are not updated for years. And don't forget to make sure that your OS does not break without updates either.
Gimp is more clunky than Photoshop, but it will never fail because of lack of license server.
This part is especially annoying:
> At sea, without internet, if I wanted to look up how to fill a polygon, I couldn't do it, but if I had printed it?
.. or maybe you could have gotten some e-books? They take much less space that paper books (important on yacht!) and lasts forever. Postscript format, from 1985, is still readable by all modern systems. Plain text ASCII, from 1968, is still being written every day. Even HTML 1.0 is rendered by all modern browsers.
I loved seeing this talk in person and really enjoyed reading through it again now. I’m kind of fascinated by the longevity of software for simple systems - games like Another World or Monkey Island or even DOOM are well-loved decades later, whereas games like Black and White that don’t port well are largely forgotten.
I’m surprised to see commenters here who don’t see portability as important for preservation - or maybe just don’t really care about preservation at all.
This whole thing strikes me as silly. Problems accessing services while alone in a boat in the middle of the sea is not anything like the general problem of preserving information and technology. We don't need to make knowledge individually accessible and maintainable because humans generally don't try to do that by themselves. And humans are actually really good at preserving the knowledge they care about. Kids in school read a poem first written down 2500 years ago about an event that occurred 500 years before that. The dead sea scrolls failed to overturn the world of biblical scholarship because it turned out the later copies of the texts were actually quite accurate. The fact that our devices don't just work without a supply chain and a steady source of power, or that there are 20 year old games almost nobody cares about which we can no longer play just doesn't signify that much. Nor does the fact that the BBC couldn't figure out how to preserve some chunk of data for 10 years.
Interesting and naive journey to find a suitable and minimal "permacomputing" environment for doing software development on a sailboat.
The author mentions power use being a factor. Last I did some research into this, smartphones are by far the most power-efficient general-purpose computers broadly available, using several times less power than something like a raspberry pi. I wonder if running an open-source OS on smartphones was considered for their sailboat permacomputing?
> We grew up in Montreal, and many of our friends worked in AAA studios like Ubisoft, making free-to-play games, building projects that had a lifespan of three years. The projects that we made in the past on the Apple stack, Electron, or on Unity3D, also had a lifespan of three to four years, but games like Super Mario, as well as others produced in that era, are still playable today.
The games that don't work in some way or form 20 years after creation are in minority due to effort of community. I dunno what author is smoking.
> chains of emulators eventually break down
<citation needed>, arguably some emulation experience is better than original
> The download is at 7 gigs with three more hours left to download the update, it won't finish, and we will have spent all that data for nothing.
Resume download existed for better part of internet. Also torrents are great for that use case...
> There was a time when computers were super playful, but now they feel cold, and have been weaponized against people.
They still are, just gonna join the crowd of weird penguin people instead of buying another windows/macbook box, all the power and weird stuff you can do with computers is still there, using current software.
Maybe not in "I built everything from scratch way" but still
> The Commodore 64 emulator was extremely complex, more complex than I could grasp. It was the limit of what I think a single person could understand. It seemed like a simple system, it was just a box, but writing an emulator for it was more than a weekend project. I was looking for something that I could nail in a single weekend.
Huh, I kinda hit the same thing. Started writing Z80 emu (in Go, then Rust for funzies), got a good framework and some way in into implementing instruction set then realised "damn, now getting it cycle accurate and synchronized with peripherals is a lot of work. And peripherals are more work than CPU itself".
> Our philosophy is that to make fast software, you need slow computers...
One of the reasons why our industry produces slow, bloated software is because the engineers building it often have the fastest computers with the most resources. It should be a requirement before shipping to have your whole team personally use the software for a week on 10 year old computers.
One of the reasons why my data management system (https://www.Didgets.com) is so fast is because I regularly ran it on an old Core-2 Duo machine with a slow hard drive and limited RAM. I didn't stop tweaking it until it ran fast on the old hardware.