https://www.theregister.com/security/2026/07/04/confidential-computings-core-trust-mechanism-is-broken-the-fix-may-not-exist/5266056

The claim in The Register is that confidential computing might not be a fixable problem. I am not going to claim I have "the solution", or that the solution I have come up with meets either the requirement of being necessary or sufficient, but I would argue that it adequately challenges the assumption that the problem cannot be solved at all.

So what is my hare-brained scheme this time?

Well, Brain, it's like this:

We first need to have reasonable confidence we are talking to the computer we are intending to be talking to. Now, in the early days of IPv6, when host-to-host IPSec was mandated, this class of problem looked to be generally solved. If we want to modify it for modern environments, it would need to look something like this. (Note: I'm using Class 3 as per the strong historical intent, as described later, to avoid unnecessary extra wording.)

1. IPSec in tunnel mode, with Class 3 digital certificates, at the entrance to the network at both ends. This gives us some assurance that we're talking to the right network.

I should define the entrance in a biit more detail. Packets arrive at a hardware proxy in a firewall's DMZ. This proxy handles the outer IPSec. The card rigorously enforces packet size and payload size, so underruns and overflows aren't effective. The inner IPSec packet exposes nothing but the source physical machine and target physical machine, but this obviously has to be a valid pairing.

2. IPSec in tunnel mode, with Class 3 digital certificates, on the physical ethernet cards at both ends. The ASN1 records used to build those certificates must include a full description of the hardware. There are optional fields in the X.509 certificate we can place the SHA3 value in. We can use SNMPv3 with strong encryption to interrogate what the system is reported by hardware as being, and can therefore not only validate that the certificate is correct but that it describes the hardware as reported.

The client therefore can validate that the system description, once decrypted, has the same SHA3 hash as the manufacturer described when building the certificate. Because of the type of certificate I'm mandating, the requirement is that the CA is vouching for verifying the credentials of the manufacturer and that the full hardware description genuinely describes the system the certificate is being issued for.

However, SNMPv3 is corroborative, not authoritative. It can compare the live-reported hardware inventory against the certificate manifest, but it cannot prove the hardware state unless the reporting agent is itself inside the trusted/measured boundary. The real machine must therefore do this in hardware. A fake machine can, of course, report how it likes, but as SNMPv3 supports strong encryption, getting the right values requires breaking into the SNMPv3 system. Which, over a network already doubly encrypted by IPSec, isn't going to be straightforward.

The certificate is derived from a set of manufacturer-held hardware measurements or device-specific secrets that are unique to the individual physical device and are not derivable from the certificate or from publicly observable behaviour. The hardware exposes only cryptographically protected evidence derived from these values; it does not reveal the values themselves. The authenticated management channel (for example, SNMPv3) is used solely as a confidential transport for this evidence, preventing disclosure of the underlying measurements during normal operation. A counterfeit device may fabricate arbitrary responses, but without knowledge of the device-specific secrets it cannot produce evidence consistent with the manufacturer-certified identity.

(This is distinct from simply using unclonable functions. An unclonable function is simply one way of producing the behaviour you want and not necessarily the best. The implementation is less important than the requirement that the client be able to independently verify - directly or through calculation - that the measurements made independently of the manufacturer match what the certificate says they should.)

The NIC certificate proves the NIC, not the whole physical machine. To prove the whole machine, the NIC identity must be bound to TPM/HSM/CPU/firmware/board measurements, not merely to a hardware manifest. As noted above, the measurements differ between components of the same type but are the same for the same component at all times. The full description of the hardware you're validating against is therefore truly a full a description of the physical environment. This means an attacker can't cheat by simply finding out what you're running. Nor is a replay attack going to help, because the description of the physical environment will vary by measurable criteria and the certificate can specify that relationship.

Our requirements are, however, double-ended. The server has exactly the same level of assurance that the hardware the user is using is the hardware the user is supposed to be using. Because the SNMPv3 is supposed to be a hardware implementation, alterations to the client hardware would be rejected just as much as alterations to the server's hardware.

3. The OS needs to be at a security level similar to B2 or B1. We have one IPSec tunnel per security label that we are using for the application. It is a requirement that the OS implements the Rainbow Book requirement of verification that only data of the right security label go to any given IPSec tunnel AND that IPSec tunnels only connect to machines that report they can handle that security label. Security labels must be end-to-end policy objects. The label has to bind the local process, user the process is running under, tunnel, remote process, remote OS clearance, and remote handler. Otherwise the tunnel may be correctly labeled but terminate in the wrong software context.

Now, again, this is authenticated bidirectionally, so that both client and server are assured that data is never permitted outside of its authorised bounds.

Further, the OS is authenticating all operations. So it is not sufficient that the processes are permitted to access the data. Processes at each end are only authorised certain operations. This is how we stop a process from being manipulated. A process that is only authorised to read data from a unidirectional connection cannot have the binary modified to write, because it isn't authorised to access the write function.

4. We need memory to be encrypted at the hardware level. The contents of memory are encrypted and all access is decrypted on-the-fly. Anything pushed into memory is also encrypted at the hardware level. This is handled per code segment, so one code segment cannot trivially access the memory of another code segment. Communication has to be by a controlled mechanism. This should be as transparent as possible, as you cannot fully trust the OS.

The read/write operations between a client and a server are two halves of the same code segment, so even if modules A and B on the server are both entitled to talk to the same client, module A on the server can only talk to module A on the client because module B will use different encryption so cannot understand anything sent from module A unless sent by a mechanism explicitly designed for that (which, in turn, would never have fine-grain access to the outside network). So even when access controls permit communication, it's not enough - it has to be between appropriate clode blocks.

(And, likewise, the appropriate code blocks running in inappropriate contexts also can't connect as there's now a security label violation.)

5. Data within each segment of program is also encrypted, but this can be a lightweight context-bound cryptographic transform. The idea is to force you to break the application in order to get keys to break the data, knowing the encryption for the memory is insufficient. Program blocks that communicate across networks use shared secrets, so that a module on computer A knows that it is talking to the corresponding module on computer B and not some different module in the same program.

If each individual library/module has a unique decryption key, then local copies of data are encrypted differently. This doesn't necessarily add overhead for us because the encryption and decryption are done at bus-level and we don't require these operations to match. This could be done in one of two ways - transfer the whole data across each time, OR decode in the context of where the data currently is where this cannot be determined solely by knowing the context of the code accessing it.

The idea is that if the data is in object A but object B references it, the key used is that for object A, since that is where the data is. Object B does not know which segment the data is in, so does not know which key will be used. So if the data moves to a segment controlled by object B, object B's key is now used but object B is totally unaware of the move or key change.

(So if you dlopen a dozen modules, each module will have its own independent encryption scheme.)

6. The application is also encrypted on disk, so having access to the disk copy isn't good enough.

7. Your virtual OS is something like Plan9/9Front/Inferno, running as a "federated" virtual computer. Each machine is running different encryption keys. Knowing the process is not enough, you have to know which instance it is running on. Reason for this is that it keeps garbage collection relatively simple.

8. The physical computer uses some form of responsive tamper resistance.

9. Security kernels in ALL of the OS' used must meet an adequate level of assurance of correctness. Proof is ideal. You don't need to prove the OS correct, if using proofs, only the security kernel.

In principle, this means that the client computer knows it is talking to the correct process in program A, running in the correct security label, running on the correct virtual machine, running on the correct physical machine, where the physical machine has provided evidence it is running the hardware it is supposed to be, on the correct computer network, where the certificates used to vouch for the virtual machine, physical machine, and network are of a level where there has been multiple pieces of physical documentary evidence provided in person to the certifying agency that the owner is who they say they are, that they are the owner of the equipment for which the certification is being issued, and that they own the business the equipment is used it.

Class 3 is, here, used in the strong sense of high-assurance organisational/device certificates with in-person identity/equipment/corporation validation. It should not be taken to mean anything that any CA happens to feel should merit this designation. The trusted CA keyring would have to reflect that.

The network/session key is bound to: peer certificate, security label, VM identity, process/binary measurement, handler-library measurement, and hardware. This means that you need access to information that is NOT readily available, even with physical access to the machine.

Does this provide a hard guarantee? Not quite. What it provides is that no layer trusts any other layer completely, and that there is a blend of shared secrets and double-ended authentication such that neither breaking into the code NOR breaking into the network will independently provide sufficient information.

Is this scheme workable? No idea. The question is not workability, or whether it even meets the strict criteria of genuinely confidential computing, but whether this sort of scheme is sufficient to provide an outline that is robust enough that a researcher could extend the ideas and thence construct a formal proof of whether confidential computing is achievable.

https://www.theregister.com/security/2026/07/04/confidential-computings-core-trust-mechanism-is-broken-the-fix-may-not-exist/5266056

The claim in The Register is that confidential computing might not be a fixable problem. I am not going to claim I have "the solution", or that the solution I have come up with meets either the requirement of being necessary or sufficient, but I would argue that it adequately challenges the assumption that the problem cannot be solved at all.

So what is my hare-brained scheme this time?

Well, Brain, it's like this:

We first need to have reasonable confidence we are talking to the computer we are intending to be talking to. Now, in the early days of IPv6, when host-to-host IPSec was mandated, this class of problem looked to be generally solved. If we want to modify it for modern environments, it would need to look something like this. (Note: I'm using Class 3 as per the strong historical intent, as described later, to avoid unnecessary extra wording.)

1. IPSec in tunnel mode, with Class 3 digital certificates, at the entrance to the network at both ends. This gives us some assurance that we're talking to the right network.

I should define the entrance in a biit more detail. Packets arrive at a hardware proxy in a firewall's DMZ. This proxy handles the outer IPSec. The card rigorously enforces packet size and payload size, so underruns and overflows aren't effective. The inner IPSec packet exposes nothing but the source physical machine and target physical machine, but this obviously has to be a valid pairing.

2. IPSec in tunnel mode, with Class 3 digital certificates, on the physical ethernet cards at both ends. The ASN1 records used to build those certificates must include a full description of the hardware. There are optional fields in the X.509 certificate we can place the SHA3 value in. We can use SNMPv3 with strong encryption to interrogate what the system is reported by hardware as being, and can therefore not only validate that the certificate is correct but that it describes the hardware as reported.

The client therefore can validate that the system description, once decrypted, has the same SHA3 hash as the manufacturer described when building the certificate. Because of the type of certificate I'm mandating, the requirement is that the CA is vouching for verifying the credentials of the manufacturer and that the full hardware description genuinely describes the system the certificate is being issued for.

However, SNMPv3 is corroborative, not authoritative. It can compare the live-reported hardware inventory against the certificate manifest, but it cannot prove the hardware state unless the reporting agent is itself inside the trusted/measured boundary. The real machine must therefore do this in hardware. A fake machine can, of course, report how it likes, but as SNMPv3 supports strong encryption, getting the right values requires breaking into the SNMPv3 system. Which, over a network already doubly encrypted by IPSec, isn't going to be straightforward.

The certificate is derived from a set of manufacturer-held hardware measurements or device-specific secrets that are unique to the individual physical device and are not derivable from the certificate or from publicly observable behaviour. The hardware exposes only cryptographically protected evidence derived from these values; it does not reveal the values themselves. The authenticated management channel (for example, SNMPv3) is used solely as a confidential transport for this evidence, preventing disclosure of the underlying measurements during normal operation. A counterfeit device may fabricate arbitrary responses, but without knowledge of the device-specific secrets it cannot produce evidence consistent with the manufacturer-certified identity.

(This is distinct from simply using unclonable functions. An unclonable function is simply one way of producing the behaviour you want and not necessarily the best. The implementation is less important than the requirement that the client be able to independently verify - directly or through calculation - that the measurements made independently of the manufacturer match what the certificate says they should.)

The NIC certificate proves the NIC, not the whole physical machine. To prove the whole machine, the NIC identity must be bound to TPM/HSM/CPU/firmware/board measurements, not merely to a hardware manifest. As noted above, the measurements differ between components of the same type but are the same for the same component at all times. The full description of the hardware you're validating against is therefore truly a full a description of the physical environment. This means an attacker can't cheat by simply finding out what you're running. Nor is a replay attack going to help, because the description of the physical environment will vary by measurable criteria and the certificate can specify that relationship.

Our requirements are, however, double-ended. The server has exactly the same level of assurance that the hardware the user is using is the hardware the user is supposed to be using. Because the SNMPv3 is supposed to be a hardware implementation, alterations to the client hardware would be rejected just as much as alterations to the server's hardware.

3. The OS needs to be at a security level similar to B2 or B1. We have one IPSec tunnel per security label that we are using for the application. It is a requirement that the OS implements the Rainbow Book requirement of verification that only data of the right security label go to any given IPSec tunnel AND that IPSec tunnels only connect to machines that report they can handle that security label. Security labels must be end-to-end policy objects. The label has to bind the local process, user the process is running under, tunnel, remote process, remote OS clearance, and remote handler. Otherwise the tunnel may be correctly labeled but terminate in the wrong software context.

Now, again, this is authenticated bidirectionally, so that both client and server are assured that data is never permitted outside of its authorised bounds.

Further, the OS is authenticating all operations. So it is not sufficient that the processes are permitted to access the data. Processes at each end are only authorised certain operations. This is how we stop a process from being manipulated. A process that is only authorised to read data from a unidirectional connection cannot have the binary modified to write, because it isn't authorised to access the write function.

4. We need memory to be encrypted at the hardware level. The contents of memory are encrypted and all access is decrypted on-the-fly. Anything pushed into memory is also encrypted at the hardware level. This is handled per code segment, so one code segment cannot trivially access the memory of another code segment. Communication has to be by a controlled mechanism. This should be as transparent as possible, as you cannot fully trust the OS.

The read/write operations between a client and a server are two halves of the same code segment, so even if modules A and B on the server are both entitled to talk to the same client, module A on the server can only talk to module A on the client because module B will use different encryption so cannot understand anything sent from module A unless sent by a mechanism explicitly designed for that (which, in turn, would never have fine-grain access to the outside network). So even when access controls permit communication, it's not enough - it has to be between appropriate clode blocks.

(And, likewise, the appropriate code blocks running in inappropriate contexts also can't connect as there's now a security label violation.)

5. Data within each segment of program is also encrypted, but this can be a lightweight context-bound cryptographic transform. The idea is to force you to break the application in order to get keys to break the data, knowing the encryption for the memory is insufficient. Program blocks that communicate across networks use shared secrets, so that a module on computer A knows that it is talking to the corresponding module on computer B and not some different module in the same program.

If each individual library/module has a unique decryption key, then local copies of data are encrypted differently. This doesn't necessarily add overhead for us because the encryption and decryption are done at bus-level and we don't require these operations to match. This could be done in one of two ways - transfer the whole data across each time, OR decode in the context of where the data currently is where this cannot be determined solely by knowing the context of the code accessing it.

The idea is that if the data is in object A but object B references it, the key used is that for object A, since that is where the data is. Object B does not know which segment the data is in, so does not know which key will be used. So if the data moves to a segment controlled by object B, object B's key is now used but object B is totally unaware of the move or key change.

(So if you dlopen a dozen modules, each module will have its own independent encryption scheme.)

6. The application is also encrypted on disk, so having access to the disk copy isn't good enough.

7. Your virtual OS is something like Plan9/9Front/Inferno, running as a "federated" virtual computer. Each machine is running different encryption keys. Knowing the process is not enough, you have to know which instance it is running on. Reason for this is that it keeps garbage collection relatively simple.

8. The physical computer uses some form of responsive tamper resistance.

9. Security kernels in ALL of the OS' used must meet an adequate level of assurance of correctness. Proof is ideal. You don't need to prove the OS correct, if using proofs, only the security kernel.

In principle, this means that the client computer knows it is talking to the correct process in program A, running in the correct security label, running on the correct virtual machine, running on the correct physical machine, where the physical machine has provided evidence it is running the hardware it is supposed to be, on the correct computer network, where the certificates used to vouch for the virtual machine, physical machine, and network are of a level where there has been multiple pieces of physical documentary evidence provided in person to the certifying agency that the owner is who they say they are, that they are the owner of the equipment for which the certification is being issued, and that they own the business the equipment is used it.

Class 3 is, here, used in the strong sense of high-assurance organisational/device certificates with in-person identity/equipment/corporation validation. It should not be taken to mean anything that any CA happens to feel should merit this designation. The trusted CA keyring would have to reflect that.

The network/session key is bound to: peer certificate, security label, VM identity, process/binary measurement, handler-library measurement, and hardware. This means that you need access to information that is NOT readily available, even with physical access to the machine.

Does this provide a hard guarantee? Not quite. What it provides is that no layer trusts any other layer completely, and that there is a blend of shared secrets and double-ended authentication such that neither breaking into the code NOR breaking into the network will independently provide sufficient information.

Is this scheme workable? No idea. The question is not workability, or whether it even meets the strict criteria of genuinely confidential computing, but whether this sort of scheme is sufficient to provide an outline that is robust enough that a researcher could extend the ideas and thence construct a formal proof of whether confidential computing is achievable.

For a piece of wild and speculative retro-engineering, I've been obtaining electronics data from the 1960s. The data sheets are long (5-6 pages) and very very detailed for just one transistor or just one thermionic valve.

When I compare those to the data sheets you can typically find on a CPU.... it's like it's from another planet. The CPU is incredibly intricate, incredibly complex, has more pins than Baldrick has turnips, and you get maybe a single page of data, often not that.

It's almost like geeks hate writing.

https://vintageaviationnews.com/warbirds-news/griffon-powered-supermarine-spitfire-mk-xix-listed-for-sale-by-boschung-global.html

This would be a great way to avoid the rush-hour traffic, although I can see that there might be complaints it takes too many parking spaces.

As mentioned elsewhere, the total lack of any good conspiracy theories is obnoxious. They tend to be all trivial, trite, and involve the most bizarre cover-ups that couldn't possibly work. I am going to argue we can do so so much better. If L. Ron Hubbard can do it, we can do it with style.

There are several that I've mulled over (line noise being caused by buffalo on the networks, the Time Lords destroying episodes of Doctor Who which reveal too much of the truth, etc). However, it's hard to really develop these into something big.

However, there's one that might just work. Symphonic Metal as a way of smuggling Gods and Demons to Earth, disguised as musicians, without anyone noticing.

Proof is easy to come by:

Nightwish obviously worked with Odin on bass, and the Triple Goddess on vocals. That's why they had to go through three vocalists, they needed to bring the whole goddess down. But how do we know? It could be coincidence! Ah! But humans can't actually shatter things with unamplified vocals. However, Tarja admitted to breaking a lightbulb with her unamplified voice. The implication is obvious, she has to possess non-human powers. And Floor Jansen clearly forgot to shrink down from her goddess stature to human height and now can't do so without people noticing.

But it's obvious that even the "untrained" voices in the genre have far greater powers than most rock or metal vocalists. They pull enormous crowds and can afford entire philharmonic orchestras as a backing group.

Then there's the matter of themes. Symphonic metal almost invariably deals with lyrics about great powers, and who better than the gods to write about those?

As for the drinking on stage - only a supernatural being could possibly put away that much alcohol during a live performance on a hot stage whilst working out at a frenetic pace and still not miss a beat.

Ok, yeah, it's borderline delusional, but that's actually stronger evidence than the Moon Landing conspiracy theorists and the Flat Earthers combined have been able to put together, and they've been around for 60 years/150+ years respectively.

I have been using AI to see if I could invent non-trivial stuff through recycling existing ideas (because AI is bad at actually creating new things). I've been reluctant to post this in my journal, as I dislike self-promotion, but there's so much discussion on AI and whether it is useful, that this isn't really a matter of self-promotion, but rather evidence in the debate on AI as to whether you can actually do anything useful with it.

https://gitlab.com/wanderingnerd50

These ideas have been run through Claude, ChatGPT, Gemini, Grok, Kimi, GPAI, and DeepSeek over many months, to revise, tune, and bugfix. They're now so big and complex, most of these AIs can no longer track them. Claude and ChatGPT are the only ones that are still managing, but even they struggle at times. Both of them report the designs as having a few residual defects but mostly in the testing and validation elements rather than the engineering.

However, they are at the point where one could reasonably argue that if AI can do non-trivial stuff, then these designs should be mostly correct using entirely correct methodology and approaches. If, however, on inspection, you decide that there are obvious major flaws in the approaches, then we can equally conclude that AI cannot do non-trivial stuff.

The hardware designs are all under CERN Open Hardware, and if you think that there's stuff there that's worth actually doing, then feel free to have a go. If you do, however, actually knock yourselves out trying, that should be filed as a bug report. :P

I am placing NO restrictions on what you do with these designs, and leave it entirely up to you on whether you feed anything back. I have deliberately NOT evaluated the designs so that I cannot cherry-pick or subconsciously bias the results of any such evaluation.

Just as a thought experiment, I wondered just how sophisticated a sound engineering system someone like Delia Derbyshire could have had in 1964, and so set out to design one using nothing but the materials, components, and knowledge available at the time. In terms of sound quality, you could have matched anything produced in the early-to-mid 1980s. In terms of processing sophistication, you could have matched anything produced in the early 2000s. (What I came up with would take a large complex, something the size of the National Computing Centre in the UK, purely for sound processing, at least circa 1964, but it could have been done. There was no technological barrier.)

This has led me to an interesting conclusion: The technology we have is limited NOT by what's available, but by a lack of generalists and abysmal communication between the silos of specialists. We have all the technology we need to be 30-40 years ahead of where we actually are, the limitations are purely social constructs and the disdain of the mad scientist/inventor class.

This led me to wonder what we're fully capable of producing today but haven't.

Two episodes are currently showing in 4K in cinemas, they plan on releasing a fully restored boxed set in December (at a naturally very high price but only 1K res), and... why?

Most of the better stories were reworked in Thunderbirds Are Go, Stingray had an arguably better title sequence (and really should be released alongside as it's really part of the same universe), and whilst I'm sure that many of us older fans are still kicking around, who exactly are we going to watch with? It's not like this generation's kids are gung-ho for it, if they were then TAG would have had a fourth season.

Yes, retro has a coolness factor (is cool still cool? I dunno, ever since cringe was yeeted, I've lost track...) and boxed sets for Doctor Who and The Avengers have done ok (but not brilliantly), but boxed sets are getting absurd. Although, to be fair, the most expensive boxed set I've ever seen was for the K-Drama "Goblin" (aka Guardian: The Lonely and Great God), which had a plastic sword and was running at £500.

But, let's be honest, how many people can afford £100-£500 for a boxed set they're unlikely to watch even once right the way through?

(And, trust me, absolutely NOBODY has ever watched the boxed set of Goblin right the way through.)

A restoration expert in Egypt has been arrested for stealing a 3,000 year old bracelet and selling it purely for the gold content, with the bracelet then melted down with other jewellery. Obviously, this sort of artefact CANNOT be replaced. Ever. And any and all scientific value it may have held has now been lost forever. It is almost certain that this is not the first such artefact destroyed.

Nor are other countries immune to destruction of historical materials. The Archimedes Palimpsest was partially destroyed by one collector aiming to raise the value by colouring in the pretty pictures, and then left to rot from mould by a subsequent collector. All the while, holding the only surviving copies of several of Archimedes' texts, various lost plays and poems, and a lost political treatise. Sheer ineptitude and a desire for quick cash did lose us an unknown percentage of the material present and very nearly lost us the rest.

I'm not even going to get into the antiquities stolen from the Iraq Museum that the Americans officially controlled, the items plundered by the allies from archaeological sites, the plundering before and after by locals of completely unexcavated sites, or the fact that ISIS was able to destroy tens, maybe hundreds, of thousands of ancient texts and artefacts on a whim with zero consequence. Nor is it clear that anyone bothered to properly document the Buddhist caves discovered in Afghanistan behind the destroyed giant statues, where vast numbers of cave paintings were discovered, rapidly fading due to exposure to modern air.,

The magnitude of incompetence is unimaginable, as is the impact on what we can learn about the past.

We have many possible futures, but only the one past, and we're not exactly doing a whole lot to protect it. Rather, collectors are blithely funding further wholesale destruction so that they can have a bit more tat for their collection which they neither understand nor appreciate.

I am, as you might have gathered, not altogether happy about the current state of affairs.

Equally, though, it's really not at all obvious what can be done about it. Quite the opposite. Attitudes are such that the situation is rapidly deteriorating, and because attitudes are thus, we risk losing any real history.

It is extremely depressing, and not just in the context of history. People aren't just not caring about the past, the spending on blue-sky science and deep R&D is catastrophically low, most R&D spending is currently on the lowest-possible-hanging fruit by corporations. Investment in education is not exactly sitting pretty either. Intel and AMD chips are faster than ever before, but buggy as all hell and riddled with security defects because cheap tricks make for better publicity stunts than working processors.

Nihilism across the humanities and STEM.

Even open source is not immune. Lots of new filesystems, but no real understanding of why they work and lots of really stupid defects. (How did OpenZFS go through three releases before fixing a bug that wiped out data blocks?)

The world, right now, is just so utterly depressing.

Ok, I've mentioned a few times that I tried to get AIs (Claude, Gemini, and ChatGPT) to build an aircraft. I kinda cheated, in that I told them to re-imagine an existing aircraft (the DeHavilland DH98 Mosquito) using modern materials and modern understanding, so they weren't expected to invent a whole lot. What they came up with would run to around 700 pages of text if you were to prettify it in LaTeX. The complexity is... horrendous. The organisation is... dreadful.

Conclusions from testing so far:

1. Gemini is, at this point, absolutely out of its depth. It is really struggling with this and loses track of stuff easily, but is still usable for verifying if a change is going to work or not.

2. ChatGPT 5 is having a very very very hard time. It'll make far fewer mistakes than Gemini, but even simple tasks (such as re-ordering the text) take 6-7 attempts before it works right. It is completely incapable of producing an OWL2 map of the system, the best you will ever get is a simple list of elements and it can take dozens of attempts to get even that right. My confidence in any of its suggestions is low. It usually takes several rounds of verifying its suggestions against Gemini to get something both agree is acceptable.

3. Claude Pro can't load even a small fraction of the specification without running out of context space, I'd have to pay ten times as much to get a context window that suffices, but even when you hand it small fragments, it... does not do well. But, like Gemini, it can do sanity-checking, within its limited context capacity. It was very good in the early days, much stronger than ChatGPT, but once I hit a complexity ceiling, it really didn't do well.

4. Grok can't cope at all - like Claude, there's just too much there. But, unlike Claude, it's not even any good on sanity-checking.

5. DeepSeek suffers the same problem as Grok, but at least makes something of an effort when given small enough fragments.

My conclusion, for right now, is that no AIs out there can handle complex interactions in an engineering project. I'm sure it's fine for very basic stuff, but they hit their limits at precisely the point they might actually have a purpose - complex engineering projects are precisely where humans (even brilliant ones) suffer, because there's just too much to track and too many ways things can conflict.

I'm not into spamming, but the design the AIs came up with is up on GitLab. My thought, at this point, is that it might actually be interesting to the LLM engineers, because this is the sort of real-world problem that you know AIs will be used for, so they'd better work. But it might also be interesting to engineers. Programming is hard, because that involves creating something new, but this isn't creating something new, it's merely replacing components in something that is known, documented, and actually works, where the only things you're changing are the materials used. Orders of magnitude easier and requires no understanding of the engineering itself.

I would say that what has been produced probably has in the region of 250 defects in it, which would actually be pretty decent if this was a clean-sheet design. An actual aircraft engineer would produce something like that in a version 0.0 design for something built completely from scratch. It's not quite such a good total when there's next to no novel design elements in there at all.

There are ontology editors, such as Protege, where there are a slew of logical reasoners that can tell you how information relates. This is a well-known weakness in LLMs, which know about statistical patterns but have no awareness of logical connections.

Is there a way to couple these together, so if you've a complex set of ideas, you could perhaps provide the ontological network plus some of the things that are reasoned from it, to supplement the prompt and give the LLM the information it can't in and of itself extract?

As with other technologies I've mentioned, there's a few of these. Intel uses a four bit number as a key, for example. ARM uses a different system, but I've not been able to quite fathom what that system was.

The advantage of strong memory protection is that you can't leverage memory management and page management limitations to read stuff you shouldn't have access to, but obviously the stronger it is, the slower it is and it doesn't shield you from cache exploits.

There's also the opposite problem, which is that if you're going to provide very high speed IPC, you've got to provide very fast security mechanisms and you've got to figure out how not to expose security keys to processes that shouldn't have them.

Any geeks here want to offer any thoughts on how to best do this?

I'd said in my last journal entry that there were many technologies for solving specific problems, but limited documentation outside of a simple description.

To cover thus further, I'd like to list packet dropping schemes. Just the packet dropping schemes, no other elements of quality of service such as the queueing mechanism that packet dropping is used with. This will help exemplify why proper undersranding is important.

Partial Packet Discard (PPD)
Early Packet Discard (EPD)
Age Priority Packet Discarding (APPD)
Preemptive Partial Packet Discard (pPPD)
Tail Drop
Random Early Detect (RED)
Weighted Random Early Detect (WRED)
Adaptive Random Early Detect (ARED)
Robust Random Early Detect (RRED)
Random Early Detect with Preferential Dropping (RED-PD)
Controlled Delay (CoDel)
Blue
Global Random Early Estimation for Nipping (GREEN)
Multi Global Random Early Estimation for Nipping (M-GREEN)
PURPLE
BLACK
WHITE
CHOose and Keep (CHOKe)
CHOKe-FS
CHOKe-RH
P-CHOKe
CHOKeD
gCHOKe

And this isn't even close to exhaustive. But it's absolutely guaranteed that no OS supports anything but a small fraction of this list, and equally guaranteed that no developer out there knows which unimplemented schemes would be useful in typical environments for, say, Linux or FreeBSD.

I can also be absolutely certain that no researcher out there working on new schemes knows what is currently out there, when it is useful, or how best to tune it to get a fair understanding of what a new scheme would need to do.

This should give people some idea of the scope of the problem. You often don't see AQM in the enterprise world because there's too many options and nothingnon how to effectively use them.

Pretty much the same reason enterprise systems will use Ext4 or XFS, if running a Ubuntu variant of Linux - there will be far better filesystems for specific needs, but there's way too many options, it's too complex to set up if you don't know exactly what you're doing, and no insights into what need goes with what filesystem.

Even the use of AI won't help much - LLM AIs can't learn from data that isn't out there.

A simple Neural Net could be trained on a range of schemes and workloads and then generate advice on optimal setup, but if no researcher is doing anything more than a cursory comparison, then there's nobody in a position to create such an AI. And, even then, it's only useful for comparing what's there, it still won't help developers figure out what they need to add.

(Although, it would be a great boost to network admins if they could push a button and have an AI figure out the best setup for their servers and network gear.)

There's an awful lot out there in the way of projects. Perhaps hundreds of filesystems, easily dozens of transport protocols (there's sonething like 9 or 10 for the IP protocol alone), there's maybe ten different packet dropping schemes and five or six packet queueing schemes. There's maybe ten of so wireless routing protocols. Linux alone has seen a vast range of schedulers and memory management systems, and three different threading models.

Even in encryption, the number of encryption modes submitted to NIST numbered in the dozens.

But all of these have one thing in common: there's essentially no literature describing what has been learned from any of these experiments.

Sue's, there's papers on each one individually, and sometimes you can find a top-level comparisons and benchmarks, but the level of deep understanding is, at best, limited. We use the tools that work well for us, but don't really understand why they work well.

This matters, because wheels get reinvented on a regular basis, mistakes are routinely repeated, and progress is frequently slowed down by the "Not Invented Here" syndrome that affects open and closed source worlds alike.

My question for Slashdotters, especially the academic ones - - why so little deep understanding? Theoretical work in computer technology exists, but I would not call it deep. Citeseerx and ArXiv have a vast amount of data on how, but nowhere near what I'd expect on why, and it's generally a very targeted why.

There is possible evidence that relativity may be incorrect. It would seem that gravity weakens more rapidly, at extreme distances, than are allowed for in GR.

https://phys.org/news/2024-05-cosmic-glitch-gravity-strange-behavior.html

For some reason, this was discarded as spam from the main page, so I'm putting it in a journal instead.