BRB Updates

This week the BRB has been updated with better colors and better Settings control. Before that, the Paleo Bible now includes most names. Also, notes on design issues with the new large Sower and Reaper models. Finally, watch dates and a headline review.

Paleo Bible

I stopped working on the Paleo Bible a couple weeks ago. This was in part over frustration with the task. This was also in part so the 3d print farm could get a work queue that could run while continuing to work Paleo Bible problems.

My personal prophetic keeps shifting between Paleo Bible and 3d work. Some mornings I wake up and know how to handle Paleo Bible problems, some mornings I know how to handle 3d problems. Life is crazy. So I need to keep moving between these projects.

The immediate problem with the Paleo Bible was I had 511 names sitting in a temporary file that needed to get loaded into the lexicon. I needed to do this while it was still a fresh problem.

Because of trouble with the 3d side of the project, details below, I went back and wrote the final bits of code to prepare those names for loading. Basically, one-off code was written to find the list of cites for those otherwise known names, and format them, so they were ready for loading.

That code work went pretty well, and the Paleo Bible is updated again this week. The link above is to the app itself.

Rare Names

These names are generally low frequency names, like names from some of the genealogies from Chronicles and Ezra. These final names also include a few more names from the New Testament.

Big data problems like this usually need to have integrity checks built into the code that manages the data. I added more checks to the lexicon to monitor for duplicates and for entries that are both names and technical words.

Duplicate names were an artifact of finding the names. It was easy enough to fix. Those duplicates were combined into single entries.

There still remains around 40 words that are both names and technical terms. That list should grow as the remaining technical terms get loaded.

These cases will need new code to use cite data to distinguish how to tell what English should be used. The final lexicon entries will show both forms. (Dove vs. Greek, for example, will show in the Lexicon.)

Coverage

In terms of lexicon coverage, there are now 2,523 roots in the lexicon. There are 14,040 different forms for those roots. There remains 37,123 different unique inbound word forms that must still be explained by the lexicon.

In terms of manuscript coverage, there are now 553,332 words, so 79.27 percent of the paleo text, that has at least some English. There are 144,684 words, so 20.73 percent, that do not have English. There are currently 698,016 words total in the text. The total keeps growing because lexicon entries split off prefix words, which then add to the overall count.

The gap that still needs to be closed are those 37,123 unique word forms that still need to be explained by lexicon entries. Those forms will cover 144,684 inbound words. So each remaining form will only explain about 4 unique words on average. I peeked ahead. Almost exactly 1/2 of those unique forms only have 1 occurrence across the text. So the lexicon loading work still ahead is less productive than done so far.

The best work flow for finding and loading those remaining words is not the same as done so far. Because these are low frequency technical terms, they need to be checked against several texts in order to get a sense of a normal meaning. The best general tool for this is the VR app. This app shows several versions in parallel. So it gives a good way to find consensus for those mostly rare words.

So the first obvious step is to get the Paleo Bible loaded into the VR app itself. There is more that needs to happen besides that first step. The VR app is now getting my coding attention and will go through a major refresh before we go much further with the detailed problems of the Paleo Bible text itself. More on these details as I have something to report.

BRB Updates

Our Tabernacles read through the text changed our understanding of how Joshua's voice functions in the text relative to other claims to god speaking in the text.

Until this read, these very different voices were considered the same and both were given green coloring. Ryan has previously started adjusting those colors, but this week did a major refresh of both the color palette used for the text and the organization and details of all of the standard manuscript related settings.

Voice

The link above is to the BRB app itself. Use the right menu and select the Settings choice to see these updates. The first change to notice is how the color used for text ascribed to a god is now a dark yellow. Only Joshua gets green text. You can think of this as like a caution sign, since text in this voice is trouble. Commonly, this is a deceiving voice of some sort.

For a good example of this in action, I would recommend Genesis 3. This is the story of the fall of man. You can see plenty of that dark yellow text as the Hivite deceives Eve and then Adam.

Other Settings changes were also done this week. Let me just review those for the record.

Keywords

The Keywords section has been given headings in order to help see the design organization of various types of keyword markup. Those new headings are Setting, Numbers and Other.

Address

The address markup is relatively recent, and provides an enclosing box when the text is addressing some audience besides us, the normal readers.

There are places in the text with unnatural changes in address which most likely mark an addition. This markup allows those changes to be spotted. An example can be seen with the address settings enabled, navigating to Psalm 90, and comparing the first 16 verses with the final verse.

Cross References

These began as Quote Links, but have grown into a series of internal cross references of various types. In each case, a reader can tap the link and move quickly to the other end of the link. There is also a link back, making study of this sort of manuscript structure easy and fast to do.

This week there are section headers in the Settings in order to organize and explain the various types of cross references. There are 5 types of actual quote links. These range from direct quotes through various milder forms of quotes.

There is now an Allusion and Motif section where text is alluding to some earlier story or following a motif. These are not direct quotes, but they are interesting points of study.

Then there is a section for Angels and Souls. This provides an easy way to chase down references to angels. Angels start out as people and then become walk offs. Angel references can sometimes be identified. This markup allows tracking those references.

The Souls option enables the display of links to past/future lives.

Quote Maps are a series of links that map a series of passages in a structural or in-order way. The links are subtle, like allusions, and would not usually stand alone, but as a series they form a recognizable map between the quoting passage(s) and quoted passages. The best Quote Map example is the way the first 9 chapters of Isaiah pick off details from the first 9 books of the Bible (apparently skipping Ruth, which in the Hebrew Bible comes later).

Finally, the Contradictions link type enables the display of links that point out when a verse is contradicted in some other passage.

Literary Devices

This is a new section heading in Settings. Though the function has been around for a long time. The title is now correct in terms of the technical vocabulary used for how Bibles are studied and marked up. This includes support for displaying enumerating lists, chiastic structures and alphabet runs.

Translation

The Translation section deals with markup related to how the English is being translated from the base texts. Currently the choice in this section enables the display of inline notes that show the logic being followed to create a divine name in the BRB text.

The Aramaic base text that we are using generally softens the divine name references as found in especially the Hebrew OT. The logical steps from Aramaic to English for each divine name reference can be seen in a shorthand form when this setting is enabled.

Manuscripts

There are times when there are material differences in the base manuscripts. There is currently 1 setting that can be enabled in order to show inline notes when those differences are important. This is usually happening when there is a material difference in other texts from the current text.

In Other Apps

You can play around with the BRB app to see how these changes are going. Most of the individual settings have an address that shows an example if you want to see an actual use. Many of these same settings also show up in the TT and related apps.

Preparing For Paleo Bible

These Settings related updates are just one of a series of updates we are making to our tooling in order to be ready for audit work coming here soon. Each setting, for example, is tied to manuscript markup that can be found in any Bible text, including eventually the Paleo Bible itself.

There is a list of other manuscript markup changes that we are making in order to support the Paleo Bible. We are making those changes in other Bibles in order to have real, current, test cases for understanding and testing these markup changes. Especially troubling is our current interlinear tags. That family of markup needs support for direct ties to lexicons. We also need better support for commentary style data.

Another change that is online this week involves adding full formal support for general inline translator notes. These are not currently used in the BRB, but they show up in other versions of texts in our library. Let me explain by use of an example.

Translator Notes

Translator notes are created by translators who run into issues when they are doing their work. Honest translators often want to tell, or warn, readers about some issue. In printed Bibles, these notes usually show up as foot notes.

So our tag system for Bible markup was updated this week in order to carry around and display translator notes. These are common in most English translations.

Our first working example of this are translator notes in the MRD text. This text shows up in our Bible Reader app. It already contained translator notes, but those notes were simply displayed inline to the running text. When the MRD was first added here recently, we anticipated fixing this obvious bug.

That problem of no support for inline notes is now fixed. They now show up like a footnote. This is a very nice trick that we can use anywhere else they may eventually be needed, including eventually in the BRB and Paleo Bibles.

So the link above is to John 7:53 in the MRD text in the Bible Reader app.

If you go into the Settings and turn on the Translator Notes you will see a medallion show up at John 7:53. This medallion is essentially a foot note number for a translator note at this location.

The MRD translation is interesting to us because it carefully notes differences between Greek and Aramaic texts across the New Testament. So you can see why this translation's notes are important to our work.

If you tap that note number, you will get a footnote displayed at the bottom of the app's window. That footnote at the bottom shows off the text of that note. This function is simple enough. All other inline notes work the same way.

To clear the footnote you can just tap the note itself. This is essentially acknowledging you've seen the note. It is at the bottom of the page to hint to the heritage of printed footnotes.

Any navigation in the app that causes the URL to change will also clear the note. The current design is built around the idea that the page can be scrolled around some without immediately clearing the note.

Other Uses

This new notes system itself allows for long form "aside" style notes. It also allows for various medallions to mark different types of notes. The technical work for this feature is now done. Markup can now be added in the various Bible texts as needed.

We are headed for a full update to the VR app where more Paleo Bible work will be done. All of the inbound texts to that app will be updated here soon and any notes found in those texts will be moved into this new notes system.

3d Model Scaling

So last week I showed photos on Telegram of the first print of the Sower model done at 3 times normal scale. This is intended as part of the exhibits that would make up a classroom for learning the inspired systems of the text.

This exhibit is the absolute starting point for explaining the drawn letter forms of the paleo Alphabet. Behind this exhibit is the Scripts wall hanging, which is already designed and fabricated.

The most important early proof of inspiration for the alphabet itself is the Sower and Reaper models. So students must know these exhibits well. They need to be available for inspection. They need to be big enough to see very clearly. They need to be strong enough to pick up and handle.

By last Friday, most of the parts for this exhibit had come off the printer. The parts themselves mostly looked good. They mostly assembled as they should.

But, there was trouble. I was not really expecting serious trouble, but I did find some important issues that are not simple to fix. These issues were caused just by the 3 times scaling factor I am using with this exhibit. Let me explain.

Design Concepts

When a scribe copies a manuscript they are moving a pen around on the page. The tip of the pen can be just about any shape. There are issues of writing style that might inform the shape of an actual scribe's pen tip.

But, a good modern example is a ball point pen. This combines a rolling ball bearing with a continuous source of ink.

For the 3d models, the conceptual idea is similar. Move a sphere around in 3d space and the area traced out by that ball becomes the 3d model.

For the Sower and Reaper, the alphabet is folded. Each folded letter pair creates a different 3d model. Those models assemble into the larger Sower and Reaper exhibits.

This is the basic conceptual lesson that students must learn. These are the conceptual lessons that create the Sower and Reaper models. These lessons constrain how each letter is actually drawn on the page. All modern phonetic alphabets distort this base reality because these lessons were lost by history.

Design Constraints

Spherical shapes do not 3d print very well. 3d Printers have flat beds and bed adhesion is driven by surface contact area. So a faceted ball, instead of sphere, is a better pen shape for this work.

Indeed, the Eden that is up in the sky might be the reference "pen" for this work. It, too, is ultimately a faceted ball.

The design work has been through 2 different generations of pens. The first was formed like a 3d version of a tic-tac-toe board. The second, and current pen shape is like a stop sign in 3d space. This second form for the pen has square facets that are larger than the square facets of the earlier tic-tac-toe pen. With this new pen, all the extreme facets on the pen are larger and the same size, so it naturally has better 3d printer bed adhesion.

All the parts built with this new pen also have better material volume in the final parts. So they are naturally stronger. So everything is good? Mostly. But there are issues with curves.

Creating Curves

Moving a sphere around in 3d space leaves behind something like pipes. Those pipes are still circular even if the pen itself is moving around a curve.

Moving faceted balls around in 3d space, especially when going around curves, creates a slightly distorted set of facets on those curves. Until this past week that distortion was visible to a trained eye, but otherwise never really mattered. The arms of the lamp, for example, have slight distortion from this effect. I'll show a pic on Telegram so you can see.

At 3 times scale, some aspects of that distortion now shows up meaningfully in the 3d printed parts. And, that distortion is now causing trouble. Let me explain.

Surface Defects

The print that actually triggered the problem was the hand on the right arm of the sower. I will show a pic on Telegram of the problem. There was a surface texture effect going on about half way up the fingers from the palm. This was NOT in curved fingers, this was in the flat hand of the sower. So it was not part of the known arc related problems as I described above.

The effect looked like something caused by trouble in the sectioning code. What was added this time around was the division of the now larger model into smaller parts. This sectioning allows those parts to be easily fabricated on the flat bed of the 3d printer.

Sectioning also means no supports are needed, this saves plastic, print time and it leaves a better surface finish on the final part.

These part sectioning cuts are done with 3d blades. In the past, if those blades were misplaced in 3d space they could mess up surfaces. I have seen this before.

After inspecting the design files, there was no trouble with the sectioning related blades. Something else was messing up the surface texture on the palm of this print.

It took some time to figure out the problem. In the end there was a small burr in the 3d part for the hand. This burr lifted one end of the hand very slightly above the 3d printer bed.

The slicing software was trying to cope with a slight pitch on the bottom of the part. It was no longer flat to the bed. About 1/2 way down the hand, the gap from the hand to the printer bed was small enough that the slicer considered it to be zero. After about 1/2 way down, the gap was big enough that the slicer thought it should compensate. A rough surface was the final effect on the printed part.

Burrs?

Why had we never seen this before? The only real difference was the factor of 3 scaling going on in these new exhibits. So the burr was always there. But, those burrs were considered as close enough to zero by the slicer to be ignored. Now the burrs are big enough that the slicer wants to compensate.

Industrial History

Industrial history is riddled with failed designs that had worked at smaller sizes, but then failed when scaled up. The Union Pacific Big Boy, 4014, steam locomotive is an example of a design that worked when scaled up. The Big Boy class of steam engines goes down in history as a marvel of mechanical design in part because it was the biggest ever built. But, also, in part because the design did not fail when scaled.

There was a similar locomotive, the "Allegheny" built by competitor on an eastern railroad. It was built at the same time as Big Boy, and is often touted as bigger than Big Boy.

But, that other locomotive design had balance problems and pounded and destroyed track when run at full speed. To cope, the owners down rated the top allowed track speed for the Allegheny class of locomotives.

But, that locomotive's firebox was not optimal for use at slow speeds. So it burned the same fuel load for less track travel. So it was uneconomical to run. The last remaining example of that failed class of locomotive sits in the Ford museum. Such is the history of design scaling.

My Own Example

In trying to scale up parts by a factor of 3, I had now just hit my own example of this same engineering history.

So where are the burrs that upset the slicer actually coming from?

It took some time to find the source of the burrs. They are small enough that they are even hard to see on the screen of the 3d design software. Parts must be zoomed way in to see the problem.

Their source comes from the way the pen is not a perfect sphere as it is being moved around in 3d space, especially for arcs. Those arcs are not mathematically perfect. They never can be, as 3d design software breaks all objects into collections of relatively tiny triangles.

Not only is the pen not a sphere, but those arm related arcs are actually series of 2 degree steps instead of a perfect curve. That step size impacts rendering times for the models. Years ago those arcs were 5 degree steps, but current hardware can render 2 degrees with reasonable speed.

This imperfection in the structure of the arm, when it connects to the hand, creates slight imperfections at the intersection of these different design elements. That is where the burrs come from. That is where the surface texture issue was being created that caused the trouble in the slicer.

Other examples?

So I started to review the entire design. Are there similar examples going on in other places? Are there any places in the designs where only by accident are we not seeing burrs that are creating slicer related failures?

It looks like all sectioned designs risk trouble if the blade used to divide sections touches on an end of an arc. Trouble created by poor sectioning does not show up in the print if the burr is up and away from the printer bed. But, ignoring this problem by being careful in the slicer is hard because burrs are so small.

I eventually expect anyone to be able to 3d print these parts. I do not want to have warnings about burrs. I need to get rid of all burrs. I need to ensure these defects cannot happen by accident ever again.

Fixes

So after a couple days of thinking about this, there turns out to be some needed changes to the designs. (This, by the way, across ALL parts in the library. All bones, all exhibits, need these few changes. Even the lamp needs changes.)

The first big deal is to fix arc related problems. Moving a 3d pen around in 3d space is a conceptual problem. For most of the arc of, say, the arm on the sower, the pen needs to look like a 2 shape, like a circle or in our current case, a stop sign shape. This can be created easy enough. The standard pen needs to be scaled flat, like squishing a grape. A pen at 1 percent of the normal height can move around the arc and leave a nearly perfect arc like shape in its wake.

This clears up most of the problem. All arcs now approach theoretical shape. But, this change then always needs at least a regular pen at the beginning and end of the arc.

If the arc connects to something else, all is good. If not, like the end of a finger, then there needs to be a correctly sized 3d pen placed at that location. Stub ends, with a terminating full sized pen, then complete the end of the arc in a normal way.

Stub ends on arcs are a design element that does not currently exist in the design files, so it needs a careful recheck across the various parts.

Special Cases

This works for most cases, but for certain cases the ark needs to be shortened. Dropping the final 2 degree arc segment, at the ends of parts like the sower's arms, will fix most other cases. Decreasing the arc back by 2 degrees removes the sectioning overhang and thus removes the burr.

In a few remaining cases, especially tight radius parts like the left arm, hand and fingers, the arc itself needs to arrive square at the joint. Because the cut joint must sit flat on the 3d printer bed, the cut is not always at the exact 90 degree mark. Fixing this rare problem involves cheating the center and radius of the arc itself. This needs to be done ever so slightly. This is a very rare case, but it does happen in a few places.

Finger Problems

Once I was watching for scaling related, and slicing related, problems, I found more issues. The left hand on the sower was the source of more trouble.

The whole left hand itself will fit as 1 part on most 3d printer beds. But, if printed whole it requires support material. Low budget support materials mar the finish of the final parts. Sectioning gives better final results.

So the left hand is sectioned so all parts can print flat on 3d printer beds. This keeps all of the silk plastic surfaces shiny and nice. The parts then must be assembled after printing. From a design perspective, all was fine.

But the first draft of the design for the cut point required supports to be used in the 3d printing of the joint. Low budget supports rough up the texture of the supported surface. That roughness weakens and deforms the glued joint. That deformation caused the fingers to not sit square to the rest of the model.

Those finger joints needed to be redesigned so no support was needed. This was done by adding parts that insert into the joint. The complicating issue is how threading goes through the same joint. The seeds carried in the left hand of the sower and reaper are supported by a thread that must also go through the joint.

In any case, the final finger joint design works. It reminds me of trouble with fingers on humanoid robots, which are also tricky to figure out.

In any case, this family of scaling related problem looks to be fixed.

Tolerances And Strength

Then there were problems with the parts that connect the exhibit sections after the 3d printing is finished.

This new fabrication step creates a bunch of tolerance and debris related issues. The interior cavities end up printed across air, or else with hard to remove interior supports. This means there are strange tolerance issues with all of the related parts.

Some of this I understood already. But I found there must be room at the back end of peg holes to capture surface debris. Designs were changed to compensate for these strange fabrication issues. Primarily, this was done by adjusting the tolerance values and by adjusting the lengths of joining tabs.

Lessons Learned

These fixes work, and I have 3d printed parts with these fixes. But, I need to not be so quick at printing large sets of parts at a scale that has never been used before.

The 3d print farm is now working through these parts one-at-a-time so they can be carefully checked and tested as they come off the printers.

Watch for more pics on Telegram as this blog goes out. The farm is now working through a complete reprint of the Sower. It should be done next week.

Match Dates

We are currently in the replay of King Jotham. The last year of his reign ends on 2026-10-18, which is the Sunday after this blog goes out.

The main event across the replay of this king's reign appears to be the war between Saudi Arabia and Yemen. Yemen appears to have the upper hand. The Saudi's are taking numerous hits to their critical infrastructure. This includes oil infrastructure as well as airports. As the Saudis impose a blockade on Yemen, the Saudi airports are blockaded in response.

Yemen is mostly Shia, just like Iran. (Shia is referenced by name in the Aramaic version of Revelation and should eventually be victorious, though not soon. Yemen, like Iran, is currently learning how to win.)

The Saudis are Zionist. There are strong rumors that Israel's people are protecting the leader of Saudi Arabia in order to keep that kingdom from collapsing. Zionists are an occupying force in Saudi Arabia, just like they are in the USA and Europe. The Saudis, just like Americans, have the problem that many of their public supports their jailers.

Watch Dates

We are currently watching 2026-10-18 and 2026-10-19 for a change from the replay of the end of the reign of Jotham to the start of the replay of the reign of Ahaz. These dates are the Sunday and Monday after this blog goes out.

Peeking ahead, Ahaz's reign runs through 2026-11-03. Note that the US elections are on this same November 3, 2026, date.

That November election should upset the political leadership in the USA which will transmit to events in West Asia.

Headlines after the election may become more intense. The siege of Jerusalem and the Assyrian deportation replays on 2026-11-09. In that story Jerusalem survived, but not much else. Whatever that headline may be, it looks to be connected to the US election in November.

More on this as we get closer.

Notes On MOABs

On the Iran front, Trump is now openly discussing the use of MOABs against Iran. These are the "Mother Of All Bombs." They are huge, conventional, munitions.

MOABs are also political theater used to cover the use of small nukes. It looks like the plans for the use of nukes have been floating around for weeks. But now, operationally, MOABs are the chosen cover story to hide the use of actual nukes against Iran.

Note, importantly, MOABs are so large they can only be dropped by slow moving transport style aircraft. These bombs are pushed out the back of the plane while in flight over the target, just like any other heavy freight style cargo delivered by these same planes.

This means MOABs are NOT precise and cannot accurately hit specific targets. This also means most of these aircraft are slow, big, easy targets for anti-aircraft defense systems.

Any claims to accurately hitting targets in Iran are thus likely to be theoretically false. Iran should also be able to shoot down at least a few of the aircraft involved.

More likely, is that small nukes will be delivered by high speed fighter jets and western media will claim MOABs were used. This allows Trump and his Zionist team to lie about breaking the various treaties dealing with the use of nuclear weapons. Trump and his team will become war criminals if this happens. Probably doesn't matter to them since they are already Epstein clients.

We had expected this sort of event to have already happened in the kings replay a few weeks ago based on how we mapped the Plagues on Egypt to the kings. That mapping has not be tested against real headlines, so it was speculative.

So this round with MOABs is in effect a second way to map the plagues of Egypt. We will review that map once we see what the actual headlines turn out to be.

Headline Review

The following caught my attention this week.

Kiev Loosing Power

The city of Kiev is reaching the point where it is becoming unlivable. No water, no sewer, no electricity, no heat. The mayor is recommending leaving the city.

Netanyahu Knew

This link is to a post on X by Martin Armstrong. Markets were moving about a week ahead of October 7, 2023. Netanyahu and his crew knew what was going to happen and were trading it.

Market moving ahead of headline events is a common clue that someone knows a major headline is about to happen. They want to profit from their crime.

This has even happened ahead of what look to be natural disasters. Some of those disasters must have been man made.

Trouble in Tehran

Some of the early US bombing of Tehran in the spring of 2026 hit a chemical plant in Tehran. The city was nearly evacuated over the pollution.

Use of Nukes

There has been ongoing discussion over use of nukes at various times over the past few years. A nuke was most likely used against Yemen when the war against Yemen began.

These weapons leave behind various signatures, like how they show up on digital cameras, the strangely strong shock waves, earthquakes and patterns seen in their large but strange mushroom clouds.

Attackers using these weapons generally claim these are large conventional bombs, like MOABs, or fertilizer or whatever.

Why would we trust anyone who claims to be setting off any such large weapon? Photographic and earthquake signatures are the best measure for what was detonated.

The link here is to a post on X with a video of at least one of these strange explosions.

Trump Threatens Iran

So now consider Trump's threats against Iran. So after the election. He probably intends to use many of these strange weapons. He would obviously go on and deny he used nukes, even if that was what he actually used.

Git Hub Problems

Committing any sort of important data to a public service is always stupid. The link here is to someone who lost their apparently private git hub account. No recourse. The Zionists who run Git Hub (MS) probably did not like his religion. Careless use of online AI services is similarly stupid.

Adobe Clones

This link is to a Youtube video, about 10 minutes, that reports about a small team that is using AI for cloning all of the Adobe apps. This does not look to be a perfect, clean room style, clone as Eric Raymond has recently described. But it is showing off the tech for making copies of otherwise massive apps.

Adobe has a wretched business model, so there is no love lost for this cloning work. Adobe is one of the few software packages where it can cost big money to END a subscription. They are like some sort of motel in a horror movie. You can check in, but you can never check out.

These new apps are not yet finished, so this is just a proof of concept. But you can see how commercial software is doomed. All commercial apps will be competing with mostly AI generated, fully open source, replacements at some point here soon. (Thinking about MS Office, OBS and similar important apps as examples.)

Note that the Adobe response can come in several forms. 1) Seriously reduce their licensing fees and legal traps, or 2) litigate each of what will become an army of clones or 3) litigate the users of clones or 4) buy off congress in some way.

Litigation is interesting because clones can now spring up like mushrooms. They will eventually spring up around the planet, outside of the legal jurisdiction of any particular judge.

Software, for software's sake, does not look to be an enduring business. Software, tied to hardware, still looks interesting. Think control software tied to the hardware of rockets as an example of expensive software not likely to be damaged by AI generated clones.

Aramco Headquarters

The link here is to a post on Telegram by Press TV that shows the fire at the Aramco Headquarters is burning down in Saudi Arabia. It will not be easy to stop Ansar Allah in Yemen. The Saudis are at risk of widespread destruction of their modern infrastructure.

Trump Now Talking MOABs

This link on Telegram has a clip of Trump talking about the use of MOABs. Note how he has been discussing bombing Iran for a long time. Now the planning cycle in the military has a plan and has a cover story. Nobody was thinking about MOABs a month ago. Trump is just talking up the new cover story.

More Later,

Phil