No, for it to be retropunk, it would need to just work. Not necessarily work well, but just work.
QBasic would be fine. GW-BASIC would be fine. P5.js would be great. Hypercard would be adequate. Heck, even raw assembly code would work.
Documentation on jailbreaks, microcontroller versions, ssh, and file systems? Not so much.
The whole point was /simplicity/. Simplicity isn't the same as ease-of-use or speed-of-use, but old-school computers might boot into a BASIC interpreter. That was simple.
I'd love to have a simple eink solution. I don't care if I'm manually flipping pixels or have high-level APIs, and I don't care if I'm using BASIC, Makecode, Python, or C. I do care that it just works, and I know ahead of time it just works.
What I don't want is I buy an old Kobo on eBay, and find out it's not jailbreakable, or requires some library which requires a different version of Ubuntu, or whatnot. I don't need another half-baked project.
The actual ultimate here would be an all-in-one which is micro:bit compatible. All-in-one means it includes a case, a reasonable form factor, and works in standard micro:bit programming environments.
Any of the e-ink pads that run Linux under the hood and expose SSH can get you to a bash prompt. Which is about as simple as one can get.
Why does it have to be /simple/ anyway? With a rich programming environment you can make your own simplicity. The world needs more devices that force you to come to them, not the other way around.
> What I don't want is I buy an old Kobo on eBay, and find out it's not jailbreakable, or requires some library which requires a different version of Ubuntu, or whatnot.
I understand what you're getting at. When I was following some of the article links with respect to the Remarkable 2, I had the exact same concerns when they were discussing how you need to wait for the patches to be updated to new firmware versions since the screen driver was integrated into the software. Needless to say, I have also been bitten by such things with other devices.
That said, you picked a poor example. Kobos aren't locked down in any meaningful way. Anyone with a knowledge of Unix and how the update process works can inject their own software. There are no secrets. There is no encryption. At least when it comes to the operating system. It is the way hardware should be, albeit it is so rare for it to be so that it is easy to jump to conclusions.
Odd, I always considered retropunk as something requiring a specialist skillset. Breaking into systems to bend them to your will etc. Different perspectives I guess.
I was using the definition from the article: "... we don’t have to suffer with abstractions on top of abstractions. It’s DOS for the 2020s. It’s graphing calculators for grown-ups"
Yours is probably a better one, but perhaps less relevant here.
QBasic would be fine. GW-BASIC would be fine. P5.js would be great. Hypercard would be adequate. Heck, even raw assembly code would work.
Documentation on jailbreaks, microcontroller versions, ssh, and file systems? Not so much.
The whole point was /simplicity/. Simplicity isn't the same as ease-of-use or speed-of-use, but old-school computers might boot into a BASIC interpreter. That was simple.
I'd love to have a simple eink solution. I don't care if I'm manually flipping pixels or have high-level APIs, and I don't care if I'm using BASIC, Makecode, Python, or C. I do care that it just works, and I know ahead of time it just works.
What I don't want is I buy an old Kobo on eBay, and find out it's not jailbreakable, or requires some library which requires a different version of Ubuntu, or whatnot. I don't need another half-baked project.
The actual ultimate here would be an all-in-one which is micro:bit compatible. All-in-one means it includes a case, a reasonable form factor, and works in standard micro:bit programming environments.