Ask HN: Why Databases Instead of Filesystem? 3 months ago
Consider: a cheap VPS can have disk latency above 10ms while the in-datacenter LAN can be ~1ms.
HN user
pushfoo
161 karma
TL;DR: Developer & technical writer + neuroscience undergrad
Top skills : Python, documentation, and automation GitHub : https://github.com/pushfoo/ Contact : ${MY_USERNAME}@ gmail.com
Posts0
Comments104
No posts found.
ctrl-f for "This isn't" and note how many instances of this pattern there are:
This isn't X. It's Y.
Introducing architecture variants 9 months ago
ARM/RISC-V extensions may be another reason. If a wide-spread variant configuration exists, why not build for it? See: - RISC-V's official extensions[1] - ARM's JS-specific float-to-fixed[2]
1. https://riscv.atlassian.net/wiki/spaces/HOME/pages/16154732/... 2. https://developer.arm.com/documentation/dui0801/h/A64-Floati...
This seems to be from astral, the organization behind ruff[1], uv[2], and rye[3] (all good things!).
They seem to force using python -m pip on Windows since they don't ship pip.exe[4]? This is very interesting.
From their doc[5] since the README.md's super-bare:
These Python distributions contain a fully-usable, full-featured Python installation: most extension modules from the Python standard library are present and their library dependencies are either distributed with the distribution or are statically linked.
The Python distributions are built in a manner to minimize run-time dependencies. This includes limiting the CPU instructions that can be used and limiting the set of shared libraries required at run-time. The goal is for the produced distribution to work on any system for the targeted architecture.
[1] https://github.com/astral-sh/ruff
[2]: Significantly faster than regular pip: https://github.com/astral-sh/uv
[4] https://gregoryszorc.com/docs/python-build-standalone/main/q...
[5] https://gregoryszorc.com/docs/python-build-standalone/main/
Lacking named tuple support is a deal-breaker for some projects. This is directly from their GitHub issues comments[1]:
Duplicate of #5613, still low priority, better use dataclasses, as suggested above.
1. https://github.com/python/mypy/issues/5944#issuecomment-4412...
TL;DR: Why not add a capability/permissions model to CI?
I agree that pinning commits is reasonable and that GitHub's UI and Actions system are awful. However, you said:
Maybe accounts should even require ID verification
This would worsen the following problems:
1. GitHub actions are seen as "trustworthy"
2. GitHub actions lack granular permissions with default no
3. Rising incentives to attempt developer machine compromise, including via $5 wrench[1]
4. Risk of identity information being stolen via breach
It's time to take things seriously.
Why not add strong capability models to CI? We have SEGFAULT for programs, right? Let's expand on the idea. Stop an action run when:
* an action attempts unexpected network access
* an action attempts IO on unexpected files or folders
The US DoD and related organizations seem to like enforcing this at the compiler level. For example, Ada's got:
* a heavily contract-based approach[2] for function preconditions
* pragma capabilities to forbid using certain features in a module
Other languages have inherited similar ideas in weaker forms, and I mean more than just Rust's borrow checker. Even C# requires explicit declaration to accept null values as arguments [3].
Some languages are taking a stronger approach. For example, Gren's[4] developers are considering the following for IO:
1. you need to have permission to access the disk and other devices
2. permissions default to no
We can't afford to fuck around anymore,
Sadly, the "industry" seems to disagree with us here. Do you remember when:
1. Microsoft tried to ship 99% of a credit card number and SSN exfiltration tool[5] as a core OS component?
2. BSoD-as-service stopped global air travel?
It seems like a great time to be selling better CI solutions. ¯\_(ツ)_/¯
[2] https://learn.adacore.com/courses/intro-to-ada/chapters/cont...
[3] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
[5] https://arstechnica.com/ai/2024/06/windows-recall-demands-an...
TL;DR: Yes and it's creating "It's X and limited by Y, but it works" projects
In web front-end, the same pattern crops up repeatedly. Two examples:
* Elm[1]: It's brutally functional and limited by purity, but it works
* htmx[2]: It's grug-brained[3] and limited by that, but it works
I'll let others enumerate web frameworks. On desktop, software for uxn and Varvara[4] by Hundred Rabbits fits the same pattern:
* 64k of RAM and limited to 4 colors, but it works
* Created when Xcode was painful to install on a boat over pre-Starlink satellite internet
Who knew rage-quitting could be so productive? ¯\_(ツ)_/¯
[3]: Said to be by the HTMX creator: https://grugbrain.dev/
Greppability is an underrated code metric 2 years ago
Line length is definitely configurable. All it takes is adding the following on pyproject.toml[1]:
[tool.black]
line-length = 100
[1]: Example from https://github.com/pythonarcade/arcade/blob/808e1dafcf1da30f...
Greppability is an underrated code metric 2 years ago
My understanding of black is that it solves bikeshedding by making everyone a little unhappy.
For aligned column readability and other scenarios, # fmt: off and # fmt: on become crucial. The problem is that like # type: ignore, those start spreading if you're not careful.
Greppability is an underrated code metric 2 years ago
we keep having similar problems, lol.
TL;DR: Octo[1] and OctoJam were cozy little highlights despite the grimness of the pandemic years.
Octo[1] targets variants of CHIP-8, an ancient virtual console. The language is so different from daily work that even its annoyances were refreshing. Yes, that includes having to overwrite parts of instructions to get desired behavior.
The maintainer has moved on[2] to working on Decker[3], but I'm still grateful for his dedication. He underestimates his contributions to encouraging a new generation of emulator developers. I haven't had time to do a deep dive into emulation beyond CHIP-8, but I've enjoyed making:
* A little Mastermind-like game (https://pushfoo.itch.io/safecracker)
* A terminal-like text library (https://pushfoo.itch.io/termlib-demo)
Others have done far better. Timendus even wrote his own linker toolkit to build a multi-tasking operating system[4]. If you're interested, there have been some rumblings of an October event of some sort now and then on the EmuDev Discord server to fill the gap left by OctoJam's end.
[1] https://github.com/JohnEarnest/Octo
[2] https://beyondloom.com/blog/octojam.html
TL;DR: How much of this is a potential class-action[1] and how much of this is failure to deliver on AI?
Am I missing something? On one hand, I think I get it: Intel hasn't been a GPU company historically. On the other, this quotes seems suspicious given Intel's gen 13 and 14 cores have issues:
Simply put, we must align our cost structure with our new operating model and fundamentally change the way we operate
At the same time, my understanding is AMD seems ahead[2] of Intel in AI / CUDA support. This quote seems to be a nod to that without saying much else:
Our revenues have not grown as expected — and we’ve yet to fully benefit from powerful trends, like AI. Our costs are too high, our margins are too low.
Before anyone point oout "Intel® Extension for Pytorch*" exists[3]:
1. That seems to be the official name (what?)
2. Their installation homepage seems a little convoluted[4]
[1] https://www.pcmag.com/news/intel-faces-potential-class-actio...
[2] https://github.com/vosen/ZLUDA
[3] https://intel.github.io/intel-extension-for-pytorch/xpu/late...
[4] https://intel.github.io/intel-extension-for-pytorch/xpu/late...
TL;DR: They already wrote Varvara[1] + software[2] for it
My understanding is:
* The authors wanted to run on a Raspberry Pi powered by solar + batteries
* They're often somewhere in the Pacific so their internet connection is often bad
* Varvara[1] is the portable-enough solution which works for them
* Others liked it enough to write a bunch of other tools[2]
It's all pretty much self-hosting at this point. It's not for everyone, but why bother with Windows if it fits your needs?
[1] https://wiki.xxiivv.com/site/varvara.html
[2] https://github.com/hundredrabbits/awesome-uxn?tab=readme-ov-...
TL;DR: Cut scope and call it done?
These sound like you're trying to build something with professional polish when you wanted to have fun:
Part of it feels like I've tried to do too much at once instead of building piece by piece
writing the tests for these and going back and forth on different decisions has killed all productivity and drive within me.
Why not build something awful and silly? Alternatively: add an awful plugin system and say it's left up to the user.
Git-PR: patch requests over SSH 2 years ago
I agree for smaller projects, especially personal ones. For larger projects, approaches like GitHub's web client + terminal interface might be the next best thing since grepping doesn't scale well. For better or worse, GitHub branding also helps make their specific terminal tool an easier sell in large org environments.
Do you remember WordArt[1]?
does it really cheapen it to have an obvious AI thumbnail?
Does it say "trying too hard"?
If the article isn't about AI images, they often signal one more of the things WordArt used to:
1. Cluelessness (using $HOT_NEW_THING out of FOMO)
2. Sales pitches (trying to sell you something)
3. Irrelevance (lead-ins for B2B sales to 1 and 2)
4. Hard social & technical problems
The last case is the worst:
1. They're about to discuss font rendering problems
2. Consider leaving before someone assigns you the ticket(s) for them[2]
[1] https://filestore.community.support.microsoft.com/api/images...
TL;DR: Did the lab get a chance to try integrating sensors into a nice looking, non-smart wristwatch form factor?
What we found is that seniors had essentially no desire to wear any sensors
My understanding is that much of it comes down to:
1. Fashion / utility concerns ("It looks stupid!")
2. Perceived loss of independence ("I don't want a baby monitor!")
However, even a phone accelerometer in the pocket seems to get useful if imperfect gait data[1]. If it's on the wrist, then it's enough for Apple to use it for fall detection[2].
My understanding is that you might have something fairly effective if you:
1. Made a watch look like wrist watches which seniors are used to and enjoy (no annoying screen, etc)
2. Integrated Wi-Fi sensing data like I mentioned elsewhere in this thread[3]
3. Found and added any features the sensors perceive as useful (there might not be any, however)
I know the regulatory and privacy hurdles for using Wi-fi radar data in a health-related device are formidable. However, there's a clear use case for it: detecting stroke-related movement abnormalities.
The paper on phone gait tracking I mentioned earlier[1] seemed to show the opposite side of the body had signal quality issues. Yes, using Wi-Fi data probably requires an additional device to combine it with data from the watch. However, "BE FAST" is an acronym used in patient education on stroke care because response time is critical[4].
[1] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8622042/
[2] https://support.apple.com/en-us/108896
[3] https://news.ycombinator.com/item?id=40893636
[4] https://www.beaumont.org/health-wellness/blogs/stroke-sympto...
TL;DR: Wi-Fi can already provide that signal.
We can already get full 3D pose estimation from Wi-Fi. Whether that's a good thing is a separate topic, but there's a recent paper[1] which also has a poster page[2] and a youtube video[3] embedded on it. The audio quality of the video is poor, however. There's a lot of echo.
This general line of work is what the comment from transpute[4] seems to have been implying. There's also a prior body of work on this which I'm not really familiar with.
[1] https://openaccess.thecvf.com/content/CVPR2024/papers/Yan_Pe...
[2] https://cvpr.thecvf.com/virtual/2024/poster/30463
TL;DR: My concerns are more directly practical ones about approaches (formal and humor-based) to overcoming language barriers between devs across language families
visual basic did that too
I haven't seen this on recent versions. An old MS support thread[1] suggests VB's editor has been English-only for the past decade-ish. Do you remember whether it's a built-in feature or an add-on? For example, did it get handled by replacing text, or storing ASTs of built-ins and remapping the display name? I'm not seeing much in search results.
I also haven't had time for an in-depth look at how Hedy handles their translation, but they do use Weblate to manage everything[2]. Their keywords page even has percentages for partial languages[3]. For Microsoft or whoever added a simliar feature to VB, I'd be surprised if they didn't have a way to do your own customization for an organization.
while i'm sympathetic to complaints of cultural imperialism
My concerns are much more practical. Collaboration across language barriers:
* is fairly easy when the devs are all familiar with the same writing systems
* can become mutually frustrating across writing system families, especially between Latin-derived and logographic[4] CJK[5] systems
My best example involves attempting to discuss the same differences across the same writing system gap. I had to do some careful reading to make any sense of things. However, it led to some immediately useful conclusions about glyph cache and texture atlas / sprite sheet issues for everyone involved.
Fun fact: limited space in rewritable text editing tools may go back at least as far as the Romans.
However, de novo writing writing systems seem to have very few enduring examples. As far as I know, Korean Hangul[6] seems to be the oldest and it still experienced significant hurdles for hundreds of years.
Part of it seems to be that symbol systems tend to be domain-specific if they even have grammar, let alone executable properties. For example:
* Extensions to flowchart concepts such as Drakon[7]
* Toys such as Scratch[8], LEGO's old MindStorms environment, etc
* Non-executable domain-specific markup (7 Wonders[9] and other card / board games)
This goes all the way back to the Sumerians. Although we no longer use symbols primarily as primarily a means of agricultural contract record keeping, we did some of their timekeeping conventions. Our mathematical notation is better as I understand it, but still awful and inconsistent from an outsider's perspective.
That last point got me thinking. Diagramming and working demos both help with graphics, games, and geometry questions. The first two also seem to be specific cases of the third, which is a human interest predating digital or mechanical computers.
However, low-power or emulator developer communication seems to tend toward the following instead of clay cylinders or tablets:
* Non-freeform monospace text and text boxes (although the Left editor has both nice font support and syntax editing now, thank you for updating me on that)
* Audio calls or screen sharing text boxes or GUIs (more text and symbols)
Aside from inventing conlangs[10], we don't really invent new human languages, nor do we apply them at project scale. Instead, we seem to tend to come up with neologisms and project-specific slang.
Is this a feature or a bug? I see two extremes with regard to bridging grammatical structure and writing system gaps:
1. Reject: attempt to formalize how Esperanto did (or the way you said VB did)
2. Embrace: encourage and combine it with the following:
* The way Forths tend toward being a family of dialects, each specific to an ISA or machine
* Naturally emerging labels and slang
To me, Python seems to have "regional" dialects specific to industries or codebase purposes. It's not a standard, but an emergent thing the same way I've heard Newgrounds[11] projects had a reputation for offensive variable names.
Python had humor once too. Unlike Newgrounds Python's humor was Monty Python references in example code instead of choosing variable names based on shock value. Also, Python seems to have lost the humor as it "grew up"
It seems like this sense of humor is important to early-phase software and hardware ecosystems. For example, the Uxn / Varvara ecosystem we've been discussing has plenty of it. Potato[12] isn't quite a joke with a punchline, but it is an irreverent reference to low-power computers with "bad" graphics.
Community coherence is something Octo had issues with, but both Uxn and Decker seem to be doing well. My guess is humor as a key factor.
Do you have any thoughts on this and other parts of community building or emergence?
* In your specific area(s) of interest? (low-power, long-term hardware)?
* For retro languages+hardware?
* In general?
I also realize I might be bringing way too much process and theory into this. Do you still use the email listen on your about page?
It'd be nice to have a fallback in case this thread locks or something. It's been rare to have such long-lasting discussions, so I don't remember how thread locking works on this site.
[1] https://answers.microsoft.com/en-us/msoffice/forum/all/visua...
[2] https://hosted.weblate.org/projects/hedy/#information
[3] https://hosted.weblate.org/projects/hedy/keywords/
[4] https://en.wikipedia.org/wiki/Logogram
[5] https://en.wikipedia.org/wiki/CJK_characters
[6] https://en.wikipedia.org/wiki/Hangul
[7] https://en.wikipedia.org/wiki/DRAKON
[9] https://boardgamegeek.com/boardgame/68448/7-wonders
[10] https://en.wikipedia.org/wiki/Constructed_language
Can I consider the UXF format stable?
UXF was one of the intended eventual targets of a very bad font converter I need to eventually rewrite.
ed is just a more taciturn vi.
I might quote you on this if I have to explain it to others.
if you're finding yourself tempted by ed you should probably try sam instead
Ty, I may try it then.
i don't understand the nature of hedy but it sounds like just another scripting language; what would make it especially difficult or costly to implement? i don't understand what you mean by 'user-localizable' or 'more overtly'
The language drop-down on the editor / try-it page translates not just page text, but the scripting language keywords itself. I haven't had time to dig into it yet, but it's inherently an internationally oriented scripting language by design since the goal is to allow adding your own language to the supported set of keyword display languages.
TL;DR: You may be right about LISP issues, but my intent was show how IO and social factors seem key to platform success
I'll skip discussing Python for the moment because I think there are a lot of things wrong with it. If I try, we'll be here forever, but they mostly come down to not enough consistency and it being pointless to discuss for reasons which will become clear below.
Whatever the nature of the cause/effect of the LISP ecosystem, I see Octo's issues as similar in result:
1. There is no way to load and persist useful data in any popular CHIP-8 variant
2. Once people get a taste, the lack of IO means they do one of two things:
* leave
* become emulator or assembly developers
Keep in mind, I still see this as success. This is based on my understanding of the Octo author's post saying farewell to running OctoJams[1] and my time as a participant. It got me interested in assembly and has helped many other people learn and begin to use low-level tools.
Compare this to Uxn:
* Although flawed, it has useful IO capabilities
* People have built applications which they use to perform real work every day
* An already-familiar ecosystem of tools exists to cater to the interests of similarly-minded people
40 years ago lisp was vastly more capable than the alternatives, along many axes. smalltalk was an exception, but smalltalk wasn't really available to most people. both as a programming language and as a development environment, lisp was like technology from the future, but you could use it in 01984.
Yes, I think that's getting at what I mean. One of the motivating factors for 100r was that Xcode is bad fit for people who live on a boat with solar-powered computers. So are Visual Studio or PyCharm.
Although the Uxn ecoysystem is far from optimal, it's still better than those heavy IDEs. Better yet, it was already mostly here a few years ago. Even to this day, it feels like it's from some point(s) in a better timeline where the world wasn't full of leftpad/polyfill/AI or whatever the next ridiculous crisis will be.
In other words, Uxn is a pidgin[2] of ideas "solarpunk" or even just small, understandable computer types like. At the same time, it does this without too much purism holding it back:
* Simple enough and familiar enough mish-mash of forth and low-color, plane-based display
* Low enough power that its cheaper than Xcode to run without more effort
* Enough IO capabilities to get things done
Since it already had all of this as of a few years ago, it's had time for social effects to take off. For example, you can share a picture, a music track, or text made using Uxn-based software. Those files will still work even if the Uxn spec evolves in backward-incompatible ways again. Its design choices are also inherently good for (or limited to) producing art aligned with the aesthetics of the creators. That seems to be part of a self-reinforcing popularity loop at this point.
Although it's theoretically possible to make similar things using CHIP-8 based tools, nobody bothers. Even if you record the output of music sequencers which have been written for it, you can't really save your work or load in data from elsewhere. In theory, there's the 16 bytes of the persistent state registers in XO-CHIP which could be repurposed from a calculator-like thing into IO, but the fact I'm mentioning it should underline the main issue in that community: purity concerns. Those limit it more than having "real" 16 buttons do. Yes, you could do some interesting multiplexing or even just bit-shift every other button press to make a pretend terminal-like keyboard, but the purity focus inadvertently kills interest more than silly function pointer syntax.
Decker is the complete opposite of Octo in this. It also goes even farther than Uxn in giving up purity concerns. Sure, it's complicated and inefficient, but it is inherently built around sharing widgets with others in a mishmash of HyperCard and Web 1.0 revival spirit:
1. You can make gifs with it, and this is probably its most popular use in the form of Wigglypaint[3]
2. When asked "um, can I borrow source from it?", the answer is "Absolutely!"[4]
This is why as much as certain Python projects frustrate me, I'm not trying to fix their inherent Python-ness right now. I just accept they're what they are. As you pointed out, it's better than the alternatives in many cases. Before you ask, I won't go as far as calling JavaScript is good, but I'll admit it's shareable. :P
[1] https://en.wikipedia.org/wiki/Pidgin
[2] https://beyondloom.com/blog/octojam.html
TL;DR: US manufacturers seem to favor the luxury market due to margins, but that might change
To my understanding, there are two main demographics:
* truck as tool (you and I)
* truck as identity statement & luxury good
Sadly, long-running vehicles don't fit the short-term stock price boost margins on luxury features seem to offer. As a result, we've moved past heated seats to focus on:
* ever-growing size
* tailgating accessories
* touch screens and voice assistants
However, even the target market for this seems to have its limits. I've seen a forum thread where people are asking what the point of Alexa is[1] if it doesn't integrate with anything. If you look at the "Similar threads" section at the bottom, there are plenty more Alexa sync issues.
Maybe people will get fed up eventually?
[1] https://www.f150lightningforum.com/forum/threads/is-alexa-us...
you'll note that ex(1) is installed by default on every linux distribution except alpine
On my system, it seems to be set up as an alias of vim ("Entering Ex mode"). Huh. A bit more reading after that has been an interesting historical detour.
i know a programmer who still uses it as his preferred editor, preferring it even to vi
I've never tried ed before this comment. Others might see it as strange and clearly teletype-oriented, but I think it's refreshingly explicit about every action taken. Even more than ex, it's a vim ancestor where commands and state are persistently visible instead of being hidden.
Thank you for mentioning this, but now I'm a little worried I might start wanting to use ed too.
i've certainly done plenty of real work with tcsh and bash, where the primary user interface paradigm is editing a single line of text to your satisfaction, submitting it for execution, meditating on the results, and then repeating.
I think you've hit on something important here. Web-oriented workflows with live reload (and Flutter[1]) inherit this. I think it means the form of the REPL itself isn't what we should be focusing on, but easy iteration and maybe cached results to save power and time.
On the topic of accessibility, do you have any opinions on Hedy[2] and whether a long-lived, low-power system might have room for something like it? The site is annoyingly JS-filled, but the idea is interesting: a language where the names in the symbol table are more overtly a user-localizable value.
'll reply in more detail later
np! I'll comment now in case it gets weird about a double-comment on the same parent by the same user.
> I think it's the primary use case like Java Applets and Flash preceded JS as iterations of sorta-portable and low efficiency tools which make up for it with sheer volume of high-familiarity material.
i wasn't able to parse this sentence. could you unpack it a bit?
Software that doesn't care about being well-made or efficient. It doesn't matter because it's either fun or useful.
> If you'd like, I can provide more specific suggestions.
yes, please! even if our priorities aren't exactly aligned i can surely learn a lot from you
This is a long topic, but some of it comes down to Decker[1] vs Octo[2]'s differences:
* Decker can be used to make and share things that process data
* The data itself can be exported and shared, including as gifs
* Octo can't really, but it does predate the AI commnity's "character cards" by shoving game data into a "cartridge" gif
* Octo has LISP Curse[3] issues
I'm serious about the LISP curse thing. In addition to awful function pointers due to ISA limitations, everyone who likes Octo tends to implement their own emulator, tooling, etc and then eventually start down the path of compilers.
I haven't gone that far yet, but I did implement a prototyping-oriented terminal library[4] for it. Since Gulrak's chiplet preprocessor[5] is so good, I didn't bother with writing my own.
i just want to clarify that i'm not za3k
Ty for the reminder. On that note, the larger font sizes you brought up are seeming more important in this moment. I don't think I can deal with 4 x 6 fonts on tiny screens like I once could. HN's defaults are already small enough.
[1] https://github.com/JohnEarnest/Decker
[2] https://github.com/JohnEarnest/Octo
[3] https://winestockwebdesign.com/Essays/Lisp_Curse.html
TL;DR: Thank you for confirming some mismatch in display hardware and project goals
also, evaluating things 60 times a second is not a good fit for low-power systems of any kind.
Agreed. As to a terminal-mode UXN, you pointed out:
as for uxn, uxn is the first attempt at frugal "write once, run anywhere" that's good enough to criticize. everyone should read devine's talk about its aspirations
I think it's the primary use case like Java Applets and Flash preceded JS as iterations of sorta-portable and low efficiency tools which make up for it with sheer volume of high-familiarity material.
nor is it good for programmer productivity
I'm curious about this. Could you please elaborate?
When trying earlier uxntal versions, the worst part seemed to be the string syntax. If it wasn't because it seemed easier at the time, my guess is the pain point might be intentional nudges away from making things the designer doesn't like.
and it’s not all that simple.
This is where I get confused:
* Can you explain more about your views on this?
* Do you favor a specific structure of hardware, OS code, and user scripts, or whatever ends up offering the best use of power and long-term device durability?
i'm not sure how well the existing varvara applications will work at 400×240 or tolerate a requirement to use fonts many pixels tall in order to be readable
Counting mW and decades implies text > GUI. Despite 100r & fans favoring GUI, there's an UXN terminal mode and a few math and terminal libraries written for it.
As to GUI, many of the ecosystem's GUI programs are FOSS with room to shrink the graphics. There's a decent 4x6 px ASCII font which is CC0 and could help, but as fair warning, it's awful at accents and umlauts.
possibly i just haven't written enough forth to have the enlightenment experience yet, but currently my hypothesis is that forth is just hard to read and that's it, and that the really great thing about forth is not actually the language but the interactive development experience
This seems to be a universal opinion since REPL isn't rare anymore. Being portable and easy to bootstrap are probably the main draw now. In addition to 100r's work, I think remember hearing ${NAME}boot or another project used it to simplify porting.
the varvara display model is not a good fit for the memory-in-pixel displays, which only have one bit per pixel, while varvara requires two.
Ah, this is what I suspected. I wasn't sure I understood the display you mentioned, so thank you for confirming the hardware mismatch.
Although your blog showed you'd considered two identical side-by-side displays[1], I have a radical idea which might not be a good one:
1. A "Full" display of W x H characters (the Sharp display or whatever you replace it with)
2. A "Fallback" 1 or 2 line display (2nd line reserved for editor info / UI?)
A single 1-bit editable line is so hard to work with that ed[2] isn't even installed by default on many Linux distros. However, people did once got real work done with it and similar tools.
As a funny sidenote, this is where non-colorForth[3] forths may align with UXN's dev. He's a Plan9 fan and uses its Acme editor[4]. So Varvara is theoretically capable of syntax highlighting, but he refuses to implement it as far as I know.
as for tools for software development, program launching, editing text, editing fonts, editing other graphics, and sequencing music, i'm confident i can write those myself if i have to. i've written a compiler in a subset of scheme that compiles itself, a compiler in a forth-like language that compiles itself, various toy text editors, various virtual machines in under 150 lines of code, and various pieces of music synthesis software
You may be pleasantly surprised by how many people will show up if you start building and releasing tools which:
* let them solve problems or have fun
* allow extending the tool
* can be used to build their own tools
Many will will even contribute back. To paraphrase the Gren[5] maintainer's recent livestream:
we've had more engagement in our time on Discord than all our years on Zulip.[6]
maybe i should set up a patreon for this or something, maybe people would be interested in supporting the project
Based on your blog, I think you can safely skip to the footnotes:
* GitHub sponsors might be worthwhile if you're willing to use non-fully FOSS platforms
* Don't make people feel like they're paying for their own work
* Do let the system do real-ish creative work and self-host, even if only as emulators
If you'd like, I can provide more specific suggestions.
[1] https://blog.za3k.com/zorchpad-update-cardboard-mockup-mk1/
[2] https://en.wikipedia.org/wiki/Ed_(software)
[3] https://concatenative.org/wiki/view/colorForth
[4] https://wiki.xxiivv.com/site/acme.html
[5] https://gren-lang.org/ (Disclaimer: I sorta contribute to this now)
[6] https://www.youtube.com/watch?v=PO8_pV7r168 (Sorry, I don't have an exact timestamp, but I'm pretty sure it was in here)
TL;DR: Yes in JS & often elsewhere, so read The Grug-Brained Developer[1] to laugh about it
Nearly 10 years ago, we had the left-pad incident[2]. As I post this, people are in a panic over a similar issue. This time it's called the polyfill incident. The details are different, but they don't really matter.
The root cause is the same:
1. People saw nice code
2. They didn't make backups of the nice code
3. Instead, they trusted someone else to keep serving it
This time, the trusted party served malware instead of deleting everything. Innovation!
A more serious (but still oversimplified) take: static linking and/or vendoring can mitigate this for a price:
* Vendoring is copying other people's source into your repo
* Static linking is the compiler doing the same thing with binary code
It's a trade-off:
* Pros: durability and longevity since everything's in one .exe / folder / zip
* Cons: lose flexibility and gain software license complications with the LGPL/ etc
It also isn't as trendy as "what you need to know" articles.
For educational yet actually funny takes, I suggest reading these:
* The Grug-Brained Developer[1], a light-hearted take about complexity being bad
* The famous ML / AI XKCD[3] about stirring big piles of numbers. What's changed since then?
* The size of the number pile
* How fast we (our GPUs) can stir it
* The amount of investor money having the tallest pile can earn
* NVidia's stock price
[2] https://arstechnica.com/information-technology/2016/03/rage-...
TL;DR: The TRS-80 Model 100[1] indeed looks closer than the AlphaSmart!
If something like that TRS had e-ink, it might be what I'd had in mind. If you're familiar with the idea of the OLPC hardware[2], like that except:
* More durable
* Lower power
* E-ink
* Not effectively vaporware
On a related note, I heard Pixel Qi[3] displays were interesting. However, the company folded. Some panels seem to pop up for sale now and then, but my understanding is they're effectively obsolete.
The recent Clockwork-PI evokes it - but the keyboard is a toy
That's a shame.
it’s just a Linux laptop with all the distractions therein
After taking a look at the device, this seems like an understatement. The Clockwork-PI[4] looks like it's mostly an emulation machine. For anyone who doesn't want to click through, it's a Game Boy form factor with a few extra buttons and a keyboard below the D-pad.
To be fair to the device, I think it's different class of device. It also fills some very specific niches:
1. Prototyping for GB/GBC games on higher-power hardware and higher-level languages
2. A decent front-end attached sensors if you can use USB
As example of #2: Mapping WiFi signal strength. Walking around a building holding a clunky laptop while someone else held the antenna wasn't fun. It was what we had to work with given the deadline, but if I had to do it often, I might want something like the Clockwork PI if someone could source better keyboards.
[1] https://en.wikipedia.org/wiki/TRS-80_Model_100
[2] https://en.wikipedia.org/wiki/OLPC_XO
TL;DR: Freewrite[1] tries but it isn't the same
They are selling a line of professionally oriented devices. I'm not sure they're worth it.
* The "Alpha" model[2] nods to the AlphaSmart form factor, but it isn't e-ink
* Weird-looking keyboard layouts with no Apple-style key in sight
* These devices are expensive for what they seem to offer
I've never used one so I can't really speak about more than what I've seen on the site. There were some negative reviews of earlier models. I'm not sure how current ones rate, nor what their keyboard feels like.
TL;DR: I love this idea and have two questions:
1. For early iterations / similar projects, could all-metal screw terminals[1] accept power internally?
2. Would supporting UXN/Varvara[2] be an option?
More on these questions below after initial comments.
## Initial Comments
if you aren't worried about going batteryless, or about mass production, you could literally buy an alphasmart neo and wire its keyboard and display up to an esp32 or something
I could, but it's a limited in availability. The keyboard is pretty important in my opinion.
memory-in-pixel lcd displays
I vaguely remember hearing about this, but don't have the EE knowledge to judge the benefits of these. Data sheet for anyone interested: https://www.sharpsde.com/fileadmin/products/Displays/Specs/L...
## 1. The screw terminal:
Disclaimer: I'm not an EE specialist.
My understanding is that if the power loss isn't too great, an all-metal internal screw terminal[1] might improve device durability:
* The power source could be replaceable. AA, AAA, LiPo, solar, etc
* If you don't solder to the metal part, even sandpaper or a conveniently shaped rock could remove oxidation
* For a case, internal screw terminals could turn a charging port into an easily replaceable component
## 2. UXN/Varvara:
From your blog, I see an "artemis apollo 3 board"[3] is being used. From a Sparkfun page[4], it seems to have enough ram to host graphical Varvara.
I was initially doubtful of UXN despite loving the idea, but:
1. The UXN community seems to have built a self-hosting ecosystem[5] of:
* development and GUI ROM launching tools
* text, font, and graphics editors
* music sequencing tools
3. The core UXN VM is simple: a minimal implementation fits in under 150 lines[6] of C89
[1] https://en.wikipedia.org/wiki/Screw_terminal
[2] https://wiki.xxiivv.com/site/varvara.html
[3] https://blog.za3k.com/zorchpad-update-cardboard-mockup-mk1/
[4] https://www.sparkfun.com/artemis