New Documentation Repository -

System Apps

Directory Help Language Random Channel Report Bug Search

New Documentation Repository

2026-06-05 02:06:53

Scott's Code Journal

Scott's Code Journal via Der Pepe (Hubzilla) ⁂

scott@codejournal.dev

One of the things I have been doing recently is capturing documentation as I go.

When you are deep in a project, you figure out things that are not well documented anywhere. The problem is, if you do not write it down while it is fresh, you forget it... or you have to rediscover it later.

So I started keeping a GitHub repository where I capture notes and reference documents as I work. The idea is simple: write it down now, publish it later. The source lives in the repo, and from there it can be published to development.guide, neuhub.org, federatedhub.org, or wherever else makes sense.

It is just getting started, but it is public and contributions are welcome.

#^https://github.com/WisTex/Development-Guide-Docs

2026-06-05 14:12:27

git64bit

git64bit@directory.diagnostics.kane-il.us

A few problems with documentation is that documents get stale, and they grow - oh boy they grow. Then the text type - linking them will end up orphaning your entire set. Wiki, gemini does not matter, it will turn your crop of docs into a field of carcasses. The only thing I learned over the last 30 years is that the less documentation, the better. No documentation is bad, too much is worse. I got better avoiding to build more than absolutely a must. The fact is, if you are not doing something enough to turn into a muscle memory, its often more efficient to re-discover than looking for the docs.

2026-06-05 16:25:13

git64bit

git64bit@directory.diagnostics.kane-il.us

All the links return 404.

What I m going to do going forward is RAG with a small model, which is eventually most hackers going to end up doing. Especially when the KB is on something like the IPFS, the RAG is a natural pairing with text without any meaningful context by the file name, file type or the path.

"chunks of text" is also better suited to JSON IMHO, so a database-like chunked corpus even more lends itself to be consumed by RAG.

2026-06-05 17:04:33

git64bit

git64bit@directory.diagnostics.kane-il.us

I look at the markdown about versions.

I seem to recall traces of the RFC and the BCP, where "versioning" is mostly meaningless they are simply superseding one another. On the IPFS "versioning" is totally meaningless since the hash changes for anything not just for rolling the rev. And for RAG - the context wins out every time. So I stopped 'versioning' a long time ago - document or code I do a tag in git and move on, the entire release is "versioned" all at once.

I think effectiveness, efficiency works against versioning (not the same as against version control, which is obviously required in a multi-user setup). But for the single user, even where the user base is a large crowd, versioning has passed its prime.

2026-06-05 17:14:16

git64bit

git64bit@directory.diagnostics.kane-il.us

Hm, now come to think of it I have seen even the chemical ingredients, the so-called Full Material Declarations of electronics components "versioned", sometimes. In practice you cannot change the substances in an IC, that would result in a mayhem - Imagine the NE555 made by a hundred different manufacturers over the last 50 years change their revision of the FMD. In the electronics industry a new "version" is a new part number, period. Just by packaging the same IC in a different footprint does not change FMD revision.

So when I see a "revision" on the FMD it seems without utility, and it is.

2026-06-05 17:50:45

git64bit

git64bit@directory.diagnostics.kane-il.us

Precisely. Currently I am working on three lxc containers - one is the Hubzilla node, the next is an orchestrator node that receives the JSON contract. It is the orchestrator that pushes the data inside the JSON into the SQL database, because JSON is both fluid and it converts to a valid SQL schema. I don't version I tag when the contract between the two container change.

I can still go the same paranoid and version everything, but as I already wrote - it would only help adding more stale information. But you are correct about the legacy practices, the MIL-SPEC is full of arcane stuff, and my employer calls them clap-traps. Half the stuff on the BOM has not been made since the 1990s.