software situation

My goal is NOT to disrupt the "programmer's model" for "average developers". They should truly be able to think that they are running on a uniprocessor but without any guarantees as to throughput (to accommodate sharing the physical processor, communication overhead, etc.).

They shouldn't need to know where "they" are executing or that the resources on which they rely may not be local.

"Advanced developers" attend to the dynamic reconfiguration of the system (at runtime). So, THOSE developers build applications that are given the ability ("capability") to relocate resources, kill off tasks, spawn new ones, etc. Because they, presumably, have a more detailed understanding of the "System" beyond the scope of some particular application/task within it.

I support a heterogeneous environment; an object can be migrated to a different processor *family* at any time (while executing). You shouldn't care as long as the interface (methods) to the object remain available (for the capabilities you have been granted) along with the current state of the object.

Similarly, the algorithms used to implement those methods (as well as internal data members) can change dynamically -- as long as the interface functionality remains immutable.

For example, I create namespaces -- (name, capability) dictionaries -- for each process. If you only need a few registered names (stdin, stdout, stderr), the code that implements that is entirely different than the implementation that tries to manage hundreds of named entries.

As it should be. (because "you" are "billed" for the resources that you use, you'd not want to bear the cost of an implementation that did more than you needed -- just like you wouldn't develop a standalone device with more complexity/cost than necessary!)

If names are insignificant (e.g., akin to file descriptors), then an implementation might use a single "char" to represent a name, giving you access to ~200+ unique names of the form "a", "b", "^X", "\b", etc. Or, treat that char as an 8 bit int -- 0x01, 0x02, 0x61, 0x62, ... (do you really *need* names like "Object 1", "Object 2", etc.?)

"Yield" is just a hint to the scheduler. If you have a preemptive implementation where "time" can be a preemption criteria, then a task need never "suggest" a good place to relinquish the processor.

OTOH, if you can only preempt when the task invokes an OS primitive, then you have to be wary of a developer spinning without ever giving the system a chance to "interrupt".

Of course. But, with VMM, you can do so much more:

- CoW semantics

- DSM

- remapping "defective" memory

- releasing memory that will NEVER be revisited

- universal call by value (for large arguments) etc. None of these things need impact the developer.

But you have to guard against "non-cooperative" (and even HOSTILE!) actors who may wish to compromise performance by monopolizing resources (of which the CPU is but one).

Using resource ledgers lets you constrain an application (process) to a subset of the available resources. Putting runtime constraints on memory, time, etc. lets you remove a "bad actor" from the set of processes eligible to run. A persistent store lets you remember this decision so you don't "readmit" the process at some future date!

Capabilities implicitly limit the actions that can be performed (i.e., methods that can be invoked) on an object. E.g., I can let you LOCK a door but never UNLOCK it. Or, let you open a door EXACTLY once, and never again!

How you refine your "permissions" is something that belongs in the objects themselves -- not layered onto a "filesystem" as an afterthought.

Yikes. All that makes me glad to be a simple circuit designer.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Hey, thanks for writing. Since all we know about each other are these brief exchanges, filling in some detail helps a lot to understand, or rather, get an idea, of an estimate of the depth of the comprehension of the whole machine stack.

The idea of a kernel or operating system (executive, scheduler, ..., interactive "operating system") for "commodity" architectures these days is that it's pretty ubiquitous the various chips' architectures, then that PCIe is on everything PC, then about usually enough USB, then about the NIC and USB root, those are pretty much ubiquitously PCIe devices, or as after UEFI and ACPI and the SMI or as about DeviceTree, ..., it's ubiquitous, after "economy of scale" a simple enough "economy of ubiquity".

So, the chips are almost all 64-bit their native word width, though agreeably sometimes it's 128, and they have various vector or SIMD instructions, then as with regards to fitting two operands in a word, the SWAR approach, about vectorizing the scalars, and word and double-word and word and half-word.

Then, here mostly the consideration is the "head-less" or "HID-less", there's no human interface device involved in server runtime images for things like running services or usually enough "boxes" or "nodes".

Then, for compiling existing sources, it seems the easiest way to do that is to implement profiles of POSIX, or posix base and pthreads. That then of course is much the traditional UNIX account of where "everything is a file", though, the operating system itself doesn't need to be implemented that way, just surface the usual objects as they are as primitives, and mostly as having file handles. (If the sources compile and run the same behavior some won't know/care.)

Then, objects, according to "naming and directory interface" usually enough, Orange Book for example defines granular access controls, so, including all things like files.

About quota and limits and the like, and about the perceived value of pre-emptive scheduling to avoid "hogging", or thrashing, here is an account of basically unmaskable uncatchable interrupts that have as a signal handler the operating system code on the core that results making the task yield, then necessarily enough using the usually context-switch machinery to pause it and restart it. Most code eventually touches system calls, and if there's a spare core it might actually be the idea to let the compute-intensive routine employ the entire core.

The many-core architectures of these days, even fifteen or twenty years ago with "AMD Bulldozer and 8 cores" and the like, these days usual PC or server chips have scores of cores, ..., often for example with the idea of running a giant hypervisor then as many virts, ..., like a Kubernetes cluster for example, ..., or simply a ton of virts, ..., these days a single board is as a model of a distributed system internal to itself.

The idea for allocation and sharing that "fairness is a matter of mechanism, not policy", is for the usual ideas of "thoughput" and "transput" as Finkel put it in "An Operating Systems Vade Mecum", about I/O and queues, and limits.

"Interrupts" are the events, "coherent cache lines" the units of serialization of memory, DMA is the bulk transfer medium in protocol, a byte is the smallest addressable memory unit, these are mostly the ordering guarantees, all else "undefined".

Proximity, affinity, coherency, mobility, ....

We build electronics. Our new PoE instrument line uses an RP2040 dual-ARM chip overclocked to 150 MHz. It costs 75 cents in any quantity.

We call the two CPUs (and the two ends of the box) Alice and Bob.

Alice does the ethernet and usb i/o, command parsing, calibrations, all that slow floating-point management. Bob does the realtime i/o, fixed-point, directly or through an FPGA.

All programmed in bare-metal c with no OS. Abstraction=0.

Seems to work.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Perhaps you should relate the types of applications you've been tasked with in the past -- or, those you hope to target in the future. Frankly, your comments read like word-salad -- failing to appreciate or interact with my prior comments and, instead, babbling bits and pieces you've read somewhere instead of reflecting a genuine understanding of the issue(s).

E.g., there's no *why* behind your statements. No "hope" in their proposals.

Experience provides both of these and, without it, future endeavours tend to fail -- miserably. (if you don't learn...)

Heh. Let's say I've worked in distributed systems for a few decades.

Here's how I'd begin to frame it. Let's say we all know "Turing tapes" from the theory. Everybody knows a mental model of a tape, with discrete differences in it or values with ordinal offsets, a tape and read-head and a write-head, the the idea that that's a "model of computation". That's pretty obvious to anybody, and everybody knows that in "the formal" that all kinds of results are said to follow from it, while at the same time, nobody thinks that way because it's just cumbersome or not particularly apt. Everybody has known that since they have one at the beach, a great computer, it's a giant scratch-pad and any way one cares to mark it with stick-marks and pebbles, and rules, is just as good a model of computation. Now, say we've all heard of "Towers of Hanoi" and otherwise, for example, how a stack machine is "equivalent" or "equi-interpretable" to other "models of computation", point being that results in one are the same results eventually as the other.

Then, say we've all heard of something like Knuth's "Mix", an abstract of a virtual machine.

So, today we all know about, for example, the instruction pointer and the stack pointer, so "von Neumann", then according to the architecture the "instruction set architecture", that there's mostly a model of synchronous routine, then though as with regards to "interrupt service routine", a model of asynchrony in the synchronous ("blocking").

Then, also we know about that basically since when DMA direct memory access made for vector or scatter/gather I/O, that instead of a model of asynchrony in the synchronous, now it's a model of synchrony in the asynchronous ("non-blocking"), sort of like any other distributed system.

So, what inspires my outline is that the model of computation, here "actors on the bus", should more than less be the model of computation, then that formal statements about it, directly apply, to the implementation.

So, that's "why".

Mostly I thought of these things myself, because nobody already bothered to point out that de facto the commodity hardware is best treated as a model of a self-contained distributed system.

(In case you're wondering then also my approach to Mathematics and Physics in Foundations has been called "Word Salad", though I prefer to think of it as a nutritious enough "Word Soup", after "Alphabet Soup", which is full of letters even if you'd rather toss it than bother to make words in the spoon, i.e., I'll aver that it's coming from and going to a good place, then those rambles or "the bot panel" from the "Critix/DeepOs" help provide some context.)

I don't disagree with your previous comments, I understand from "generous reading" that accounts of reliability and robustness and flexibility and function and so on are usual, and sensible.

"Equilibrium is always both at equilibrium and seeking equilibrium."

That seems cool. So, you wrote your own USB and packet stack? Or, it's a system-on-chip?

I drive my tractor with my hands on the wheels and the sticks and the levers and the other levers and the feet on the pedals and the other pedals and my rear in the seat, ..., abstraction = 0.

Attitudes are various about "abstraction" and "concreteness". (Attitudes or "opinions".) Some prefer to write more or less directly to the concrete adapter, others prefer to model the interaction since usually only a tiny, tiny subset of the "defined behavior" of the concrete adapter fulfills its abstract function.

It takes all kinds, ....

"The Blind Men and the Elephant" is a usual sort of account, and it's the same kind of idea since forever that any two individuals are going to see things differently, and a question whether they even see the same thing at all, "subjectivity", then there's the great formal and practical account of the formal or "interfaces" usually enough, interfaces to the adapters, "inter-subjectivity", so when we clock out we can say it's done.

When I see someone writing to directly to the concrete adapter, sometimes it's hard to distinguish that or easy to read that as from, "Hello, World".

Then, "layers" is usually enough the idea of making models of modules, in layers, then that the boundaries exist, then for example that the code its logic is "separable and composable", then to point it at other adapters their interfaces or harnesses, for example for "systems under test" vis-a-vis "systems under load".

I'm not a mechanic yet the metaphor about the tractor for example is about compression test. If the engine's misfiring or burning oil or something, then a usual enough idea is to remove one of the spark plugs and attach a compression tester and turn over the starter motor and and measure the compression and perhaps vacuum and compare it to a table from the manufacturer to diagnose what's going on. So, that's an abstraction, all the activity that goes into maintenance for operation is essentially abstraction.

Or, you know, according to instruction.

Exercises then in "abstraction and concreteness", are totally usual, and figuring them out is for example for the difference between writing logic and writing libraries, one for concreteness the other abstraction.

It goes both ways, ..., it takes all kinds.

(I am definitely a software engineer and have written many, many KLOCs in prod and under continuous test. Or, as my desk neighbor once told me, she said, "your code is solid". So, I'm familiar with distributed systems on the order of orders and events.)

We use the WizNet ethernet chip and the code that they supply. It's more than a mac/phy: it handles packets and protocols, including UDP.

The RP2040 has a built-in USB interface. The electrical interface to the USBc connector is two resistors. It looks like a COM port to the users. What's really slick is that the USB can also run in a mode where it looks like a memory stick. To reload the systrem code, we boot into memory stick mode and the user then drag-drops a single file to update the box: Alice code, Bob code, and the FPGA config.

Tractors are cool. Physical and basic.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Trying to figure out "commodity" computing above "embedded" computing, and to be able to explain it and thusly give an outline, an abstraction itself, of the connections and the circuits, has that these days at least for "commodity" general purpose computing, there's a great "economy of ubiquity" so that whence there's a model of the bus as almost always PCIe, then about clock signals and clock drivers and clock interrupts, about power management and power states, about variously the ideas, here they're mostly ideas first as I'm not that great of a computer engineer, about differential pair lines and the other serial protocols usually enough, then about SATA mostly, is then mostly about PCIe and DMA and then a miniature fleet of cores, these being themselves often single or "hyper" threaded, it's not moving that fast the platform, to basically make for it a model of computation as it embodies itself.

Here's a bit of a podcast, 44:35 - 49:55 sort of talks about these things, there are others. "Reading Foundations: denser tensors".

This discussion drifted into operating systems, or schedulers as they may be or executives plainly, in the context of the software more generally there's much to be made of "logic extraction", since, pretty much all sorts of source code pretty much lives in a world of types and among models of computation, and so, according to the shape in the logic, there's much to be made of flexible or "polyglot" parsers, basically into representations of state and scope, and for example into making natural diagrams of the flow-graph, this is just "modern tooling to make sense of complexity", instead of "ignore the man behind the curtain in the booming voice of Oz".

Absolutely.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

Dang, they promised us rain this week. Didn't get any.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

The line of clouds crosses the California coast about 50 miles south of San Francisco. The SF Bay area shows mostly clear skys, while to the south, the missing rain clouds are moving inland:

Baloney. ECMMF AI data has been available since July 2025 in the form of AIFS (Artificial Intelligence Forecasting System).

At this time, the crown jewels of AI startups are the details on how they generate their predictions. In other words, their source code and system architecture. They're not about to give that away for free and certainly not without an NDA. There are probably some open source AI initiatives which might include AI weather prediction models. Try your luck:

Do you really need to know how an internal combustion engine works in order to operate the vehicle?

They just need bigger computers.

John Larkin Highland Tech Glen Canyon Design Center Lunatic Fringe Electronics

They also want all the CPU's, memory, video cards, cooling water, electrical power, government support and investors on the planet. If they can't get these, they threaten to put the data centers in orbit. All this to obtain better weather forecasts. Meanwhile, I can do as well with my Ouija board and weather rock:

They can't much get _bigger_ computers, only _more_ computers.

"Why do they hire economists?" "To make the weather man look good."

windy.com is very good here. And local weather radar: