I built this first as a 32-bit binary, and there was noise that I had to cut with a substr function.

In the rebuilding with my MinGW 64-bit Windows cross compiler on Oracle Linux, I had to mine function prototypes out of all the code for exactly this reason.

'for those unaware: c89 has a cool "feature" where, if you try to call a function which doesn't exist, rather than erroring out, the function is implicitly declared as a function with unspecified parameters returning int.'

I'm not testing this, because that is agony.

I'm leaving them a working build, and retiring this month.

This code was written by the living and the dead, and my stewardship is finished. I do not envy the poor soul who must test this.

It was ashes when I excavated it myself. A hat tip to those who have gone before.

https://en.wikipedia.org/wiki/UNIVAC_1100/2200_series

The 1108-II was the first SMP dual processor architecture that was sold commercially, announced in 1965.

The operating system launched on the 1107 is now known as OS 2200, and is still supported.

https://en.wikipedia.org/wiki/OS_2200

United Airlines remains a major customer for the UNIVAC architecture.

The first SMP Unix implementation was on UNIVAC hardware, and used the EXEC-8 kernel from OS2200 directly, implementing a Unix system call as a "shim" around it.

https://www.nokia.com/bell-labs/about/dennis-m-ritchie/other...

"The UNIX system for the UNIVAC 1100 series was built as an integrated development environment for transactions that run directly on EXEC. Unlike most other implementations, therefore, it runs not directly on the hardware but as a collection of user-level activities under control of EXEC. These obtain services that would normally be provided by device drivers, and some process creation and management services from EXEC. Any configuration supplied by Sperry, including multiprocessor ones, can run the UNIX system."

This was possible because their economic planning is centralized.

They all can refine it, but the more technically adept refineries that specialize in processing heavy, sulfur-soured crude do not run efficiently with lighter grades.

https://www.forbes.com/sites/rrapier/2026/04/05/debunking-a-...

It also has its own domestic oil production of 4.3 million barrels per day.

"Meanwhile, the engineering team's predictions about the relentless march of CMOS proved true. By 1991, the NVAX was also on the market, offering roughly the same performance for a tiny fraction of the cost and size. At lower performance settings the same design was available in desktop form, outperforming all previous VAX machines. The 9000 managed not only to lose billions of dollars, but also led to the ending of several much more promising designs."

https://en.wikipedia.org/wiki/VAX_9000

DEC also lost Dave Cutler's team over PRISM, which was also a deep cut. Deeper than the ECL disaster? Debatable.

DEC had no hope in the ECL money furnace and the loss of the VMS architect.

I'm also assuming that ARM code density was better than Alpha (conditional opcodes being a major contributor).

"Well, we were looking at doing a low power Alpha and decided that just couldn’t be done, and then looked at the ARM. We think we can make an ARM which is really low power, really high performance, really tiny, and cheap, and we can do it in a year...

"Well, I worked on the StrongARM 1500, which was a very interesting product. It was an ARM and a DSP kind of highly combined... And then we finished that project and our group in Palo Alto, we were just gonna start an Alpha project."

https://archive.computerhistory.org/resources/access/text/20...

"According to Allen Baum, the StrongARM traces its history to attempts to make a low-power version of the DEC Alpha, which DEC's engineers quickly concluded was not possible."

https://en.wikipedia.org/wiki/StrongARM

While AArch64 has been in the top supercomputer, a phone running on Alpha was not.

For this scalability problem, it deserved to die.

This may change, obviously. Likely for the worse.

How can I escape an imminent oil shock?

Question 2:

How can I escape an AI bubble demonstrated by CAPE?

I'm using Claude, and I'm good so far.

Comments URL: https://news.ycombinator.com/item?id=49102879

Points: 14

# Comments: 2

"Transactions involving multiple attached databases are atomic, assuming that the main database is not ":memory:" and the journal_mode is not WAL. If the main database is ":memory:" or if the journal_mode is WAL, then transactions continue to be atomic within each individual database file. But if the host computer crashes in the middle of a COMMIT where two or more database files are updated, some of those files might get the changes where others might not."

https://sqlite.org/lang_attach.html

I'd actually love to have the Holo keyboard back. That was my favorite.

https://se-legal.de/services/criminal-defense-lawyer/self-de...

That is diametrically opposed to their interests in data collection.

The recent Darksword exploit should give everyone pause in asserting that iOS is secure:

https://www.malwarebytes.com/blog/mobile/2026/03/a-darksword...

I trust iOS with my banking and financial apps in a way that I would never trust Google, but I am under no illusion that any architecture can be completely secure.

On the Linux side, I have found SELinux maddening at times in forcing me to the syslog to enable and permit what I need the machine to do.

I have never seen anything this obstreperous in a BSD, but perhaps I have not looked with sufficient depth.

In any case, the Trust / SELinux / Enforcing status is a sizable advantage against iOS.

So the nanostructures allow a maximum size of hydrates.

How is this flushed after collection? What impels the captured molecules out of their recesses?

No, because I am retiring next month!