You send a file, but how do you know it arrived intact? In other words, how do you know that it didn’t get cut off, garbled, or changed somehow? Simplistically, you could just add up all the bytes in the file — a checksum — and send that along with the file. You compute the checksum when you know the file is good, and the receiver can compare the checksum to see if they match.

However, a simple addition doesn’t catch certain classes of errors, which is why there are better checksum algorithms that, for example, wrap the carry bit around or otherwise modify files with common errors so they produce different checksums. There are two problems with checksums. First, no matter how much you modify the algorithm, the chances that two files produce the same checksum are pretty high. Especially with common error patterns.

For example, assume a very simple algorithm that simply adds the bytes and discards any carry. If a file contains 0x80, 0x80, those numbers essentially cancel each other out. If you replace them with 0, 0, you’ll get the same checksum. To some degree, using anything other than a second copy of the entire file will have this problem — some corruption goes undetected — but you want to minimize the number of times that happens.

The other problem is that a checksum by itself doesn’t let you correct anything. You know the data is bad, but you don’t know why. If you think about it, the simplest checksum is a parity bit on a byte: odd parity is simply summing all the bits together. If the parity bit doesn’t match, you know the byte is bad, but you don’t know why. Any even number of errors goes undetected, but I am sure one-, three-, five-, or seven-bit errors will get caught.

People invent better error-checking codes by devising schemes that can promise they can detect a certain number of bit flips and, at least in some cases, correct them. One of these is the cyclic redundancy check (CRC). It is easy to think of the CRC as a “strong checksum,” but it actually works differently. What’s more, there isn’t just a single CRC algorithm. You have to select or design a particular algorithm based on your needs. Most people pick a “named” implementation like CCITT or Ethernet and assume it must be the best. It probably isn’t.

A CRC is a checksum in the broad sense: you feed it a message, and it gives you a small value that you append, store, or compare later. But unlike a simple additive checksum, a CRC is based on polynomial division over GF(2), which is a fancy way of saying “divide using XOR instead of carries.” That detail matters. It gives CRCs very strong guarantees against common classes of errors, provided you choose the right polynomial for the job. That’s the key. You must choose the right polynomial.

The Polynomial Machine

A CRC treats your message as a long binary polynomial. For example, the byte stream is interpreted as a sequence of coefficients: each bit is either present or absent. The CRC algorithm divides the message polynomial, after shifting it by the CRC width, by a generator polynomial. The remainder is the CRC.

In normal arithmetic, division involves subtraction and carries. In CRC arithmetic, subtraction is XOR. That is why CRC code often looks like this:

if (crc & topbit)
crc = (crc << 1) ^ poly;
else
crc <<= 1;

That loop is implementing polynomial long division, one bit at a time. The generator polynomial is the magic number. For a 16-bit CRC, the polynomial has degree 16. For a 32-bit CRC, degree 32. You will usually see it written as a hex constant, such as 0x1021 for CRC-16/CCITT or 0x04C11DB7 for the classic Ethernet/ZIP/PNG CRC-32. But the polynomial is not just an arbitrary constant. It determines what error patterns the CRC is guaranteed to detect.

What CRCs Catch

A well-chosen CRC can guarantee detection of all single-bit errors, many multi-bit errors, all burst errors up to a certain length, and a very high percentage of longer random errors. The key metric is Hamming distance, often abbreviated HD. If a CRC has HD=4 for messages up to a certain length, it detects all 1-, 2-, and 3-bit errors in messages of that length.

That last qualifier is important. CRC strength is not just “16-bit CRC good, 32-bit CRC better.” It depends on the maximum message length. A polynomial that is excellent for 32-byte embedded packets may be mediocre for kilobyte-size messages. A polynomial standardized decades ago may be familiar but not optimal.

[Philip Koopman’s] work at Carnegie Mellon is the go-to reference here. [Koopman] and [Chakravarty’s] paper on CRC polynomial selection for embedded networks specifically looked for good CRC polynomials for short embedded messages, and [Koopman’s] “Best CRC Polynomials” tables list polynomials by width and Hamming-distance performance. The important takeaway is that many standard polynomials were chosen for historical reasons, not because they are mathematically best for your packet size.

There are plenty of videos that explain CRC, but if you are going to watch a video, you might as well pick one of the many from [Phil Koopman] himself, like the one below.

Famous Does Not Mean Optimal

Take CRC-16/CCITT, polynomial 0x1021. It is found everywhere: telecom, embedded examples, and bootloaders. It is not a terrible polynomial, but it is not automatically the best 16-bit choice. [Koopman’s] tables include other 16-bit polynomials with better Hamming-distance behavior over useful embedded-message lengths.

Likewise, classic CRC-32 using polynomial 0x04C11DB7 is deeply entrenched because of Ethernet, ZIP, gzip, and PNG. But CRC-32C, the Castagnoli polynomial, is often a better general-purpose choice. It has excellent error detection properties over common message lengths and is also supported by hardware instructions on many CPUs. Intel added CRC32 instructions with SSE4.2, and ARM AArch64 also includes CRC acceleration for CRC-32 and CRC-32C.

Of course, standards matter if you have to meet the standard. But if you are designing a new private protocol between your sensor board and your controller, blindly copying the first CRC-16 example from the Internet is not engineering. Pick a polynomial based on your packet length and your risk model.

The Practical Embedded View

For very small messages, even an 8-bit CRC may be adequate. For moderate packets, a good 16-bit CRC is often enough. For firmware images or large records, 32 bits is more reasonable. The point is not to use the biggest CRC you can tolerate. The point is to choose a CRC width and polynomial that give the desired detection strength for your longest protected message.

Also, remember what a CRC does not do. It is not cryptographic. It does not stop malicious tampering. The point of a CRC is to detect accidental corruption, not protect against sophisticated hacking attempts.

Real-world CRC definitions also include bit reflection, initial value, final XOR value, and sometimes byte order conventions. Two CRCs can use the same polynomial and still produce different answers because those parameters differ. That is a common embedded debugging trap. Someone says “CRC-16,” and both sides implement different CRC-16s. CRC-16/IBM, CRC-16/CCITT-FALSE, CRC-16/XMODEM, CRC-16/KERMIT, and CRC-16/MODBUS are not interchangeable.

If you specify a CRC in a protocol document, include at least the width, the polynomial (which can be represented in different formats, by the way), the initial value, if you use reflection on the input or output, and any value to XOR the output with. It is also a great idea to include the computed checksum for ASCII “123456789” so anyone can compare their algorithm to yours.

If you are working with Linux systems, be sure to look at the cksum program which can use several CRC algorithms or other methods like sha1 and other digest-style methods.

Efficiency

Computing CRCs a bit at a time is compact, but it costs eight loop iterations per byte. In some cases, that’s ok, but for performance, you want a table if you can afford the memory. For a 16-bit CRC, the table is only 512 bytes and can be generated at compile time, if desired.

Many CPUs have CRC peripherals. Use them, but read the fine print to make sure they can handle your desired CRC. It is often a good idea to check a hardware implementation against a known-good software implementation before you send it out into the wild. You can do many CRC tests using an online tool. Of course, there are several out there.

Choosing a CRC Today

For a new embedded protocol, define the maximum length of data you need to check. Then decide how many bits of overhead you can afford. Then head to Koopman’s tables to pick a polynomial with good Hamming-distance performance for that length.

The CRC has been around for a long time. But it isn’t just something you grab off the shelf. You need to plan and understand the ramifications of picking different polynomials.

CRCs aren’t the only game in town. Credit card numbers, for example, use check digits. There are other ways you can identify and, in some cases, zap bit errors, too.

After scathing accusations of skimping on due diligence, as well as other feedback to my article on trying to use an ‘AI coding assistant’ for the first time, the only rational, academic response is to lick one’s wounds following a particularly bruising peer review and try to address the raised issues. Reality after all does not care about one’s feelings, and there may be more to this AI assistant technology that can be coaxed out with a more in-depth look.

To this end I’ll do my best to try and work through each raised point, criticism and accusation, to see what I – and perhaps others – can learn of this endeavor. Said points include the use of the wrong frontend – i.e. Copilot – and the wrong model – being Claude Haiku 4.5 – as well as the egregious flaw on my end of ‘prompting wrong’.

For the sake of due diligence the best frontend and models will be investigated for particular tasks, with finally the verbal minefield of ‘prompt engineering’ examined for industry-standard approaches.

Junior Developer

The exact way to refer to an LLM coding assistant is still in flux, with some comparing it to pair programming, while others see the assistant more as a glorified search engine that also has code-complete features as a kind of merger of a web search engine and IntelliSense in Visual Studio. This relationship and how to look at it is the cause of a lot of contention as a result.

Another perspective is that of these assistants being more like junior developers. After all, they can apparently do all the basic boilerplate stuff, write unit tests and perform a range of other basic tasks that are beneath more senior developers. The corollary here is then of course why companies would even want to hire another junior developer if the LLM can fill these jobs. Unsurprisingly, it is already being reported that this happening.

The million dollar question that remains is that if all of this is true whether a junior developer still has value. The answer appears to be ‘yes’, even if you ask Microsoft. The argument would appear to boil down to that these assistants supposedly automate away a lot of the tedium that used to get pushed onto junior developers, leaving them free to develop more advanced skills, naturally supported by the same coding assistants.

Fancier Automation

This gets us to the question of whether these assistants are really much better than the automation tools that have existed in IDEs for many decades now with arguable improvements over time. They certainly do seem to be more capable, but they’ll still never exceed their programming, and require a lot of finagling to make them do the right thing.

Returning to junior developers for a moment: bad apples aside, they will let you know if they didn’t understand something correctly, ask for clarification, admit that they don’t know something and offer to look something up in the documentation if they do not know. None of these are things that these glorified chatbots are capable of, which makes a comparison with IDE automation tools rather fair, especially since junior developers tend to get fired if they screw up as badly as the LLM tools seem to regularly do.

While it’s true that these newfangled coding assistants do have a context window in which they “remember” previous details, you’re still dealing with the limitations of the underlying model no matter how good your prompt engineering skills are. They will also regularly confabulate and you have to accept that they generate code and documentation that is just as likely to be correct as completely wrong, even if many users of these tools seem to believe that they are actually more performant.

Ergo you’ll be writing test cases for the test cases and generated code, while also pulling code review duty, as there is no possibility of ever establishing a level of trust. Especially not after it deletes your entire hard drive or the production database for the second time that week.

If that sounds like the kind of junior developer or automation tool you’d love to be paired up with, then you’re quite the adventurous spirit. Meanwhile I have had enough fun with even code completion tools like the aforementioned IntelliSense or its equivalents in the various other IDEs that I have used over the years to never use them again. It’s bad enough when a code completion tool gets it wrong, it’s worse when the human in the loop fails to catch the glaring mistake.

Model Frontends

Although we generally refer to ChatGPT, Claude or Copilot as an LLM, this is technically incorrect, as these are merely the chatbot frontends that are written to provide a natural language interface experience. The choice here is naturally quite dizzying, as you have a range of major players including the aforementioned, each of which offers a web interface as well as integration with various IDEs and use on the CLI for easy automation.

Hence the claim that one should never use the web frontend for coding, as it needs access to your code and local environment, which makes sense if you want more of the pair programming experience. Since my ‘IDE’ of choice are Notepad++ and Vim, my options here are of course rather limited. There is a third-party OpenAI integration plug for NP++ called NPPOpenAI, but that would seem to be it.

The cool kids are of course all using Visual Studio Code with direct integration of all the frontends, but that option seems about as appealing as ripping half the RAM out of my PC and smashing my fingers with a hammer. Even as a former avid Visual Studio Pro user I feel insulted on a fundamental level at the mere thought.

Maybe that one of the CLI tools like Copilot CLI are a better match for me here as suggested, but this would appear to be more of a way to automate various GitHub tasks. Despite searching around I could not find an objective comparison of the different frontends, just many strong opinions and various pricing plans for model access, so for all intents and purposes they’re being treated as the same.

The Model Catwalk

It was further suggested that I take a look at LiveBench.ai for a comparison of how models perform on various tasks. This does indeed appear to be a valuable resource, if only for providing what appears to be a fairly objective way to compare these individual models against each other.

When sorting by the heading Coding Average, it puts OpenAI’s GPT-5.2 Codex at the top, with Claude 4.7 Opus Thinking High Effort close behind at both a hair over 83%. The Haiku 4.5 model that I was using comes in at a mere 72.17%, which is still much better than the sub-60 percent models near the bottom. Of the free models Haiku 4.5 at least would seem to be not too terrible, with Anthropic marketing it in October of 2025 as equivalent to Sonnet 4 when it comes to coding performance:

Consequently, it would be expected to perform at least decently at given tasks, but we can take a look at what other models are available via GitHub Copilot, for instance.

If you’re not into shelling out any clams for a purported improved experience with at least the Pro+ – not Pro – subscription, you get access to quite a few models to pick from that are apparently not ‘premium’. Of note here is that new sign-ups are currently ‘paused’ as usage-based billing is being introduced.

Of these available free models the following would have theoretically performed better according to the aforementioned benchmarks:

• GPT-5.4 Mini, at 74.70%.
• GPT-5 Mini, at 76.07%.

Following the ‘fast and cost-efficient’ category things get a bit dicey to compare, due to Anthropic’s awesome naming scheme and apparently an additional mode you can use these models in, which may or may not apply here:

• Claude Sonnet 4.6 (Thinking High Effort), 79.9%.
• Claude Sonnet 4.5 (Thinking), 80.36%.

These are apparently ‘more versatile and highly intelligent’, which doesn’t seem to bump up their total score too much compared to the mini models. Following this we get the ‘most powerful at complex tasks’ models:

• GPT-5.4 (Thinking High Effort), 78.18%.
• GPT 5.3 Codex (High), 78.18%.

Taken at face value, the 72.17% for the Haiku 4.5 model is indeed somewhat worse than the other two mini models, yet as this points system relies on a specific methodology it’s important to consider what this means. From the underlying coding tests we can see that they are all Python-based programming examples, which is great if you’re testing Python coding assistants, but rather useless for my purposes as I program in just about any language except Python.

Perhaps more worrying here is the statistic that even in this scenario the best model (GPT-5.2 Codex) only managed to score a rather pitiful 83.62%, so your choice would seem to be roughly between ‘atrocious’ and ‘very bad’. Within the free model selection you’re choosing between roughly 28% and 22% of the answers being incorrect, or roughly a 3/4 chance of getting what you were asking for.

Statistically, this wouldn’t seem to make much of a difference when picking either model.

Prompt Engineering

On my last foray, I was also accused of “prompting the wrong way”, which brings us to the topic of prompt engineering, where you must learn to follow specific rules in order to “correctly” use one of these coding assistants. A crucial aspect that was not obvious to me is that you absolutely must use so-called ‘environmental prompting’, where you set the equivalent of global variables.

To this you then add instructions, such as in the absolute gem that is used by the Livebench code test for an array test:

### Instructions: You are an expert Python programmer. You will be given a question (problem specification) and will generate a correct Python program that matches the specification and passes all tests. You will NOT return anything except for the program.
### Question:
You are given an integer array nums and an integer k.
The frequency of an element x is the number of times it occurs in an array.
An array is called good if the frequency of each element in this array is less than or equal to k.
Return the length of the longest good subarray of nums.
A subarray is a contiguous non-empty sequence of elements within an array.

Example 1:

Input: nums = [1,2,3,1,2,3,1,2], k = 2
Output: 6
Explanation: The longest possible good subarray is [1,2,3,1,2,3] since the values 1, 2, and 3 occur at most twice in this subarray. Note that the subarrays [2,3,1,2,3,1] and [3,1,2,3,1,2] are also good.
It can be shown that there are no good subarrays with length more than 6.

Example 2:

Input: nums = [1,2,1,2,1,2,1,2], k = 1
Output: 2
Explanation: The longest possible good subarray is [1,2] since the values 1 and 2 occur at most once in this subarray. Note that the subarray [2,1] is also good.
It can be shown that there are no good subarrays with length more than 2.

Example 3:

Input: nums = [5,5,5,5,5,5,5], k = 4
Output: 4
Explanation: The longest possible good subarray is [5,5,5,5] since the value 5 occurs 4 times in this subarray.
It can be shown that there are no good subarrays with length more than 4.


Constraints:

1 <= nums.length <= 10^5
1 <= nums[i] <= 10^9
1 <= k <= nums.length

### Format: You will use the following starter code to write the solution to the problem and enclose your code within delimiters.
```python
class Solution:
def maxSubarrayLength(self, nums: List[int], k: int) -> int:

```

### Answer: (use the provided format with backticks)

With this kind of preamble and explicit instructions to the ‘coding assistants’, you may as well just write the code yourself. Even if further brevity is usually ‘good enough’, the need to spend all that time and effort just to get the answer that you know you were looking for. Even a junior developer wouldn’t need this much hand holding.

In this regard, the other uses that people have mentioned, such as bouncing ideas off the chatbot — “rubber ducking” — has merit, but often even talking to potted plants or going on that walk around the block can do just about as much with getting one’s thoughts in order, along with random web searches.

Whether to use “micro prompts” or larger tasks, whether to use the chatbot as a search engine or not, and whether to correct answers to previous prompts are all details that seem to be highly divisive among users of these tools, as is the topic of vibe coding, which some seem to embrace, while others dismiss it as an insult for their artisanal craftwork.

Local Models

There are many more things to cover here, such the use of local models vs these hosted ones, with all the gotchas of subscriptions, private data harvesting and the like that this entails, but that will have to wait for another article. It’s also interesting how much the subscription and usage fees (and limitations) are currently going up across the various services, making the idea of local models seem more attractive, if they are even worth it with such limited inference capacity available.

Suffice it to say that I have learned some things along the way of writing this article, while not changing my overall premise and conclusion of the previous article. Although I could have certainly picked a theoretically better model, this is hard to to substantiate without pitting the models against each other in STM32 CMSIS and Ada coding challenges. Based on the results in Python it’s hard to make the claim that it would have made an amazing distinction, but maybe not using a ‘mini’ model makes all the difference here?

Hopefully the better models won’t be removed from free access before I can even give this idea a shot.

There’s a thing that people who grew up on farms all share: a connection with food production that isn’t some mystical rose-tinted woo from a TV chef, but instead a practical general knowledge from being there on the ground. A glance at a crop in a field and you immediately recognise what it is, if it’s ploughing time you’ll know the soil type, and there’s always either too little, or too much rain. For a given foodstuff you’ll know far too much about where it came from, because if your dad wasn’t involved in its production, the chances are someone he knew was. You take this for granted, after all doesn’t everyone have this general knowledge? Seemingly not.

Hackaday is not a cooking channel, but I know we’re all interested here in how things are made. Shouldn’t that also extend to what we eat? It’s fashionable to follow a back-to-nature line that all commercial foodstuffs are somehow over-processed junk, but without the requisite knowledge you’re flying blind there. To know both how common foodstuffs should be made, as well as how they are made industrially, should be an essential for everyone.

Mm-Mm-Mmmm, Coagulated Milk!

So without further ado, it’s time to dive straight in with cheese, or to be more specific, hard cheese. In simple terms the flavoursome snack is matured fermented coagulated preserved milk, which sounds a lot less appetizing than what the cheese marketing people will tell you, but that’s the hacker’s truth.

The milk comes from lactating farm animals, in most cases cows, but as an example in my local supermarket I can buy sheep and goat cheeses too. A dairy herd is also a breeding herd, and after the calves are weaned the cow continues to be milked until the next time she’s brought into calf.

Pulling no punches here, in most commercial settings the calves are removed from their mothers very young and brought up on a kind of cow infant formula, which is without doubt rather cruel. I grew up with a small suckler herd in which the aim is to breed high quality breeding cattle, so ours were fortunate enough to stay with their mothers until they were naturally weaned.

The milk will be collected and refrigerated, and in most cases will be pasteurised, heat treated to kill bacteria. Some people will tell you this removes all the goodness from the milk which is a questionable assertion, given that what it really does is make the stuff easier to transport without going off, and stop people dying from milk-borne infection. In a cheese context some cheeses rely on un-pasteurised milk for their flavour or authenticity, but as I’ll explain later, in most cases this doesn’t make them a health hazard.

Gambling at the Bacteria Races

Cheesemaking is a fermentation process, and as with others, the point is to control the fermentation such that its by-products kill off the harmful bacteria and preserve the food before they can spoil it. In the case of beer or wine the alcohol from anaerobic yeast metabolism does this job, but in the case of cheese it’s lactic acid from a class of bacteria that produce it given the right conditions.

This is why un-pasteruised milk can be used without too much worry, as those undesirable bugs should be removed by the lactic acid. You need lactic acid bacteria to be present which could be a hit-and-miss affair growing them in the milk naturally, but here in 2026 you add them as a pre-prepared culture. The make-up of this culture would originally be derived from the terroir of the cheesemaking region, for example the bacteria where Emmental cheese originated produces gas which gives that cheese its characteristic bubbles. It’s here you see the origins of the different types of cheese, as alongside the different bacteria are local variations in technique which lend the final product its unique qualities.

The milk is heated to speed up the fermentation, the idea being that a warm temperature favours the lactic acid bacteria over the undesirable bugs that might spoil it. Once the lactic acid fermentation is mostly done, the mixture is turned into curds and whey by the addition of rennet. This is an enzyme that coagulates the milk solids, the fat and proteins, leaving a thin liquid, whey, as the leftover.

Rennet is another of those things that can involve some cruelty, as traditionally it would have been produced from the stomachs of young calves slaughtered for the veal industry. Sorry veal farmers — I have never knowingly eaten veal. Fortunately it’s now much more likely to be made commercially from an engineered fungal or bacterial culture, which is why you will see most cheeses labelled as vegetarian.

The cheese is now a big tank full of curd, swimming in whey. The whey is strained off and the curd is broken up. releasing more whey. There is then a process of stirring the curd to release as much whey as possible, which yet again has an effect on the final cheese and is part of those different varieties, and eventually you have a pile of relatively dry fermented curds.

If you were Canadian you’d run off with some of it and make poutine, but sadly for me as a Brit we didn’t invent that marvelous street food, so we’d add salt before pressing it into moulds to make a basic cheese shape and extract the last drops of whey. We’d then wrap it in muslin and place it in a cool dark place to mature for several months. What you’d extract at the end would be covered in mould, but the cheese once you’d peeled off the muslin would (most of the time) be amazing!

Blessèd Are The Cheesemakers

So there you have it, that in a few paragraphs is how you make a farmhouse cheese. For us it was on a small kitchen-table scale for our own consumption, but it would be substantially the same for any small-to-medium farmhouse operation. Even the large-scale factory cheese operations do the same thing, with the key difference being that they require the process to be efficient and optimised, but above all consistent.

Remember I said that our cheese would be most of the time amazing? Cheese can go wrong, it can get infected with a bad bacteria, it can ferment differently, and it can taste, well, not so good. We could afford to lose a few cheeses, but a multi-million-dollar company can’t. So their process is controlled to the n’th degree, and out slightly hit-and-miss steps are eliminated. The hygiene, temperature, humidity, and every other possible variable are controlled exactly, to ensure that every cheese they make has the same flavour and texture, and time from milk to finished cheese is the same every time.

If I were asked, I would say that a commercial cheese from my supermarket is entirely as good a product as the most artisanal of farmhouse cheeses, and I think in terms of nutrition and quality, I would be right. Of course the farmhouse cheese would almost certainly taste a lot better because its production schedule is optimised for those qualities in a premium product rather than for low price, but I think it’s an important thing to say in order to head off those who’ll tell you that the cheaper stuff is not so good for you.

There certainly are cheeses that come closer to that, for example “pizza cheese analogue” which is a synthetic product, or plastic wrapped slices for which the name “Processed cheese” should be a clue, but in general if it’s “proper” cheese it’ll be real enough.

I hope now you know more about cheese from a hacker perspective rather than a culinary one than you did before you started. I’ve shared what I know about the agriculture behind it with an unflinching approach because I feel consumers should know what’s behind what they eat. Above all then, buy decent cheese, and enjoy it.

Featured Image: US Department of Agriculture, Public Domain

Among so many other technological advances, the Cold War saw the advent of the ballistic missile submarine. The concept was simple—pack enough nuclear warheads to destroy a small civilization into a compact metal tube, and then hide it underwater. The oceans would act as a cloak for your fleet of world-enders, and keep your enemies forever on their toes. A terrifying machine that could both start and end a war with the push of a button.

Most nation states are populated by humans with the will to live. Thus, there has been a great incentive to find ways to keep tabs on these sunken doombringers. Great efforts have gone into improving sonar and magnetic detection methods over the decades, which are the bread and butter of sub hunting to this day. However, military researchers have also explored the prospect of whether submarines could be detected via their effect on the gravitational field alone.

Do You Feel It?

The simple matter is that every object with mass has its own gravitational field. We don’t typically think about it, because gravity is the weakest of the fundamental forces. On anything less than a planetary scale, it’s generally not obvious to us in our daily lives. However, submarines are quite heavy and large, particularly those that are armed with a complement of nuclear-capable ballistic missiles. Thus is raised the prospect of detecting these massive objects via their perturbations to the local gravitational field. This has been a hot-button news item in military commentary circles of late, with much bluster that advanced measurement equipment could potentially render the ocean transparent and reveal the locations of submarines at great distances.

Naturally, it’s difficult to comment accurately on top-secret military capabilities from a civilian viewpoint. Such a technology would be game-changing in a strategic sense, to the point that any nation state with such a capability would have great reason to keep its existence strictly hidden. However, there is some literature on the topic that is in the public domain, which discusses just how hard this feat would be to execute in practice. A great example is a report prepared by the Pacific-Sierra Research Corporation in 1989, under the sponsorship of the Naval Air Development Center.

How It Works

When it comes to detecting the gravitational anomaly of a submarine, you might think it would be easy given the sheer mass of such a craft. However, the way submarines operate frustrates this at a very fundamental level. In normal operation, a submarine is neutrally buoyant, displacing an amount of water roughly equal to its own mass. Thus, the submarine is not really distinguishable from the water around it in terms of its first-order effect on the gravitational field, being roughly as heavy as the water that would otherwise be there.

There is a wrinkle, though, in that a submarine is bottom-heavy for the sake of stability. This does create a variance in the gravitational field versus the otherwise uniform field in open water, and it’s one that could theoretically be detectable with a sensitive enough apparatus.

The device used for measuring gravitational variation is called a gravimeter. They are essentially a special-case variant of accelerometer, specifically designed to very accurately measure the local acceleration due to gravity at a single point. Then there is the gravity gradiometer, which measures the spatial rate of change of gravitational acceleration. By virtue of measuring acceleration gradients, a gradiometer is not sensitive to the acceleration perturbations of a moving platform, making it particularly useful for use in a moving frame of reference such as towing behind a ship or aircraft. Various types of each instrument exist, from portable units to high accuracy laboratory instruments; creating an exhaustive list of all  variants is outside the scope of this article. The real question is, based on the gravitational anomaly generated by a large submarine, to what useful range could a gravimeter or gradiometer detect one?

Unfortunately, the maths says that you have to get very, very close. In the 1989 study, calculations suggested the best gravimeters and gradiometers in the world would maybe be able to pick up a large submarine from a distance of tens of meters, at best. The simple problem being that the gravitational anomaly generated by an underwater submarine, and the gradient of that anomaly, are both so small, that even highly sensitive instruments would struggle to pick it up when the submarine is practically in visual range. Even if the problem were simplified, and one were trying to detect a submarine as a heavy point mass in empty space, detection ranges would stretch to somewhere in the range of 100 meters at most. Of course, this would be largely irrelevant due to the neutral buoyancy considerations explained above.

It’s true that technology has moved on since 1989. We have more advanced gravimeters and gradiometers available now, including quantum units with greater sensitivity than ever. And yet, even with these advances, it would be still be a struggle to detect a submarine at useful range. Sensitivities would have to jump by four or five orders of magnitude to enable detection at ranges of 1000 meters. Even still, if this were achieved with some highly classified system, it would still be relatively limited in capability versus more established techniques in magnetic or acoustic detection.

The parameters of the problem, combined with the sheer weakness of gravitational forces, means that gravitational detection is not some silver bullet for tracking enemy submarines at great range. While it would be desirable to have some kind of sensor that could reveal where these nuclear weapon platforms are lurking at all times, that technology seems beyond the reach of even the most capable navies at this time. For now, strategic planners will continue to sweat over the threat these weapons pose, never quite knowing whether they’re lurking just off the coast or half a world away.

The 2000s was a decade of great change in the computer industry. The world had grown accustomed to corruptible floppy disks, blue screens of death, and achingly slow load times. In a few short years, all of that would change, as USB drives, better operating systems, and faster processors brought forth a new age of stability and speed.

Amidst this era of upheaval, Microsoft introduced a new technology. It was intended to increase performance on the cheap to a new generation of machines, but it would turn out to be little more than a gimmick that never really caught on. Let’s explore the easily-forgotten legacy of ReadyBoost.

Boost or Bluster?

When Windows Vista was launched in 2006, it was built to make the most of new technologies that were rapidly becoming mainstream in the industry. Chief among them was flash memory. The USB flash drive had risen to prominence as a defacto solution for removable storage, while digital cameras and PDAs had made Compact Flash and SD cards familiar items to many.

Microsoft engineers realized that this presented an opportunity. While flash memory was still only available in relatively small capacities at the time compared to magnetic storage, it had a special advantage of its own. NAND flash could offer far quicker reads for random access compared to spinning magnetic hard drives, which were subject to the mechanical limitations of their rotational speed and how quickly their heads could seek across a platter. Thus, the idea for ReadyBoost was born—to use cheap flash storage as a cache to speed up random disk reads.

ReadyBoost had some basic requirements. It could only be activated on USB flash drives or other removable flash media with a capacity in excess of 250 MB. That was the minimum cache size, with a 4 GB maximum size in the initial Windows Vista release. One could decide to dedicate a device to ReadyBoost, or only use a segment of its total storage capacity.

Only a single device could be used at a time for ReadyBoost in Windows Vista, formatted in FAT16, FAT32, or NTFS. The drive in question would be tested to determine if it could achieve 2.5 MB/s read speeds for 4 kB random reads, as well as 1.75 MB/s write speeds for 512 kB random writes, in order to make sure it would be fast enough to work as a higher-speed cache. Similarly, access times had to be below 1 ms for the device to be of use.Any space used for cache could not be used for storing files. The ReadyBoost cache itself was stored as a file called ReadyBoost.sfcache.

ReadyBoost could be enabled on a range of flash media, as long as it met the above minimum specifications. USB flash drives were an obvious choice, if you didn’t mind having a dongle hanging off your PC or laptop all the time. Microsoft also noted that SD cards could be a convenient solution for permanently parking a ReadyBoost cache in machines that had a card reader slot. You could also use CompactFlash cards, too, if so desired.

Approaching the time of release, Microsoft engineers noted that random read performance on flash drives was 10 times quicker than hard disks. However, on larger sequential reads, HDDs were still going to outperform most USB 2.0 flash drives available. Even in 2006, it was noted that the ReadyBoost system would make the biggest difference under high disk use and low free memory conditions. On machines with lots of RAM and during light usage, it didn’t help as much.

ReadyBoost was just one of a range of technologies that was implemented in Windows Vista to aid performance. Microsoft also developed ReadyDrive, which was intended to hurry along boot times with the aid of newly-developed hybrid hard drives that combined magnetic storage with non-volatile flash memory. There was also SuperFetch, which assessed which applications were most commonly used and preloaded them into memory to allow them to load faster. These technologies were both a little more background in operation, though.

Microsoft gradually improved ReadyBoost over the years. Windows 7 brought upgrades, allowing the use of up to eight devices with a cache capacity of 32 GB each—putting the total cache size maximum at a hefty 256 GB. The algorithm behind ReadyBoost was also improved, while newer, faster flash memory and interfaces aided performance further. The technology persisted through later Windows versions, until it was eventually deprecated and eliminated in Windows 11 version 22H2. One suspects this was because use rates were so low that it didn’t make sense to maintain the feature any longer.

How much difference ReadyBoost did make in the real world? While the basis of the technology was sound, it’s not exactly clear how many users actually bothered to use it. The impact was theoretically greatest on systems with slower magnetic hard drives and low RAM. This became increasingly less relevant as the industry moved towards larger amounts of RAM and SSDs as standard. For most Windows users, it remains a footnote in the operating system’s history—an interesting curio that helped in some edge cases, but was perhaps not a gamechanger except for the weakest machines out there. In the end, it couldn’t compete with the tried-and-true method of just having faster primary storage and more RAM in the first place. It might have helped out a bit back when underpowered netbooks were struggling along and RAM in excess of 2 GB was a luxury, but today, ReadyBoost just doesn’t make sense when every PC out there has a blazingly fast SSD under the hood. The times changed, and the world moved on.

If you were around tech in the bad old days, magnets could be really bad news. They were fine on the fridge, no problem at all. Put one near a floppy disk, or a hard drive, or even a computer monitor, though, and you were in for some pain. You’d lose data, possibly permanently destroy a disk or drive, or you’d get ugly smeary rainbow effects all over your screen.

The solid state revolution has eliminated a lot of these problems. We all use SSDs, flash drives, and LCD monitors now, all of which care a lot less about flirting with magnets. However, the same can’t be said about all our modern hardware, for a magnet could cause your smartphone some major grief indeed.

Magnetic Fields

As you might expect, the magnetic susceptibility of certain modern smartphones once again comes down to non-solid state parts. Now, there aren’t exactly a lot of phones out there that are packing hard drives or floppy drives or any sort of magnetic storage. Instead, it all comes down to cameras.

Take the modern iPhone line, for example. Apple is quite careful to warn against carelessly using magnetic accessories with the smartphone, because it can interfere with the cameras. Specifically, it’s because of the optical image stabilization (OIS) and closed-loop autofocus systems that are built into the cameras themselves. These devices use magnetic position sensors to determine lens position to compensate for focus, vibration, and movement, and use magnetic voice coil actuators to move optical elements, in order to take the best possible photos and videos at all times. If there’s a strong magnetic field in the vicinity of the lenses, it can interfere with this operation.

Few of us are sticking fridge magnets on our iPhones, to be sure. However, there are a lot of magnetic cases and mounts and other accessories that give people a great reason to stick magnets on their phone. In the cases of some third-party accessories that are poorly designed, it’s possible for these to cause problems with the camera if the magnets are too strong or too close to the key hardware. It’s worth noting that in typical use, something like a magnetic case or other small magnet won’t cause a lot of permanent harm. It will generally just degrade the operation of the camera until the magnet is removed.

This isn’t solely an iPhone problem, either. It can affect any phone that has any sort of magnetic sensing or actuation involved in the camera mechanism. Indeed, Samsung has even filed a patent on ways to mitigate this problem through carefully orientating the magnets used in folding phone mechanisms, and the appropriate use of shielding. Ultimately, similar camera technology is used in a great many phones, all of which are susceptible to this problem.

It’s true that in day to day use, you’re probably not going to run into a lot of problems waving around a magnet near your smartphone. Nor did floppy disks fail en masse in the 90’s, unless one of your colleagues was feeling vindictive and wiped them all with a fridge magnet on their lunch break. Still, like the oddball helium problem that because apparent with smartphones a few years ago, it’s funny to think that magnets could be causing trouble with computer hardware today. The fact is that a modern smartphone contains multitudes, and thus can surprise you with its edge case frailties.

Once upon a time, computing was simple. You had files on a floppy disk. If you wanted to take them to a different computer, you ejected the disk from one machine and put it in another. It wasn’t fast, but it was easy and intuitive. Besides, you probably only had one computer of your own, anyway.

Life has since gotten a lot more complex. You’ve got a desktop, a laptop, a work laptop, your personal and business phones, and a smart watch to boot. You live amongst a swirling maelstrom of terabytes of data. Despite all the technical advances that got you here, it’s still a pain to get a file from one device to another, even when they’re sitting on the same desk. Why?!

This Modern Glitch

Our computers are actually very good at connecting to each other. We have Ethernet devices with auto-negotiation, WiFi and Bluetooth in just about everything, and DHCP for good measure. It’s easy to get devices on the network and online. One might think all this connectivity would make sharing data easy. But we’re not so lucky.

Let’s take a straightforward example. Just getting a JPG off a smartphone requires jumping several hurdles and a little bit of begging to the benevolent tech gods. You can plug your phone in via USB to grab files, assuming you’ve got an Android, but you’ll have to flick through menus multiple times to get it to shift into the right mode to get files off. An iPhone will allow the same but you’ll need an app to help “import” them.

You could alternatively try sending them via Bluetooth, but you’ll have to go through the hassle of pairing, which almost never works first time. You’ll also get glacial transfer speeds and watching the process fail a few times. Alternatively you might see if your phone comes with a proprietary app for transfers, or you could try waiting to sync files to a cloud service or just emailing them to yourself. The latter method will make a mess of your inbox, but at least you get the files across when you need them.

It Was Not Ever Thus

It wasn’t always like this. Jump back a quarter century, and things looked very different. Windows 9x had a massive install base, with Windows XP just bursting on to the scene. You could still sneakernet stuff around with floppy disks if you wanted, of course. But it was also a cinch to set up simple network shares to access files across machines on a home network. It just worked.

Much the same was true of the Macintosh ecosystem. Back then, smartphones weren’t a thing, and few of us were carrying any sort of device with any real amount of data. Things like digital cameras and MP3 players would soon rise to prominence, but getting files on and off them was a dream—simply plug in, and they’d present as a USB mass storage device. No drivers, no passwords, no bloated apps. Just peace.

Of course, that would all change a few years down the line. Take the Windows world as an example. Network shares still exist, and you can set them up if that’s what you really want. Unfortunately, though, they’re so much worse than they used to be at the turn of the century. They’re buried under layers of permissions and user account nonsense that makes enabling them absolutely arcane. Only some of us run multi-user logins on individual machines, even fewer of us choose to run domain-style networks in our homes. In contrast, a lot of us would like it to be easy to pull a few files off the loungeroom computer when needed. However, doing so requires navigating passwords and accounts and setting permissions and if you get the slightest bit of it wrong, you won’t even see the shared files, let alone be able to access them. A task that used to take 3 minutes of setup now takes half an hour or more and a couple trips to Knowledgebase.

It shouldn’t be like this. One can imagine a world where all our devices in the home are allowed to share files openly and freely. Imagine if you could just click into the network tab on your PC, and see everything across all your devices – your laptops, your phones, your desktops and lab machines. Imagine not having to pair your phone or fiddle with utilities or special sharing tools or, god forbid, sending files all the way to the cloud just to move them three feet across your desk. Imagine this, all your files across all your machines at the click of a button, no auth, no nonsense, whether Apple, Windows, or Android. You already have all these devices talking on the same network, so all your stuff should just be there!

Alas, we cannot have such nice things. It’s not just because Big Tech is full of mean people that want to make life worse than it used to be, but it can feel that way sometimes. Instead, it’s more because of boring, sad, practicalities that are difficult to overcome. Security is perhaps the biggest headline issue in this regard. We now use our personal computers to store more private and confidential data than ever.. This makes access control paramount to avoid bad actors getting access to compromising information. There’s also the need to prevent the easy spread of viruses, which becomes very difficult when there’s a permissive file sharing route between devices. Malware has often taken advantage of holes in network sharing protocols as a vector for infection.

Beyond this, there’s the simple problem of interoperability. There isn’t a uniform standard that would allow easy, secure file sharing across laptops, desktops, and smartphones of all makes and models. This would require a large number of different tech companies to all get together, define a solution, and agree to implement it going forward. Sadly, current thinking seems to be that the proprietary solutions we have today are “good enough.” Apple’s AirDrop or Samsung’s Quick Share will get you by if you stay in the right walled garden, for example, and neither cares much to start a dialogue to establish something better and more cross-platform. Few tech companies would be excited about opening up potential security holes by implementing a new broadly-accessible file sharing protocol, either.

Perhaps a metaphor best explains the misery we find ourselves in today. If you live in a safe town with low crime, you might not feel the need to lock your car doors when you pop down to the supermarket. It means you can get in and out of your car without fishing for your keys, which is a great convenience when you’re carrying a bunch of heavy grocery bags. At the same time, you can’t live like this in a nastier place. Bad actors will simply open your door, rifle through your car, and take anything they like. That could end badly for you.

Unfortunately, cyberspace is that nasty place. By and large, we can’t just freely share files between devices because it’s too dangerous to do so. You don’t want your bank accounts drained, or your personal photos used for blackmail, so we have to drench everything in layers of authentication, even in the privacy of our own homes. Perhaps one day there will be some framework that allows us to create a close-knit network of “trusted” devices so we can freely move data about our own protected little bubble. But until then, we’ll have to suffer with Bluetooth passcodes and proprietary apps and the fact that it’s usually quicker to email a friend a photo then to find a way to directly transfer it to their phone which is sitting right next to you. It’s an annoying problem, and one that will not easily be solved.