Perhaps the most vital dev tools for our hypothethetical string-centric hardware would be those for converting from a human-legible form (stick to text status-quo since this hardware is string-centric, caveat) to what each of our coprocessors can reasonable be expected to understand!
And back! Though I'd minimize the need for that by shipping updates as source code where I can.
Also tools to run these programs, providing an intuition over their behaviour.
The Graphics Compositor & SFX coprocessors would be primarily programmed by the Output Unit using compiletime constants. As would the Arithmetic Core, with the aid of a special "label" type.
To aid debugging that Arithmetic Core I'd probably end up creating a tool which has the Input Preprocessor emulate its RAM, triggered by user input or a periodic timer. So we can stepwise debug the program, and view its entire state! As well as a disassembler rendering arrows for control flow.
2/3?
To debug those output programs it could be useful to send them a signal ranging from low to high, to see/hear how the handle each input value.
Similarly I'd have a tool which runs an FPMA program output the results as scatterplots showing the output for each value of each input (holding other inputs to, by default, zero), verbalized as differently-pitched beeps. I've already described how its compiler would work.
And I've already described a stack of language for our "Layout Coprocessor".
3/4!
This Layout Coprocessor would have tool rendering its visual output for given input values, with an option to sweep an input from low to high to see how the output responds to every value.
The Output Unit (frequently combined with the Parsing Unit) would have tool that opens tabs/windows for all the outputs (including the Arithmetic Core's code) generated by running one of its programs.
And I'd give the Parsing Unit a tool which styles its input text to annotate which rules it matched.
To load additional code into kernel-space, you can use various commandline tools which call the appropriate syscalls & device files. With the kmod command dispatching to the appropriate subcommand.
After parsing commandline flags insmod converts remaining arguments into a multi-string, & constructs a Module object to (with preprocessing) call the init_module syscall.
There's someadditional logging infrastructure, which might write to Syslog.
After validating no further args are given lsmod parses each line of /proc/modules (via LibKMod) & iterates over the linkedlist to serialize textual output. Any benefit here beyond cat /proc/modules?
After parsing commandline flags (filling in missing args with uname) depmod constructs some directory paths to consult, validates a dependency files/directory, initializes various objects, iterates over a given file (one format or another) gathering symbols to link into a hashmap, ...
2/4
... loads all the config files & a directory of modules OR loads the modules listed in commandline args, converts the modules hashmap into an array, parses a modules.order file consulting the hashmap, computes a topological sort of dependencies from the gathered collections, & outputs the results in a choice of format.
After parsing flags filling in missing onesmodinfo builds a KMod context & iterates over remaining args (which it validates exist) loading their modules in 1 of 3 ways.
For each of those modinfos modinfo serializes various info LibKMod has parsed from device files.
After parsing commandline flags modprobe initializes logging, fills in missing parameters, initializes a LibKMod context having it parse its "resources", & runs a chosen subsubcommand.
These subcommands may output various properties of the LibKMod context, output loaded version numbers, output a module's symbols, or hand off to rmmod or insmod.
After parsing commandline flags rmmod initializes a LibKMod context & iterates over remaining commandline args (validating they exist) leading each given module in 1 of 2 ways. Calling the delete_module syscall on each via a light LibKMod wrapper.
After parsing commandline flags static-nodes opens modules.devname device file directly & an output file, to parse the modules.devname to reformat into a chosen format.
The problem with federated alternatives to centralized services (and also one of the main problems with centralized services which lead people to look for an alternative) is Discovery.
Etsy and Twitch and YouTube provide an audience, supposedly. With the right pitch (and the right advertising dollars) you can get your own slice of that audience. (For as long as the algorithm graces you, and as long as you're willing to stomach the other things your viewers will be algorithmically suggested.)
Over spent the past year I explored how I'd build a browser truly from scratch, hardware on up, over the next month or so I'll explore tooling to help us build this!
Can we self-host the development? Without pulling in other OSs, being self reliant?
Not for the AI models (text prediction, speech recognition, machine translation, etc) since that would require faster hardware. The AI coprocessor I described would get worn out training itself.
And not initially: Before we can write software on our device we'd already need most of this software already running on it! Unless...
The easiest way to get started is probably to hook the device up to external hardware or (ideally) software terminal (via RS232 over USB?)! Giving us text entry & rendering (with retro flair!) as well as the ability paste text from the web, filesystems, or text editors before we reimplement these things for ourselves as we gain self-reliance!
In designing these dev tools I'll strive to make the software easy to study & (minor caveats) modify on-device, whilst hindering the ability for others (whom you interact with over the internet) to claim that control for themselves.
I won't extend the hardware to aid implementing these dev tools, since they're not the main point of the device. Though at times I will discuss "clever hacks".
3/3 Fin for today! Tomorrow: Introduce compilers & code-runners.
As a massive project Linux is split into several mostly-but-not-really-independent "modules" which get dynamically linked together as the kernel is running! Userspace (rarely) generally initiate this via the topic of today's study: LibKMod!
There's an iterator over the multistring in a modules.builtin.modinfo file. It may use OpenSSL to check cryptographic signatures. It implements a doubly-linked list datastructure. There's a parser & builder for KMod options.
LibKMod may parse binary ELF files to simplify the work done in (hostile) kernel-space. There's a layer integrating a runtime-choice of decompression libraries, in case the kernel doesn't support these formats. There's abstractions around files, including memory-mapped BTree lookups.
Perhaps one of the 2 most central sourcecode files models & parses a ref-counted kernel-module object, abstracting those support routines & certain device files, & e.g. the init_module syscall.
The other main file (aside from implementing some logging infrastructure) defines a ref-counted "context" object with accessors some of which may be sourced from device files, & queries collections via various device files with in-process caching.
2.5/2.5 Fin for today! Tomorrow: KMod commands, then: kernelspace side!
Developer's PSA: The way you & your culture do things isn't the way everyone does things! Be wary of cultural constructs, no matter how basic they may seem!
Time & dates. Text. Punctuation. Names. Addresses. Iconography.
What else am I forgetting?
P.S. This is also a politics PSA. Very topical to NZ right now!
@smallcircles NZ Act's David Seymour is removing sushi from school lunches because its "woke". He only wants the most western/kiwi of foods in the school lunch program.
While I don't particularly care whether sushi is in school lunches, this reasoning must be mocked!
Doctorow's article from Tuesday (I read it yesterday) made heavy reference to his fight at the W3C against EME (their DRM standard).
That brings me back... Frustrating times! The arguments defending EME felt spurious as they accused us of being spurious. Splitting meaningless hairs over whether EME is DRM in-and-of itself. In the end advertising EME as being DRM.
Under the insistence that Flash needed to die, & the Web required Netflix et al.
The way I think about DRM: Its an (injust) law masquarading as technology.
It would've been great if W3C took a stance, but in attempting to be neutral they sided with the status quo. At the very least we made it utterly clear this is controversial!
And I think those championing it know what they're meant to believe, but not why. In practice DRM isn't meant to constrain audiences directly, its meant to constrain developers of playback hardware/software. Shaping technological reality.