P.S. I'm reminded of the short story "My Father's Singularity" (https://clarkesworldmagazine.com/cooper_06_10/) wrt. the gradual way change accumulates until a significant gap has grown.

I haven't tried reverse-engineering one yet, I hope at least some of these are hackable? Conway's life would certainly be one fun use, but custom games are totally something I'd want to make too!

Are these actually membrane or are there some switches there? I assume membrane, if only based on the dirt-cheap price. Anyway in combination with lighting up + sound the feedback feels immersive enough, it's definitely more fun than poking a tablet.

- Pine64's general model is selling cheap, quite-good, not-fully-documented hardware with expectation community software will(?) grow around it. Some of their products grow fantastic support, some less so, some remain "dev kit" — do your homework.

But then on subsequent interactions between a git client that made a shallow clone various time ago and the git server, it's AFAIU actually expensive for the git server to compute the portion this particular client doesn't yet have.

Intuitively, and very hand-wavingly, I suspect things could be improved by:

(1) clients relaxing "exact depth" requests to "give me approximately N days of stuff, over-sending being OK", and server relaxing "minimal traffic" to roughly map time ranges to whole packfiles — CPU/traffic tradeoff. (2) allowing servers to under-send too (makes (1) tradeoffs easier), by client asking for missing parts right away and/or later — needs on-demand fetch ability to be transparent to user. With "promisor" mechanism in "partial clones" this sounds more realistic? (3) storing history/trees/blobs in entirely separate packfiles(?) I suspect recent years work on bitmaps & MIDX move in this direction, only less naively?

I'm not saying Git can scale as well as a DB, but I do feel we sat on an effectively frozen Git format & protocol for a ~decade, and are now exploring more of the design space so hope future will be less clear-cut...

And specifically, partial clones remove the hard "fully offline vs. centralized" dichotomy we long clinged to. Assuming you stay online (necessary anyway if you consider HTTP/DB), things that used to be up-front UX decisions can now be matters of perf tuning!

* The most dramatic win is if you had to fetch info from every package's separate repo, like Go did. Then, a central DB/caching proxy can build global indexes, unlocking huge wins, no question. It's like "1+N" issues. However, most examples other than Go in the article talk of a single Git repo already storing a global view (still leaving opportunity for custom indexing and querying).

That's an economic win sure, but it's tragic if we fail to unlock more of their flexibility for "end users"! IMHO that's the biggest unsolved problems of computer science: that it takes so much professional learning to unlock the real potential (and even that fails us programmers much of the time! How frequently do you say "I'll solve it myself" and the time invested is actually worth it? In the words of Steve Krouse we've not quite solved "End-programmer Programming" yet.)

I do want FOSS to follow through and offer live inspectors for everything, but no, I no longer believe users should "learn to code" as the salvation. We're nowhere near it being worth their time, we actually went downhill on that :-( Conversational AI and "vibe using" will play a role, but that's more like "adversarial interoperability", doesn't cover what I mean either.

I want cross-app interoperability to be designed in, as something everyone'd understand users want. I want agency over app state — snapshot, fork, rewind, diff etc. I want files back (https://jenson.org/files/), and more¹. I want things like versioning and collaboration to work cross-app. I want ideas and metaphors we haven't found yet — I mean it when I call it unsolved problem of CS! — that would unlock more flexible workflows for users, with less learning curve. The URL was one such idea - unlocking so much coordination by being able to share place[+state] in any medium.

I want software to be malleable (https://malleable.systems/) in ways meaningful to users. I want all apps to expose their command set for OS-level configurability of input devices & keyboard shortcuts (Steam Input on steroids). I want breakthroughs on separating "business logic" from all the shit we piled, so users can "view source" and intervene on important stuff, like they can in spreadsheets. (I want orders of magnitude smaller/simpler shit too.) I want the equivalent of unix pipes combinatorial freedom² in GUI apps. I want universal metaphors for automation, a future not unlike Yahoo Pipes promised us (https://retool.com/pipes) though I don't know in what shape. I want previewable "vector actions", less like record-macro-and-pray-the-loop-works more like multiple cursor editing. I want more apps to expose UX like PhotoShop layers, where users are more productive manipulating a recipe than they'd be directly manipulating the final result. (https://graphite.art/ looks promising but that's again for visual stuff; we need more universal metaphors for "reactive" editing... I want an spreadsheet-like interface to any directory+Makefile. I want ability to include "formulas" everywhere³.) I want various ideas from Subtext (https://www.subtext-lang.org/retrospective.html).

I want user access to the fruits of 100% reproducibility, including full control of software versions (which are presently reserved to VM/Docker/Nix masters). I want universal visibility into app behavior — what it accessed, what it changed on your computer/the world, everything it logged. Ad blockers actually achieve 2 ways to inspect/intervene: starting from the UI (I don't want to see this), and starting from network behavior (I don't want it to contact this), and both give users meaningful agency!

¹ I highly recommend following https://alexanderobenauer.com/ for his "Itemized OS" research ideas. His shared work with Ink & Switch https://www.inkandswitch.com/embark/ is a tantalizing demo too. ² http://conal.net/blog/posts/tangible-functional-programming-... was intriGUIng but still too nerdy for fitting naturally into end-user workflows. (But if you like such nerdy, https://www.tandisgame.com/ is somewhat related & fun) ³ https://calca.io/, https://worrydream.com/ExplorableExplanations/

I guess https://www.folklore.org/Calculator_Construction_Set.html is the closest you get with a compiled language :-)

P.S. https://web.stanford.edu/dept/SUL/sites/mac/parc.html has good historical context on that visit(s)

* Linux live USBs can be a nice safe intro to such power? Give them 2-3 with differnt-looking distros (even if cosmetic ;-), tell them "try this for a day, if you decide which one you like it you can install it permanently". Hmm, I should try this with my kids!

Data structures, control structures/message passing, functional programming... It's really "Scheme in Scratch clothing" under the hood.

In particular, its "build your own blocks" facilities are powerful enough (including macros i.e. custom control structures receiving "body" arguments as unevaluated lambdas) for you to build any scaffolding they need to focus on concepts you want them to learn at this stage.

¹If you don't have much time to sit with them, Scratch may win on "go find tutorials on youtube".

Integration was not perfect, but it does create a json .paper file containing a url. But at least it makes you aware the doc exists every time you look at the folder.

Alas, with Paper desktop & mobile apps being deprecated, that's increasingly useless :-( Will the main app at least take over the ability to [double-]click these .paper docs to open them in a browser?

One sweet quality of RPi this lacks was being unbrickable — the entire state was on SD card; screw up and you can just write a new card. (Recent RPis complicate that with an a boot flash). But by now I've bricked enough RPis by electrical damage — including an 400 — to not be as excited about that :-]

I do agree with your analysis. All I'm saying is if one is considering a competitor, the X4 with x86 running mainline linux might be a safer bet than most less-documented ARM boards...

A pragmatic pedagogical thing I love with Snap! is the ease of creating custom blocks, including macros / custom "C-shaped" control structures. If you have some time, this allows you to "scaffold" helpers that will allow him to create interesting stuff while focusing on things you want him to learn and hiding issues you don't.

* Example: I wanted to teach rendering a custom costume with e.g. health bar or text label. My son is already familiar with Snap!'s turtle-drawing primitives that can render lines & text but there was an impedance mismatch — you draw on the screen, and it does support snapshotting all current drawings to create a costume, but using that involves some careful save-and-restore of much global state (e.g. pen color). I built him a "draw costume" block that takes a body of turtle-drawing commands and affects only current character's costume. If you ask me, Snap! should have had similar API built-in; but what's more important it was easy for me to add one that looks and feels as-if it was builtin. This way I can decide what I want to teach ("you can compute how you appear") and what is incidental complexity.

In retrospect, me unhappy + them unhappy = time to actively seek moving (which they'd still support back then); I stayed into a spiral of feedback => motivation => productivity => ... eventually I was laid off. I can't know how moving would have worked out but I regret not trying. [OT: and other passivity, not taking feedback seriously enough, sticking to WFH despite evidence it was challenging for me.]

That said a fixed-factor mutiplication can probably be done faster AND [more] precisely as a sum of some shifts. Or many other ways with a lookup table.

They also mention _approximate_ cm/inch conversion is doable by double shift on the Fibonacci scale - if golden ratio was exactly 1.6, its square would be 2.56, but actual phi² = 2.618 which is quite bad approximation for 2.54...