On 03/30/2026 07:44 AM, john larkin wrote:
On Sun, 29 Mar 2026 20:54:28 -0700, Ross Finlayson
<ross.a.finlayson@gmail.com> wrote:
On 03/29/2026 03:24 PM, john larkin wrote:
On Sun, 29 Mar 2026 14:29:32 -0700, Ross Finlayson
<ross.a.finlayson@gmail.com> wrote:
On 03/29/2026 12:39 PM, Don Y wrote:
On 3/29/2026 5:53 AM, Ross Finlayson wrote:
That seems to speak to "proximity" and "affinity", with regards
to "coherency", and "mobility". To "move" state, about state & scope >>>>>>> or the contents of (some of) memory and registers, of a process or task,
here is described as "re-seating" which is also the usual enough >>>>>>> idea in programming like C and C++.
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.
Perhaps the most usual example is pre-emptive multithreading itself, >>>>>>> about basically the state as a stack, and "process control block" >>>>>>> and "thread control block" usually enough, about context-switching. >>>>>>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.?)
In this "Critix" concept, or "DeepOs" (or "BeepOs/DeepOs"),
the idea of the "re-routine" as a model of asychronous concurrency, >>>>>>> is a little different than the usual idea of a co-routine, which >>>>>>> is usually enough a fork in the process model, then about signals >>>>>>> as IPC with PID and PPID, vis-a-vis, fibers and threads or events >>>>>>> and task queues, basically the re-routine never "blocks" and has >>>>>>> no "yield" nor "async" keywords in the source text, instead any
call to a re-routine implicitly yields, and then the re-routine
is run again later, the re-run, where as the re-routine is filled in, >>>>>>> then then the re-routine adds a penalty of basically n^2 in time >>>>>>> to be completely non-blocking and where asynchrony is modeled in >>>>>>> the language as the normal procedural flow-of-control.
"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".
Then, as that's only in the kernel itself, that n^2 might seem a >>>>>>> huge penalty, yet, it's actually quite under that, since as the
re-routine its data (in a stack) is filled in, then most of its
routine is cache hits, the "memoized" calls to the re-routine.
About the allocator, then this design concept basically is for
making use of virtual memory, to be able to "re-seat" the memory >>>>>>> of a process without changing a process' view of the memory.
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.
This can help avoid both syscalls and memory fragmentation,
since memory paging basically is performed by the user-space
process in its time instead of by the kernel. This has the
usual guarantees of process memory that it's to be visible only
to the process itself unless explicitly shared, that then being
treated as a usual sort of shared resource in the distributed sense. >>>>>>>
The syscalls by a process essentially yield (the process yields
to the scheduler), about ideas like round-robin and fairness
and anti-starvation and incremental-progress in the scheduler,
while it's so that until a process gets any other signal and
only touches its own memory that's non-yielding, then about
the machinery of pre-emptive multithreading or context-switch
and as with regards to hyper-threading or the interleaved contexts >>>>>>> on the double-pipeline CPUs, the idea being that context-switching >>>>>>> is along the lines of basically a periodic signal interrupt.
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! >>>>>>
Notions of "Orange Book" and "mandatory access control" then
are considered "more than good ideas" with regards to the allocator >>>>>>> and scheduler of resources in computation.
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.
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
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.
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".
ECMMWF has access to an AI weather forecaster that they refuse to use beyond in-house study. They continue their conventional weather forecasting operations as usual without it.
This is unlike many other applications, where people use AI without a clue as to how the AI is arriving at its results.
On Mon, 30 Mar 2026 23:30:01 +0000, someone ><cffbf4deb9142bce48974efc0e64dede@example.com> wrote:
ECMMWF has access to an AI weather forecaster that they refuse to use beyond in-house study. They continue their conventional weather forecasting operations as usual without it.
This is unlike many other applications, where people use AI without a clue as to how the AI is arriving at its results.
Dang, they promised us rain this week. Didn't get any.
ECMMWF has access to an AI weather forecaster that they refuse to use beyond in-house study. They continue their conventional weather forecasting operations as usual without it.
This is unlike many other applications, where people use AI without a clue as to how the AI is arriving at its results.
On Tue, 31 Mar 2026 11:01:41 -0700, john larkin <jl@glen--canyon.com>
wrote:
On Mon, 30 Mar 2026 23:30:01 +0000, someone >><cffbf4deb9142bce48974efc0e64dede@example.com> wrote:
ECMMWF has access to an AI weather forecaster that they refuse to use beyond in-house study. They continue their conventional weather forecasting operations as usual without it.
This is unlike many other applications, where people use AI without a clue as to how the AI is arriving at its results.
Dang, they promised us rain this week. Didn't get any.
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: ><https://www.windy.com/-Satellite-satellite?satellite,36.831,-117.809,6> ><https://www.windy.com/-Menu/menu?rain,36.831,-117.809,6>
In Ben Lomond, I'm under the clouds and seeing only a little rain,
which barely registers on my rain gauge. The forecast is more of the
same through Weds evening. Sorry.
On Tue, 31 Mar 2026 13:54:57 -0700, Jeff Liebermann <jeffl@cruzio.com>
wrote:
On Tue, 31 Mar 2026 11:01:41 -0700, john larkin <jl@glen--canyon.com> >>wrote:
On Mon, 30 Mar 2026 23:30:01 +0000, someone >>><cffbf4deb9142bce48974efc0e64dede@example.com> wrote:
ECMMWF has access to an AI weather forecaster that they refuse to use beyond in-house study. They continue their conventional weather forecasting operations as usual without it.
This is unlike many other applications, where people use AI without a clue as to how the AI is arriving at its results.
Dang, they promised us rain this week. Didn't get any.
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: >><https://www.windy.com/-Satellite-satellite?satellite,36.831,-117.809,6> >><https://www.windy.com/-Menu/menu?rain,36.831,-117.809,6>
In Ben Lomond, I'm under the clouds and seeing only a little rain,
which barely registers on my rain gauge. The forecast is more of the
same through Weds evening. Sorry.
They just need bigger computers.
John Larkin--
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
On Tue, 31 Mar 2026 15:06:33 -0700, john larkin <jl@glen--canyon.com>
wrote:
On Tue, 31 Mar 2026 13:54:57 -0700, Jeff Liebermann <jeffl@cruzio.com>
wrote:
On Tue, 31 Mar 2026 11:01:41 -0700, john larkin <jl@glen--canyon.com>
wrote:
On Mon, 30 Mar 2026 23:30:01 +0000, someone
<cffbf4deb9142bce48974efc0e64dede@example.com> wrote:
ECMMWF has access to an AI weather forecaster that they refuse to use beyond in-house study. They continue their conventional weather forecasting operations as usual without it.
This is unlike many other applications, where people use AI without a clue as to how the AI is arriving at its results.
Dang, they promised us rain this week. Didn't get any.
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:
<https://www.windy.com/-Satellite-satellite?satellite,36.831,-117.809,6> >>> <https://www.windy.com/-Menu/menu?rain,36.831,-117.809,6>
In Ben Lomond, I'm under the clouds and seeing only a little rain,
which barely registers on my rain gauge. The forecast is more of the
same through Weds evening. Sorry.
They just need bigger computers.
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: <https://www.google.com/search?udm=2&q=ouija%20board> <https://www.google.com/search?q=weather%20rock&udm=2>
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
Jeff Liebermann <jeffl@cruzio.com>wrote:
On Tue, 31 Mar 2026 15:06:33 -0700, john larkin <jl@glen--canyon.com>wrote:
On Tue, 31 Mar 2026 13:54:57 -0700, Jeff Liebermann <jeffl@cruzio.com> >>wrote:
On Tue, 31 Mar 2026 11:01:41 -0700, john larkin <jl@glen--canyon.com> >>>wrote:
On Mon, 30 Mar 2026 23:30:01 +0000, someone >>>><cffbf4deb9142bce48974efc0e64dede@example.com> wrote:
ECMMWF has access to an AI weather forecaster that they refuse to use beyond in-house study. They continue their
conventional weather forecasting operations as usual without it.
This is unlike many other applications, where people use AI without a clue as to how the AI is arriving at its results.
Dang, they promised us rain this week. Didn't get any.
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: >>><https://www.windy.com/-Satellite-satellite?satellite,36.831,-117.809,6> >>><https://www.windy.com/-Menu/menu?rain,36.831,-117.809,6>
In Ben Lomond, I'm under the clouds and seeing only a little rain,
which barely registers on my rain gauge. The forecast is more of the >>>same through Weds evening. Sorry.
They just need bigger computers.
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: ><https://www.google.com/search?udm=2&q=ouija%20board> ><https://www.google.com/search?q=weather%20rock&udm=2>
Jeff Liebermann <jeffl@cruzio.com>wrote:
On Mon, 30 Mar 2026 23:30:01 +0000, someone ><cffbf4deb9142bce48974efc0e64dede@example.com> wrote:
ECMMWF has access to an AI weather forecaster that they refuse to use beyond in-house study. They continue their conventional
weather forecasting operations as usual without it.
Baloney. ECMMF AI data has been available since July 2025 in the form
of AIFS (Artificial Intelligence Forecasting System). ><https://www.ecmwf.int/en/forecasts/dataset/aifs-machine-learning-data> ><https://www.ecmwf.int/en/forecasts/datasets/open-data>
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: ><https://en.wikipedia.org/wiki/Open-source_artificial_intelligence>
This is unlike many other applications, where people use AI without a clue as to how the AI is arriving at its results.
Do you really need to know how an internal combustion engine works in
order to operate the vehicle?
Jeff Liebermann <jeffl@cruzio.com>wrote:
On Tue, 31 Mar 2026 15:06:33 -0700, john larkin <jl@glen--canyon.com> >>wrote:
On Tue, 31 Mar 2026 13:54:57 -0700, Jeff Liebermann <jeffl@cruzio.com> >>>wrote:
On Tue, 31 Mar 2026 11:01:41 -0700, john larkin <jl@glen--canyon.com> >>>>wrote:
On Mon, 30 Mar 2026 23:30:01 +0000, someone >>>>><cffbf4deb9142bce48974efc0e64dede@example.com> wrote:
ECMMWF has access to an AI weather forecaster that they refuse to use beyond in-house study. They continue their
conventional weather forecasting operations as usual without it.
This is unlike many other applications, where people use AI without a clue as to how the AI is arriving at its results.
Dang, they promised us rain this week. Didn't get any.
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: >>>><https://www.windy.com/-Satellite-satellite?satellite,36.831,-117.809,6> >>>><https://www.windy.com/-Menu/menu?rain,36.831,-117.809,6>
In Ben Lomond, I'm under the clouds and seeing only a little rain, >>>>which barely registers on my rain gauge. The forecast is more of the >>>>same through Weds evening. Sorry.
They just need bigger computers.
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: >><https://www.google.com/search?udm=2&q=ouija%20board> >><https://www.google.com/search?q=weather%20rock&udm=2>
windy.com is very good here.
And local weather radar:
https://www.knmi.nl/nederland-nu/weer/actueel-weer/neerslagradar
Jeff Liebermann <jeffl@cruzio.com>wrote:
On Mon, 30 Mar 2026 23:30:01 +0000, someone >><cffbf4deb9142bce48974efc0e64dede@example.com> wrote:
ECMMWF has access to an AI weather forecaster that they refuse to use beyond in-house study. They continue their conventional
weather forecasting operations as usual without it.
Baloney. ECMMF AI data has been available since July 2025 in the form
of AIFS (Artificial Intelligence Forecasting System). >><https://www.ecmwf.int/en/forecasts/dataset/aifs-machine-learning-data> >><https://www.ecmwf.int/en/forecasts/datasets/open-data>
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: >><https://en.wikipedia.org/wiki/Open-source_artificial_intelligence>
This is unlike many other applications, where people use AI without a clue as to how the AI is arriving at its results.
Do you really need to know how an internal combustion engine works in
order to operate the vehicle?
It may help a lot!
Same for motorbikes etc..
On Wed, 01 Apr 2026 06:45:52 GMT, Jan Panteltje <alien@comet.invalid>
wrote:
Jeff Liebermann <jeffl@cruzio.com>wrote:
On Mon, 30 Mar 2026 23:30:01 +0000, someone<cffbf4deb9142bce48974efc0e64dede@example.com> wrote:
ECMMWF has access to an AI weather forecaster that they refuse to use beyond in-house study. They continue their conventional
weather forecasting operations as usual without it.
Baloney. ECMMF AI data has been available since July 2025 in the form
of AIFS (Artificial Intelligence Forecasting System).
<https://www.ecmwf.int/en/forecasts/dataset/aifs-machine-learning-data>
<https://www.ecmwf.int/en/forecasts/datasets/open-data>
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:
<https://en.wikipedia.org/wiki/Open-source_artificial_intelligence>
This is unlike many other applications, where people use AI without a clue as to how the AI is arriving at its results.
Do you really need to know how an internal combustion engine works in
order to operate the vehicle?
It may help a lot!
Same for motorbikes etc..
Oddly, driver training schools don't include much on how internal
combustion engines function. Most of the training is on how to
operate the vehicle with maybe a few maintenance hints (put air in the
tires, check the oil, keep the windows clean, etc). Some of my
friends struggle with opening the door when they forget their wireless
key fob at home. Judging by appearances, driving to the supermarket
and back, without hitting anything, is a major accomplishment that can
be achieved without knowing how the engine works.
It's the same with AI weather forecasting. Members of the GUM (great unwashed masses) do not need to know how an AI is used to produce a
weather forecast. To them, the process might involve a weather rock: <https://www.google.com/search?udm=2&q=weather%20rock>
or Ouija board:
<https://www.google.com/search?q=ouija%20board&udm=2>
and they would accept the results. Hopefully, they would also know
what to do about the results and be able to decode the forecast terms.
How many of these do you know?
<https://www.weather.gov/bgm/forecast_terms>
Knowing how sausage and weather forecasts are made does not make
either more digestible.
Incidentally, while attending college in the 1960's, I worked part
time as an auto mechanic (floor sweeper) at a Ford dealer. I met
quite a few drivers. I noticed that the stunt and race car drivers
were terrible at maintaining their vehicles, while the mechanically
inclined did well on maintenance, but were not very good drivers. I
guess that also applies to electronic design. There are those that
can design, but can't operate their designs and those who can do
amazing things with the final product, but couldn't design anything
that actually worked or could be manufactured. Similarly, computer programmers should not attempt to operate a screwdriver.
Oddly, driver training schools don't include much on how internal
combustion engines function. Most of the training is on how to
operate the vehicle with maybe a few maintenance hints (put air in the
tires, check the oil, keep the windows clean, etc). Some of my
friends struggle with opening the door when they forget their wireless
key fob at home. Judging by appearances, driving to the supermarket
and back, without hitting anything, is a major accomplishment that can
be achieved without knowing how the engine works.
It's the same with AI weather forecasting. Members of the GUM (great unwashed masses) do not need to know how an AI is used to produce a
weather forecast. To them, the process might involve a weather rock: <https://www.google.com/search?udm=2&q=weather%20rock>
or Ouija board:
<https://www.google.com/search?q=ouija%20board&udm=2>
and they would accept the results. Hopefully, they would also know
what to do about the results and be able to decode the forecast terms.
How many of these do you know?
<https://www.weather.gov/bgm/forecast_terms>
Knowing how sausage and weather forecasts are made does not make
either more digestible.
Incidentally, while attending college in the 1960's, I worked part
time as an auto mechanic (floor sweeper) at a Ford dealer. I met
quite a few drivers. I noticed that the stunt and race car drivers
were terrible at maintaining their vehicles, while the mechanically
inclined did well on maintenance, but were not very good drivers. I
guess that also applies to electronic design. There are those that
can design, but can't operate their designs and those who can do
amazing things with the final product, but couldn't design anything
that actually worked or could be manufactured. Similarly, computer programmers should not attempt to operate a screwdriver.
On Wed, 01 Apr 2026 06:41:06 GMT, Jan Panteltje <alien@comet.invalid>
wrote:
Jeff Liebermann <jeffl@cruzio.com>wrote:
On Tue, 31 Mar 2026 15:06:33 -0700, john larkin <jl@glen--canyon.com> >>>wrote:
On Tue, 31 Mar 2026 13:54:57 -0700, Jeff Liebermann <jeffl@cruzio.com> >>>>wrote:
On Tue, 31 Mar 2026 11:01:41 -0700, john larkin <jl@glen--canyon.com> >>>>>wrote:
On Mon, 30 Mar 2026 23:30:01 +0000, someone >>>>>><cffbf4deb9142bce48974efc0e64dede@example.com> wrote:
ECMMWF has access to an AI weather forecaster that they refuse to use beyond in-house study. They continue their
conventional weather forecasting operations as usual without it.
This is unlike many other applications, where people use AI without a clue as to how the AI is arriving at its results.
Dang, they promised us rain this week. Didn't get any.
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: >>>>><https://www.windy.com/-Satellite-satellite?satellite,36.831,-117.809,6> >>>>><https://www.windy.com/-Menu/menu?rain,36.831,-117.809,6>
In Ben Lomond, I'm under the clouds and seeing only a little rain, >>>>>which barely registers on my rain gauge. The forecast is more of the >>>>>same through Weds evening. Sorry.
They just need bigger computers.
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: >>><https://www.google.com/search?udm=2&q=ouija%20board> >>><https://www.google.com/search?q=weather%20rock&udm=2>
windy.com is very good here.
And local weather radar:
https://www.knmi.nl/nederland-nu/weer/actueel-weer/neerslagradar
Windy is very similar to https://www.ventusky.com. V has nice visuals
but the forecasts are petty bad.
John Larkin
Highland Tech Glen Canyon Design Center
Lunatic Fringe Electronics
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 63 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 493001:38:15 |
| Calls: | 840 |
| Files: | 1,302 |
| D/L today: |
9 files (7,185K bytes) |
| Messages: | 267,829 |