"they can read my email, take my money, and impersonate me to my friends, but at least they can't install drivers without my permission"

   https://xkcd.com/1200/

Americium is not a good atomic clock material---it doesn't have superior electronic transitions, and the nuclear transitions causing its radioactivity would get in the way.

Nuclear oscillations could also be used: there is a proposal to use a low-energy nuclear oscillation in Thorium; it would be more stable than electronic oscillations: https://en.wikipedia.org/wiki/Nuclear_clock

The distinction of what can or cannot be called 'radioactive' is somehow artificial: masers, atoms and nuclei all emit radiation, so they all are technically 'radioactive'. Conventionally, 'radioactive' radiation requires energies that cause ionization of common materials, usually quoted as above 10eV. The Thorium nuclear transition is actually below that, so technically it is not radioactive---but I'd still not want to sit next to such clock without some shielding, because even UV radiation with energies above 3eV is known to damage living tissue.

   Site preparation began in February, 2024;[12] the prefabricated restroom was placed by a crane in March;[2] and installation was completed on April 22, 2024, costing about $200,000 to the city.

Don't get me wrong, I am excited about solar power but careful about the economics: the capital cost of solar right now is well over 1$/W (panels+inverters+installation/hookup) and even though it is falling nicely, the amortization schedule needs to be considered. A rule-of-thumb figure is 1kWh of power per year from 1W nominal installed, so the capital cost will have to be amortized over 100 years to reach $.01/kWh. The installed price has to come down by a factor of 10 for this to work out.

   $ sqlite :memory: 
   create table t (product,revenue, year);
   insert into t values ('a',10,2020),('b',14,2020),('c',24,2020),('a',20,2021),('b',24,2021),('c',34,2021);
   select product,sum(revenue) filter (where year=2020) as '2020',sum(revenue) filter (where year=2021) as '2021' from t group by product;

Unfortunately, they are often artificially differentiated by the style of the UX interaction: TUIs promote the keyboard actions, and GUIs prefer mouse without corresponding keyboard shortcuts. Unfortunately for GUIs, their designers are often so enamored with WIMP that they omit the keyboard shortcuts or make them awkward. I hate it when, even if the ACTION button is available by keyboard traversal at all, it requires some unknown number of widget traversals instead of being one tab away.

Since the keyboard is almost always used for the textual data, it makes sense to me to always enable it for command execution. Well designed GUIs and TUIs provide both WIMP and keyboard UX, which sadly is not the norm today, so here's my vote to make them larp for each other more.

I think LLMs will get better, as well.

   Any competent computer engineer can design a much better ISA than RISC-V.

Specifically, about detecting the overflow: the familiar, classic approach of a hardware overflow (V) flag is well known to be suboptimal, because of its effect on speculative and OoO implementations. RISC-V has enough primitives to handle an explicit overflow checking, and they are consistent with performance techniques such as branch prediction and macro fusing, to the point of having asymptotically vanishing cost--there can be no performance penalty. Even more so, the RISC-V code that does NOT care about overflow can completely ignore these checks.

My go-to analogy is assembly language programming: it used to be an essential skill, but now is essentially delegated to compilers outside of some limited specialized cases. I think LLMs will be seen as the compiler technology of the next wave of computing.

BTW, one side benefit of LP is freedom from arbitrary structure of DSLs. A standard practice in LP is to declare and define objects in the spot in which they are being used; LP tools will parse them out and distribute to the syntactically correct places.

gpg --gen-random --armor 1 20

or:

pwgen

The downside is that couldn't get it to segment for different speakers. The concensus seemed to be to use a separate tool.