Computers could be good, but they aren't.
That's the gist of it.
I guess I mean Good with a capital G, as in "a force for good in the world", but I also mean good with a lowercase g, as in "not super shitty to use, or think about".
I'm not going to waste a lot of bits talking about how computers are bad. I've done this a lot before, and you probably already agree with me. I'll quickly summarize the high points.
What's wrong with (modern) computing?
- Computers spy on us all the time
- Computers are insecure, while pretending not to to be.
- Computers enable new modes of rent seeking, further exasperated by shitty patents and worse laws
- Computers/the modern internet encourage behaviors which are bad for our mental health as individuals.
- Computers and the modern internet, in concert with modern capitalism have built a world essentially without public spaces.
You know, all that bullshit.
I've spent a lot of time thinking about what the next 30 years in computing might look like, the successes and failures of the last 30 years, and the inflection point at which a computer is Good Enough for most tasks.
I've spent a lot of time thinking about the concept of planned obsolescence as it applies to computing, and what modern computing might look like without the profit motive fucking everything up.
I'm just a dude.
I'm a sysadmin. I spend a lot of time using computers, and specifically I spend a lot of time fixing machines that are failing in some way.
But I'm just some dude who thinks about stuff and imagines futures which are less horrible than present.
I've said that as a way to say: I don't claim to have The Answer, I just have some ideas. I'm going to talk about those ideas.
So how did we get from the gleaming promise of the digital age as imagined in the 70s to the harsh cyberpunk reality of the 20s?
Centralization, rent seeking, planned obsolescence, surveillance, advertising, and copyright.
How do we move forward?
Re-decentralization, a rejection of the profit motive, building for the future/to be repaired, building for privacy, rejecting advertising, and embracing Free software.
Personally, there's another facet to all of this:
I use and maintain computers professionally, and recreationaly.
Sometimes, I want to do something that doesn't feel or look like my day job. Unfortunately, most of my hobbies feel and look a lot like my day job.
To that end, I have some weird old computers that I keep around because they're useful and also because they're Vastly Different than the computers I use at work.
My #zinestation, mac plus, and palm pilots fall in this camp.
I can do about 80% of what I want to use a computer for with my 486 based, non-backlit, black and white HP Omnibook.
Add my newly refurbished and upgraded Palm Lifedrive, and I'm closer to 95%.
Let's run through those tasks:
- Listen to music (The palm is a 4GB CF card with a 2GB SD card, basically.)
- Watch movies (I have to encode them specially for the palm, but the lifedrive makes a great video iPod.)
- Read books (plucker is still pretty great)
- RSS (ditto above)
- Consult reference material (via the internet or gopher over my esp32 modem with the appropriate DOS software and SSL proxy, or more likely, via a real hacky thing I wrote to mirror a bunch of websites to a local web server.)
- Develop (frankly Via GW-BASIC, although I'd love to start doing real programming again.)
- Games (this is the thing the omnibook is worst at! I consider that a strength most of the time, but I do have a lot of parser based IF games on it.)
There was a time in the recent past when I used a Pentium MMX laptop as my only computer outside of work for weeks at a time.
It could do basically everything I wanted it to do, including some far more impressive games.
It's batteries gave out, finally, but until then it made a decent little computer.
The only real problem I run in to in these setups are the hoops I have to jump through because I'm the only one using them, and because (wireless) networking technology has advanced in ways that are not backwards compatible on the hardware level, while leaving laptops without a clear upgrade path.
No one gets upset that their typewriter can't browse the internet, you know?
But a computer isn't an appliance, it's an everything machine, and as an Everything machine, if it can't do the New Shiny Thing we have to throw it away and get a new one.
That's the mentality I'm trying to break out of.
I want to define a(n extendable!) list of tasks that I feel like will be relevant indefinitely, and build a machine to last 30 years.
Which, finally, brings us back to the ESP32!
Basically, the ESP32 is a simple microcontroller (that is to say, it's a computer! It's just not a computer the way we usually think about it.)
It's really cheap, like $3 or $4 for a simple board. There are folks making software for it already to treat it like a desktop computer.
It's not completely open or completely standardized or capable of everything I want out of my #PersonalComputer but ...
They get most of the way there on every count, and they have built in wifi and are so very cheap.
It would be entirely possible to base a new paradigm of multi-decade computers on the ESP32, but built in such a way as to be agnostic to the actual hardware (that is to say, you follow the write once run anywhere model of Java, and use the ESP32 as the host of a virtualized environment OR you build for the ESP32, and then emulate the ESP32 on newer hardware in the future)
This is basically the approach that Infocom took in the 80s when they developed text adventure games for every computer on the planet.
They invented a fake computer, compiled all their games for that fake computer, and then wrote emulators for that fake computer for every major machine of the era.
As a result, basically any computer can run an infocom game.
Now, is the ESP32 a good home for a multi-decade computer?
It's a little more limited than I would have picked (I'd have probably stopped in the early multimedia era), but it's also way less power hungry than what I would have picked, and frankly significantly cheaper and easier to understand.
So I'm going to spend the next few months exploring the ESP32 as the basis for a purpose built computer that inherits the legacy of the tinkerers of the microcomputer era.
Principles I plan to adhere to in my ESP32 exploration:
- Offline first, but networked
- Understandable is better than "easy to use"
- don't make assumptions about available hardware
- Don't re-invent the wheel without a good reason
- don't try to build a modern computer
- Decide what this machine should do, make sure it's good at those things.
Chip-8 - https://en.wikipedia.org/wiki/CHIP-8 - Chip 8 is a virtual machine from the 70s for making games and software portable. It's part of the reason your graphing calculator plays games.
The 100 year computer project (https://thedorkweb.substack.com/p/the-100-year-computer) that sent me careening back down this path has a lot in common with chip-8 (and the article mentions it by name.)
We've talked a little about hardware. We've talked a little about use cases, but we should probably dig deeper in to that.
The remaining piece of this puzzle is software, which I think is closely tied to, but ultimately separate from, use cases.
I'll talk about that now, a bit, until I fall asleep.
So first things first, it's late and this might be incoherent.
In order for a decade spanning computer to be remotely useful, it needs software that speaks common protocols and file formats.
These protocols and file formats should be open standards, well defined, and well documented.
In my current use cases, I mostly use plaintext files, csv, and HTML. When I need to use a more specialized software, I convert between an old file type and a new file type using a piece of open source software on a more modern system.
This takes the form of, for example, antiword or pandoc, running on Linux.
Ultimately, there are still these least common multiple kind of standards out in the world, and they're likely to stick around forever (can you imagine a world without plaintext files?), And converters to get back to these platform agnostic file types are likely to stick around too.
But filesystems, transfer protocols, etc? These things change, and often with good reason. Our system will need to keep up.
My solution to this problem so far has been intermediary computers.
One example: Fetch the emails or the RSS feeds on my laptop, convert them, shuttle them over serial to the old machine.
Another: use the older machine as a serial terminal to a more modern box. Do my actual work on the more modern box.
This extends the life of the older machines, and lets me access modern conveniences when I want them, but it doesn't actually provide a model for a computer that will remain relevant.
I dunno what the answer is here, but I suspect it's something like
1 - define a native format for networked data that you're willing to support.
2 - provide several common network interfaces including serial/uart and wifi.
3 - be willing to whack another machine on to the serial port and let it translate a new hardware or software protocol when the existing ones are no longer supported. (Such as what I do now with the omnibook and my ESP32 wifi modem.)
And 4 - be willing to adapt.
The point of this project, as I see it, is to provide a standard set of tools and protocols and file formats that should be relevant and workable for decades.
If 2.4 and 5ghz wifi stop being supported by new radios in ten years, or WPA2 is replaced with WPA3 or whatever, we write new firmware, install a new radio, or migrate all our data (stored in open formats), and software (open source and largely platform agnostic), somewhere else.
@ajroach42 Espressif also made ESP32-C based on RISC-V (ESP based on Xtensa LX6 is now named ESP-S by Espressif). So this is a more long term evolution. They currently give away RISC-V based boards, if you mail to them and have good projects (else it’s abour 2~3€ the board :)
@ajroach42 ESP32 (at least Xtensa LX6) is also really interesting in synthesizer world. Some make good analog synthesizer with it’s DAC. it is managed by default by FAUST language https://faustdoc.grame.fr/tutorials/esp32/ https://ccrma.stanford.edu/~rmichon/faustMicro/ https://hal.archives-ouvertes.fr/hal-02988312/document https://faustcloud.grame.fr/doc/tutorials/index.html
@ajroach42 The RISC-V version is pin2pin compatible with Xtensa LX6 version, so any hardware project will be compatible (as GigaDevice GD32 (STM32 compatible), ARM version, and GD32V (RISC-V version) made).
@ajroach42 You can found boards like Bluepill with STM32 at ~100MHz for 1~2$, and that’s about the power of a 68060 computer, so very powerfull :). Convergence toward RISC-V in microcontrollers (and probably servers) is like convergence toward Linux for OS on servers and supercomputers
I am giving the emerging RISC-V options a serious look.
@ajroach42 This is one of the major obstacles to a multi-decadal computer I see. Both on the connectors (hardware) and the protocols. I wrote up some thoughts on
At least character sets are (mostly) backwards compatible (but I may have worked on EBCDIC systems).
@ajroach42 I've been reading through your goal of a multi-decade computer and it echos a lot of thoughts I've had. I'm building a house this spring and want to put in a whole home system that will hopefully be as future-proof as reasonably possible. It is a hard goal. My gut tells me that you're a little on the primitive end with your use cases, but not by much. I think things got good enough around 2010 on the hardware/software end. Any reason you would shy away from Raspberry Pi?
@daniel the end of the windows XP era is a good target in terms of features depending on your software and your use case.
I have some computers that age that get regular use.
I use and enjoy various raspberry pis in some special purpose builds. Outside of thag I find them to be, basically, just normal computers but slightly underpowered for some tasks. In my experience this leads to folks trying to use them like normal computers and then getting frustrated.
@daniel if the pi meets your needs, and you're confident you'll be able to keep it running in the future, I don't see any reason not to use it.
@ajroach42 The reason I strongly consider them is mostly the community and their prevalence. I think I'll be able to find one in 50 years.
@ajroach42 I think one significant goalpost was reached when peripherals got better than human senses could discern. Another was the maturity of software RAID systems. Yet another, was the plateauing of audio/video codecs. One of the biggest hurdles for me is the reliance of smart phones to capture recordings. They are too convenient and have amazing quality. Getting the iPhone to talk to Linux is always a PITA. If Linux smartphones take off, I have a hard time figuring out what else I need.
@daniel I'm not terribly worried about smartphone lockdown becuase I've stayed out of Apple's ecosystem in order to avoid it.
I think you made a valid point with the fact that monitors, for example, can show more detail than eyes can see.
I don't know that I consider that to be super relevant, but I'm also content watching films on DVD, so what do I know?
"Most tasks that computers are used for on a daily basis could be completed on much less powerful hardware if there wasn't a profit incentive in the way....
I want to define a(n extendable!) list of tasks that I feel like will be relevant indefinitely, and build a machine to last 30 years."
I mean to me this only leads one place; getting emacs to run on the absolute most minimum hardware :P
If you are making do on limited hardware you are mainly doing text editing at that point.
Emacs is already over 30 years old, it will be around as long as computers are around and coupled with org mode and it can do anything that involves text within a single wholistic workflow.
If a computer was designed around emacs/org mode you certainly wouldnt try to use it like a shiny new computer (and fall into that expectation trap that would keep you from truly interfacing with this computer as a new experience).
Anyways heres a pamphlet about the one true god that is emacs
@Alonealastalovedalongthe most of what I do, most of what most people do, with a computer is editing text and then sending that text to places.
Databases, spreadsheets, web pages, emails, IMs, all text at heart.
I imagine emacs has already been ported to the ESP32, but I haven't verified that.
I'm considering a slightly different approach, one that aims to be more proscriptive, but the emacs life is valid.
@ajroach42 Sorry to butt in here, but this has inspired an Idea™: what if we designed computers to be upgradable without having to /replace/ the old parts?
Like, for example, imagine if processors came on PCIe cards, and when you needed extra compute for the latest game/software/etc., you could just install another CPU card and use the cores of both?
Not only would it avoid wasting the old CPU, but you could also take that card out and loan it to a friend when you're not using it.
@keith some backplane designs kinda sorta work like this, but you're limited by the bandwidth and connectivity of your backplane.
@vertigo @ajroach42 @keith This is a very old idea, but I think it ends up being less useful in practice than you might think because of the vastly different bandwidth and latency requirements between the CPU<->RAM channel and other peripherals. In the microcomputer era and for longer with "big iron" servers everything just lived on the memory bus. But that got prohibitively expensive with GHz clock speeds.
I think we should stop thinking of those devices with CPU and RAM and a couple ports as computers and start thinking of the network as the computer, in a far more real sense than Sun's marketing people ever meant it.
@freakazoid @ajroach42 @keith RapidIO encompasses all of those configurations, and does so more efficiently than Ethernet (until you get to jumbo frames, and even then, the difference isn't huge). Its three biggest applications today are in telecommunications (e.g., cell towers), supercomputers, and spacecraft, all of which are hard real time environments with lots of compute nodes and, often, strong requirements for link redundancy.
Because it's switched, aggregate bandwidth is very high, as long as CPUs talk to devices not in contention. (Memory is considered a device.) There is no bus. It is entirely point to point, like 10-base-T and higher. Unlike Ethernet, hypertransport, and PCIe, no switch port is distinguished.
RapidIO supports not only RDMA-like transactions, allowing one to build ccNUMA architectures with relative ease, but also message passing as well. These can be mixed on the same link as well, allowing for flexibility in systems design.
Yeah, there's no way I can afford to put spec-conforming RapidIO devices into my homebrew designs.
The spec, though, is open in exactly the same sort of way as RISC-V is open. Which means I could, if I were so motivated, create my own, much slower, homebrew and/or FPGA-friendly variants. I just couldn't actually call it RapidIO.
Fun fact: at one time, I was going to do exact this, routing traffic over ordinary SPI links. RapidIO even followed me on Twitter. I think they still do.
The question now is, am I so motivated?
No. :) At least, not right now. I would get a much bigger bang for my buck if I just adopted STE or the RC2014 backplane bus standards.
I would like to revisit porting RapidIO to a hobby-friendly environment in the future though. But, I'd do it purely for the "neat" factor alone.
@vertigo @ajroach42 @keith So, like, switched SPI? That sounds pretty interesting. SPI is great from a speed perspective, but the need for separate chip select lines is a big downside. I2C is better for hanging multiple peripherals off of, but it's way slower.
Was your plan to make it packet switched with buffering of some kind? I'm reminded of cell-switched systems like the internal switches of some routers, and of course ATM.
So, like, switched SPI? That sounds pretty interesting. SPI is great from a speed perspective, but the need for separate chip select lines is a big downside. I2C is better for hanging multiple peripherals off of, but it's way slower.
Not in any generic sense, no. (Although, I have an idea for working around your specific problem too. I should blog about that some time.)
For my RapidIO mapping to SPI, the host PC would implement MOSI, MISO, SS#, and CLK, like any normal SPI interface. To support data transfer in the reverse direction, a separate pin SR# (basically, Switch Ready) would be implemented which would indicate that data was queued up for the host to receive. The host hardware would need to assert SS# and CLK to receive the data queued up.
Things get complicated when switches are introduced, however, because some ports end up as slave ports, and others as master ports, and this would have to be configured in the mesh enumeration phase somehow. RapidIO's switch protocols don't support this, so it would necessarily be a protocol-breaking feature.
Was your plan to make it packet switched with buffering of some kind? I'm reminded of cell-switched systems like the internal switches of some routers, and of course ATM.
Buffering is actually optional with RapidIO. Switches are required to hold at least one packet, but can hold up to 8 on copper links, and something like 32 on fiber-optic links, if I recall correctly. (It's been a while, so my memory on this specific detail is hazy.)
I actually did consider the use of ATM. Like, honest to goodness, 100%, 53-bytes per frame no matter what ATM. I even had a way to work around the "cell tax" by using the otherwise unused GFC field to allow a device to send shorter-than-48-byte payloads.
However, I eventually opted against it because some microcontrollers that I thought people might want to use didn't have the RAM capacity to hold even a single cell. But, OMG, I'm so tempted to just say "screw it, use a bigger microcontroller and just deal with it." It would indeed simplify so much.
I am super tempted to go this route, even to this day.
@freakazoid @ajroach42 @keith For the #ForthBox, I'm planning on using the 65SIB bus. It's built on top of SPI, but can support up to 7 devices on a single channel. The channel has seven select lines on it.
I helped create this standard back around 2009 or so with Garth, and later on, Garth wrote it up in a more formal way.
The idea I had regarding switched SPI was as follows:
When the host asserts the SPI select line, none of the attached devices drives the MISO line. The host transmits a single byte. Each device compares the byte sent against its local address. If there's a match, that one device then starts driving MISO, and starts behaving as if its own, local select line was asserted.
That's basically it.
Long and a bit rambly, sorry
@ajroach42 I have a powerful gaming desktop, a slightly less powerful gaming laptop, a good ish 2012 Thinkpad, and a bunch of Raspberry Pi's and 99% of what I do can be done on the Pi's (watching Internet things, and especially with the 4GB models that's more than enough to have 1 stream plus a few chats, plus Fedi, and probably still play Doom). There's only a few games I can't play on my Thinkpad, which has no GPU (and comes from the first gen of intel CPUs where they thought maybe we should make the GPU slightly more powerful than enough to display Win7 Aero)
You can do everything, slowly, on a Raspberry Pi, and you've been able to do it since the first Pi came out. 8 years later, and 8x the power per Pi, they're still considered "low power" and yet when I got my first RPi in 2012 the gaming rig I *dreamed* of having had 8GB RAM in it... Chillblast custom PCs could spec a max of 32GB at the time!
If we somehow convince enough people that something like a Pi is enough, then companies will *have* to bring their usage down.
Schools were meant to adopt the things (at least in the UK) but it never really happened because Microshaft has their Office suite, and programming languages so deeply ingrained it'd be like pulling the floor out from under the ICT curriculum...
A social network for the 19A0s.