chasil

Here is a good example where this is not so. Unfortunately, my datacenter runs this vulnerable VMS release on an emulated VAX.

https://www.theregister.com/on-prem/2018/02/06/ghost-in-the-...

First of all, did you disable the calculator? This app is an amazing feat of intellect, and should be retained due to its fundamental worth of ingenuity.

https://medium.com/@jnebos/the-humble-android-calculator-4f1...

Second, the kernel itself presents attack surfaces. It is important to accept updates, when they are offered.

How closely related is this CPU to SPARC?

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

"Based on the seminal Berkeley RISC, the 29k added a number of significant improvements... One design element used in some of the Berkeley RISC-derived designs is the concept of register windows, a technique used to speed up procedure calls significantly."

The wiki says:

"Additional XMM (SSE) registers: Similarly, the number of 128-bit XMM registers (used for Streaming SIMD instructions) is also increased from 8 to 16...

"The original AMD64 architecture adopted Intel's SSE and SSE2 as core instructions."

https://en.wikipedia.org/wiki/X86-64

This wansn't v2?

My production binary was built on Oracle Linux 5, with gcc 4.1.2.

I just rebuilt a core program that talks to my UNIVAC OS2200 CITA and my VAX ACMS from Linux.

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.

Today's surviving UNIVAC architecture originated in the first transistor-based machine, the 1107, which was not compatible with any of the previous designs that all used vacuum tubes. "Only 36 systems were sold."

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."

They were also able to drastically cut their own internal demand and external sales/shipments (the article mentions jet fuel to other Asian nations).

This was possible because their economic planning is centralized.

In researching this question, 40% of the refineries in the U.S. can process light crude efficiently.

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 might be said that this article casts China as a "super capacitor" in that it can store and release massive quantities of oil at will.

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

DEC also blew a fortune on the ECL VAX.

"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.

This interview with Allen Baum seems to imply that DEC was quite aware of what could easily be done with Alpha, and what could not.

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...

For everyone who says that the Alpha was a technically-superior CPU design that should have prevailed, I will draw attention to an interesting fact:

"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.

I realized some time ago that Oracle spelled backwards is "el caro," which (according to Google translate) means "the expensive one" in Spanish.

The apparent takeaway is that Apple devices on AT&T have reduced privacy.

This may change, obviously. Likely for the worse.

Question 1:

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.

Then WAL mode is not safe for you.

"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

Date and time are a deeper loss for me.

If I donate, can we get the Lineage keyboard with all the symbols in the same places?

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

This reference from Germany indicates that self-defense is lawful even if it ends the attacker's life, as long as the violence is not excessive for the situation.

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

Google is never going to put their administrative access in a restricted sandbox.

That is diametrically opposed to their interests in data collection.

I'm not sure that I agree that iOS devices have equal protection.

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.

It appears to me that the "water envelope" refers to chemical hydrates of water.

So the nanostructures allow a maximum size of hydrates.

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

Should I be worried that my plant is owned by Apollo?

No, because I am retiring next month!

I don't really have an oar in this water, but...

"Judge approves a $1.5B Anthropic settlement over pirated books used to train the Claude chatbot"

https://abcnews.com/Technology/wireStory/judge-approves-15b-...

I use:

  find . -name '*.log' -print0 | xargs -0 rm

For this simple example (derived from the article), find also has a delete operator.

This null termination is now a POSIX standard.

I have read elsewhere that spinning mercury would be used as the mirror.

If you find something that binds you inextricably with the global economy, then you have power.

Oil is not that thing.

The neon from Odessa and Mariopol was obviously not that thing.

The quartz from North Carolina appears to be an example of that thing. Not absolutely irreplaceable, but inconvenient in the extreme.

Is such a thing found in Iran? If so, that is an alternate path.

That can be people, instead of a raw material.

I have lived with this violence all of my life. I was a fresh teen in the Carter hostage crisis.

I know Eisenhower's role in starting it:

https://en.wikipedia.org/wiki/1953_Iranian_coup_d'%C3%A9tat

There is nothing better that could happen to Iran than to manufacture critical products of such value that global fear of their loss gives them a shield as well.

This is entirely within their capability.