LisPi

Hi, I'm Lispi, Lisp (Technomancer) Wizard (to eventually be).

You might know me from LisPi (npub1rp2…mhtw)

I like Free Software, #Emacs and resilient computing a lot.

I also like anime girls, animes with cute girls doing cute things and artwork with them too. Cute stories are good too.

Some Pins:

Software and Assumed Privilege, common problems: https://mastodon.top/@lispi314/111253066257920146

Writing Privacy-preserving software & services 101: https://mastodon.top/@lispi314/110849018589421824

Current avatar: Cyn from Murder Drones, in her cute maid drone appearance.

#Kopimism #FreeSoftware #CommonLisp

Last Notes

2026-10-07 03:32:04 UTC

- reply

> I guess we have a different view of the reliability of sqlite
I also consider reliability as a project, rather than just as software.
The latter has been proven-enough, but the former could fail at any time (although I mentioned the mitigation caveat).
I also just don't really like the idea of storing large blobs in SQLite, the way it handles that is pretty bad in my opinion (and multi-DB support is *documented* flakey in a bunch of additional ways too). I spent a while investigating the various databases to see if it was practical (because I wanted to do it) and was rather disappointed even by the ones that handled it best (PostgreSQL has a bunch of dumb limitations that suggest it was implemented before they had partitioned tables and was never touched since).
The closest to a satisfying option I could imagine there (without changing a *lot* of its storage management model) would be to add an extension to SQLite that enables handling external blobs in the same transactions as internal storage (a lot more reasonable to do this with SQLite than PostgreSQL actually, since collocating the DBMS and the user simplifies a bunch of things).
That does constrain implementation languages to ones that can do FFI callbacks (or C) or at the very least require one such language for implementing that part.
> sqlite also provides indexing, which will be unavoidable for pruning old content, deduplicating blobs, finding files that actually changed, etc...
Yeah, all of that would need to be handled.
> You may 'pragma wal_autocheckpoint=0' to disable autocheckpointing in wal mode
Not quite what I had in mind. This still calls fsync at least once per transaction.
The not-completely-applicable PostgreSQL example I linked batches multiple transactions as a single unit to write out & sync, if they happen with a given timespan.
My idea was more like accumulating N chunks of changes (or up to M files if they're smaller) before committing any of that to disk.

2026-10-07 01:38:05 UTC

- reply

> Way more tractable.
It does still tie it in ways I find uncomfortable.
The metadata database being SQLite is sensible-enough. The risk of upstream going evil is somewhat mitigated by the strong stability that allows for just pinning it without consequence.
> sqlite provides the structure. blobs contain files content and nothing else.
Ah I see, yes, not conflating control & payload.
I would say structured binary formats would also provide the same loss of ambiguity, but they are more work if one can rely on SQLite (or something like LMDB, if you just go full key-value store).
> sqlite has that
I was under the impression it would be in the program using it. It does? I had thought unlike some [like PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-COMMIT-DELAY) it was missing this.
Would you have a link?

2026-10-05 17:14:29 UTC

- reply

I think one in something like Scheme or SML would be.
Something safe and reasonably tractable to reimplement (C++ is not as bad as Java, but I think it might be worse than Common Lisp on this), and which permits less verbose implementation.
Mostly it being a reimplementation (or binary-compatible output, anyway) of one of the current ones (borg, duplicity, dup, dar [...]) sounds like would be fine-enough.

2026-10-05 08:31:49 UTC

- reply

Those are possibly promising.
I'll have to check *which* version of C++ DAR expects though because the main compilers that implement recent versions are kind of fucked.
Meanwhile `bup` is Python so like... hopefully it isn't based on too-recent a version/set of features.

2026-04-19 16:15:50 UTC

- reply

Ethics is part of the mandatory curriculum for engineering schooling here for basically *everything* other than software and due to stronger unions & such, they also *do* in fact care.
They are also made to *have* to care because they're liable if their stuff kills people or leads to considerable harms.

2024-09-10 20:52:23 UTC

- reply

Cost can be ignored in a number of ways.
Basic physics issues, not so much. Radiation-hardening & using fault-tolerant systems is feasible
Practical concern related to maintenance: How is one going to send someone up for maintenance? Are they going to live there?

2024-09-10 20:31:31 UTC

Regarding datacenters in space... there's a reason they're built on planetary surfaces, usually.
They use the planet & its atmosphere as a heat sink. Where's that heat going to go in space?
Radiate it away? One *will* have to throttle the compute a lot for that to be enough.
That datacenter will be worse and less reliable than one hosted in some random programmer's homelab.

2024-09-04 22:02:25 UTC

- reply

> i don't have a lot of experience with that, it seems like a cool thing but it still feels uncommon for gui to be interoperable or for graphical windows to communicate with each other.
It is, it's a common flaw of modern systems for it to not be a thing by default. BeOS had it as a thing by default.
> i've noticed that often gui programs change how they process input or stop responding to outside input altogether once the main window has been launched. maybe i'd attribute that to bad development though.
In some cases that's bad frameworks, in many other cases it's bad programming.
Part of the issue with GUI frameworks on UNIX-likes is that they adopt a view of a hard division between GUI & /somewhat/ interoperable POSIX CLI.
> meanwhile with cli scriptability is the default and expected behavior. in gui it's still very lacking.
I would say that CLI scriptability in UNIX-likes are also uniquely awful.
PowerShell did it better. Unstructured pipes simply shouldn't be a thing.
Ideally, programs would have mailboxes capable of receiving dynamically-typed messages with proper structure.
(And then of course LispMs didn't need pipes because the Listener allowed simply using Lisp.)