tardate 2026

LLM Limits: GPUs or Data?

Mon, 09 Mar 2026 10:00:00 +0000

Large Language Models (LLMs) are statistical inference machines that project from available data and training sets. When they stray beyond the data, they hallucinate. Which may be a good thing, depending upon your intent. But usually not. LLM advances in the past 10 years have largely been constrained by the capital and supply-chain wizardry required to put farms of GPUs on the job of training the latest model. But are we reaching the point where DATA becomes the strangling bottleneck, not GPUs?

The Bait And Switch

Remember the early days of AI hype, promising to cure cancer and solve climate change?

Well, … no. Things are a lot more prosaic these days.

In his 2026 presentation to the Royal Society, Professor Michael John Wooldridge explained how the LLM breakthroughs of the past 10-20 years really just boil down to the ability to apply scale (i.e. lots of GPUs and storage) to a simple and elegant idea - the transformer.

What was the training data that the model builders were using? Andrej Karpathy famously characterised model training as a lossy compression of the Internet.

While Common Crawl remains a good starting point for experiments, leading efforts such as OpenAI GPT-family models are trained on combinations of:

Public web data
Licensed data
Human-created data
Code repositories
Books and reference materials
User interactions

Which sounds great. All of human knowledge in a bottle!

But not quite.

I’ve noticed that people in tech, especially, over-estimate the completeness of the Internet. After-all, the early Internet cultivated an apparently self-evident truth that information wants to be free .. as documented by Steven Levy in Hackers: Heroes of the Computer Revolution.

So how much information, and more importantly knowledge, is readily machine-reasonable? Some may be surprised that is is still a relatively small fraction, likely <5–10% of all recorded human knowledge.

If you include all tacit knowledge: far less than 1% is represented.

A quick thought-experiment may help:

Think of your last job, and the key activities you were occupied with to be successful day-to-day. How much of that was captured, written down, and stored somewhere?

For most people, even in very digitized roles, the answer is somewhere between “none” and “very little”. And that is how much data the AI has to work with.

Does it matter though?

A casual interaction with an LLM may appear satisfactory. That may be a low bar, as the roasting that Richard Dawkins got for his Claude Delusion illustrates.

My retrospectively-enlightening career is festooned with examples of good intentions boldly proceeding before an absence of data. To wit…

Skinny Data

Data, though rich an voluminous, does not contain the necessary detail

I recall conducting a machine-learning exploration on 12 years worth of customer support data. Multiple gigabytes of valuable digital dust.

It was successful to a degree: the model could predict resolution categorization with a high degree of confidence.

But it couldn’t determine exactly how to resolve a given case, because the actual technical steps and details were not recorded in the dataset.

So if you wanted to build an AI replacement for the support agent with this data, what you’d get would go something like this:

Customer: I seem to have problem X with these symptoms Y and Z. Can you help?

AI: Of course we can! Based on my training data I can confidently say that our resolution would be “Network Configuration”

Customer: er, ok? So what exactly should I do?

AI: You are right, perhaps my instructions were not clear. If you need further help, call our interactive voice-assisted ChatBot at 1-800-FUCK-OFF. I am sure they will be able to resolve your inability to follow our instructions

As the basis for anything remotely useful or intelligent, it turned out that the data was pretty much useless.

The data-capture challenge was that much of the real action happened “off-screen”. If the support agent needed to swivel and ssh into a remote device … totally transparent. Or consult with a colleague … unrecorded. Or use an air-gapped device to do some queries .. unmonitored.

It’s almost as if 90% of the job did not leave a digital footprint.

Correct!

And that was for a technical job. Imagine how much of a non-technical job fails to leave the digital footprints that an AI requires. 98+%?

Key learning:

Most “jobs” do not leave a meaningful digital footprint. If you want to capture the details, you will need a specific data capture initiative.

Meta may have belatedly wizened up to this deficit in their datasets, before it was revealed that they would start capturing employee mouse movements, keystrokes for AI training data.

Shadow Data

The data is out there, but it can’t be accessed

I’ve noticed this is a particular problem with historical research, as an example.

If one is looking for specific information, such as aircraft tail codes and operations logs, or uniform details for specific information, the information may exist somewhere - but it is in a book on a shelf, in a museum, library, or archive, and definitely not part of the training data, or accessible by search.

AI responses on such topics will be lacking in the necessary detail, or worse, fictitious.

If one were to ask, for example, about the uniforms worn by the Japanese in Peleliu, we get:

Olive-drab or khaki cotton tunic and trousers
Often faded to light brown, tan, or greenish-grey from tropical exposure
Many wore simplified tropical shirts instead of full tunics
Puttees (cloth leg wraps) or canvas gaiters
Split-toe tabi shoes or hobnailed ankle boots

i.e the equivalent of

y’sir, he kinda looked japanese

Not useful! There is a great deal of information that is not generally accessible, or yet to be digitized. Rather than deliver glib deceptive answers, it would be far better if the concerned agents were able to promote relevant digitization efforts.

Data Black Hole

No-one thought to collect that data yet

Early in my career, I was involved in projects to improve predictive machine maintenance.

The problem was: the machines didn’t produce any data.

So the first step in most projects was to figure out what data you really needed, and how to collect it. It was usually a non-trivial exercise in itself; often the bulk of the dollars spent.

And these projects were successful, but for very bounded problems.

These days, people often assume the data is a given, or simply subject to a price for access being agreed.

But no. So much or the world remains inaccessible to machine-reasoning.

Key learning:

Do not underestimate the challenge of capturing “all the data”.

The Best Datasets

Hang on, I thought we were supposed to be curing cancer, solving climate change, or something equally important?

But no, we’re optimising software development instead!!!!

It is no surprise that “coding” is the domain within which AI agents got really good.

Coding presents the most complete and self-contained dataset, with much of the technical field available for AI training from books, blogs, and open source repositories such as LeetCode-Solutions, and an almost infinite selection of example TODO list implementations.

So we proclaim “job done”! … before remembering we were meant to be solving more important problems.

Are we selecting the best data to solve the most important problems, of finding the easiest problem that the most available data can solve?

Remember 2015, the year the world declared developer productivity as the most imminent threat to humanity?

Wait, no! It was water crises and interstate conflict.

Has AI helped solve those problems? Well, no…

But At Least AI Can Code

Hmm, AI still falls short at just generating code.

In my experience, the biggest challenge in software engineering is “figuring out what people want/need”.

Call it requirements analysis, UX design, or just consulting - bringing clarity to the messy mix of inter-personal and business incentives was always the more critical (and challenging) part of project.

The part that AI is far from being able to master.

Where To From Here?

More Data

If we pursue the LLM paradigm, then clearly what we need is more data.

Current LLMs, no matter how good they appear to be, are working on datasets that represent less than 1% of all knowledge.

But all the easily accessible data has already been plundered.

QED: LLMs need a massive data collection exercise, like Meta’s MCI.

But surely this as an exponential race to the bottom? As fast as GPUs can process, we need even more data to ingest. I am picturing a lecturer’s chart scooting off to the top-right…

Unbounded by Data

Or perhaps LLMs are an evolutionary dead-end?

Ineffable Intelligence was founded by David Silver in November 2025 to chart an alternative path: focus on developing reinforcement learning algorithms that would have the ability to endlessly discover knowledge and skills, rather than the transformer approaches that are fundamentally bounded by the data they have available.

Translated, I believe this simply means:

rather than just work on data we are given
we will go collect data for ourselves

Presumably with suitably Black Mirror-esque data appendages and sensors to cross the machine-ecosystem boundary.

Composability

I’ve been increasingly drawn to the concept of job composability as a way of thinking about AI impacts on the workforce.

Task composability is a design principle where complex workloads are broken down into smaller, independent, and reusable “tasks” that can be easily combined or reconfigured to create new workflows.

Most AI pitches assume they can do the “whole job”. But real people know this is BS.

So the question becomes: can AI do a little bit of the job, and a human do the rest?

It depends on whether the task is composable or not.

A good example of a composable task could be content marketing: an AI can independently take care of Research & Data Gathering, while a human can take care of selecting appropriate sources and tailoring the pitch for the client.

Typical characteristics of non-decomposable tasks:

Lack of Objective Truth: Tasks where the “correct” answer depends entirely on subjective human values. e.g. writing a sympathy card for a friend
Tacit Knowledge: Skills that are learned through physical embodiment rather than data. e.g. how to master kigumi
High-Stakes Accountability: Roles where a human must “own” the moral consequences of a decision. e.g. someone must be on the line for this forecast call!

Conclusion

So this is the rational middle-ground: LLMs are not worth the trillion dollar valuations, but they can be useful in the routine course of working a task.

I just hope that someone gets stuck with that AI training bill, like the investors who paid for the Global Crossing bankruptcy and unwittingly ushered in the era of “effectively free” global communications!

AISLE: The End of Zero-Days?

Wed, 11 Feb 2026 05:00:00 +0000

AISLE have been developing a complete AI workflow for deep cybersecurity discovery and remediation, and if their Wall of Fame is any indicator of potential, they may prove to be one of the most transformative companies to emerge from the AI bubble.

I must admit to being a little jaded. Where are all the AI startups delivering meaningful breakthroughs?

We were sold a vision of AI curing cancer, ending the climate crisis, and eliminating poverty.

Instead, much of the commercial narrative seems to have fixated on workforce reduction and generating a tidal wave of AI slop, along with a huge power bill.

So I wasn’t expecting to be impressed when I heard about AISLE on Security Now #1063.

But I was.

It’s 2026, and we still treat vulnerabilities as “Normal”

Since computing’s original sin of mixing code and data, security has been a cat-and-mouse game. We’ve made enormous advances in system and network security, yet we still accept one assumption as inevitable:

There is no such thing as bug-free code.

As developers, we follow secure coding practices. We run static analysis. We adopt DevSecOps pipelines. And still, vulnerabilities ship.

Our experience with AI coding tools such as Claude Code and GitHub Copilot is mixed. They fix some bugs, hallucinate others, chase red herrings, and lack a true closed-loop workflow for discovering and eliminating security flaws.

What is AISLE doing differently?

AISLE’s ambition is simple and radical: software released with zero known security vulnerabilities. Where software is assured by AISLE to be free from security vulnerabilities before it is released.

The company emerged from stealth in October 2025. In the absence of reliable cybersecurity benchmarks, they targeted live, heavily audited open-source projects including:

OpenSSL
curl
Firefox
Linux
OpenVPN

The results have been remarkable:

OpenSSL security patch of 2026-01-27 addressed 12 new zero-day vulnerabilities - all discovered and remediated by AISLE
curl 8.18.0 released January 8, 2026, AISLE was responsible for 3 of the 6 CVEs

If accurate, that’s not incremental improvement. That’s industrialized vulnerability discovery and remediation.

AISLE appears to be succeeding not by building a better autocomplete engine, but by creating a full AI-driven workflow dedicated to one problem space.

Is “Zero Vulnerabilities” Realistic?

For many of us versed in the “old ways”, this sounds too good to be true! And to be sure, if software is free from security vulnerabilities, that is not the end of security issues.

Even perfect code doesn’t eliminate phishing or credential theft. Humans will always remain part of the attack surface.

But removing exploitable software flaws changes the economics of cybercrime dramatically. No zero-days means fewer catastrophic breaches.

Another AI Unicorn?

AISLE emerged from stealth backed by angel investors. No major institutional round or valuation has been disclosed yet.

But if their trajectory continues, they may become something rare: not the first AI unicorn, but possibly the first AI unicorn to actually do something significantly good for the world!

What Happens Next?

The obvious path is integration into CI/CD pipelines with a security assurance as a subscription service. One can request a demo, but I’ve not yet seen any pricing.

Longer term? Pure speculation, but I would not be surprised to see a rapid exit and acquisition. My bet would be Microsoft:

to use internally:
- A world without Windows security patches, because there are no vulnerabilities to fix!
to integrate with Microsoft-owned GitHub as a value-added service:
- A perfect pairing or upgrade to the existing Dependabot and Code Scanning services
- A must for enterprise clients, while ensuring the open-source supply chain that so many companies rely on is kept free from issues

If AISLE can assure software security before release, “reasonable industry practice” changes. Releasing vulnerable code may eventually be considered negligent under the law, with the old “no liability” boiler plate in license agreements challenged in court. Be prepared to defend why you are not using a service like AISLE!

References:

AI in the Call Centre

Tue, 03 Feb 2026 05:00:00 +0000

AI is decimating call centres, but two can play at that game! Inspired by true events😂

Tyranny of the Urgent

Thu, 08 Jan 2026 06:00:00 +0000

The Agile Embedded Podcast is as thought-provoking as ever with their take on the Tyranny of the Urgent. The discussion focused very much on how the agile mantra of creating immediate customer value can lead a team astray, but it made me think of all the other ways I’ve seen and experienced the “Tyranny of the Urgent” over the years.

Three thoughts came to mind:

We’re Not Being Honest about Impact and Urgency
We are ignoring the Full Feature Lifecycle
When Things are Always Urgent, it may just be a Capacity Problem

Tyranny of the Urgent: An anti-pattern where short-term urgent demands systematically override long-term important work, causing reactive behavior and worsening future urgency.

Problem 1. We’re Not Being Honest about Impact and Urgency

Task priority should be a factor of both Impact and Urgency. This is as true in agile environments as elsewhere. It’s a common prioritisation technique that appears in many guises (in project management, ITIL support, Eisenhower matrix, PICK Charts) but as a concept is trivially simple.

No matter how a team calculates priority, it is very sensitive to the fact that both impact and priority are hard to quantify and extremely subjective.

In reality, I’ve often had to deal with, let’s say “misleading”, assessments of impact or urgency. For example:

the product owner claiming a feature is critical based on an imaginary concept of the customer
- i.e. trust me, I know what the customer needs without any data or actual customer input to back it up
- it can be a symptom of a team that is far past their initial requirements efforts and is now coasting.
- Solutions?
  - without being rude about it, find a way to reset expectations around validating requirements before they are accepted for development.
  - Discuss the “definition of done” for a story/requirement itself.
  - May need a jolt to re-engage meaningfully with the customer group, perhaps with a new round of focus group, customer surveys, or customer visits.
a sales person claiming features are deal-breakers for a new customer and must be urgently delivered to close the sale
- sometimes this may be true, but in many cases I’ve discovered it’s not (most painfully, after the fact)
- it may be “lazy sales”: passing the buck to development rather than do the hard work of selling the solution as-is and overcoming customer objections
- but it can also be a skills gap: sales or pre-sales don’t know the solution well enough or have the requirements analysis skills to help best assess the solution fit and gaps for the customer
- Solutions?
  - the main way I found to battle this is greater involvement of development in the pre-sales process, proposal design and review.
  - it may point to a lack of training on your product with the sales, pre-sales, or customer care teams
whatever the C-suite says this week is the most urgent and important thing to work on
- i.e. if you have the authority, you can bypass whatever process is in place for product management
- This can be tough, because at the end of the day “the boss is always right”!!
- I’ve mainly seen this in places where senior management either don’t understand the processes used to manage product development, or they don’t trust it to deliver the necessary results
- Solutions?
  - invest time in building the stakeholder relationships and educating them on how development works.
  - nothing beats a good track record to build trust.
    - if execs only hear about development when things go wrong, they’ll think that’s the norm
    - make sure to provide regular updates that include all the good news about the process working correctly

Problem 2. We are ignoring the Full Feature Lifecycle

The podcast did touch on the Three Horizons model for ensuring there’s always an innovation pipeline, but on a smaller scale I’ve seen insufficient attention paid to appropriately balancing effort across the full lifecycle of features.

The most common anti-pattern I’m sure we’ve all seen is all effort consumed on new feature development, and only allowing for some effort to be clawed back to fix bugs. The team ignores the important work of taking features from good to great, and never gets around to retiring features that no longer add value.

I’m my own practice I’ve found “4Rs Feature Lifecycle Analysis” a very useful diagnostic to combat this. In essence, all stories get classified as belonging to one of the four stages of a feature lifecycle:

Stage 1, Reveal: new feature development
Stage 2, Refine: improving a feature
Stage 3, Rectify: fixing bugs, CVEs, updating dependencies etc
Stage 4, Retire: removing the feature when it no longer has sufficient value

Looking at where effort is bucketed makes it very clear if the product management process is delivering a pipeline of work that matches the maturity of the product. i.e.:

during initial product development, one expects most effort to go into new feature development
after launch
- if one is not seeing a shift towards refinement, it may indicate we are stuck in “new feature mode” and are not taking the time to improve the “v1” features already launched
- and if we see rectification starting to swamp feature development, it may indicate systemic quality issues
in very mature products, we’d expect to see effort largely shift to rectification and ideally an uptick in retirement effort

If we are using agile software development process, isn’t Feature Lifecycle Analysis redundant? A well-balanced and high-performing team should be able to find the optimal balance by trusting the process:

customer/business requirements rule, and are represented in the team through a product owner or even an onsite customer
we prioritise work for each iteration as a team, balancing customer/business requirements with other things that the team knows are important in order to meet customer expectations (like performance)
we keep our iterations short and continuously deliver working software, so even if we get things wrong we can course-correct in short order

That is of course the ideal. But we operate in the real world, and many things can upset the balance. For example:

Urgency Trumps Impact
- It’s easy to find a queue of people ready to argue for the latest urgent requirement, but there’s no-one around to champion the more impactful stuff that hasn’t also been called out as urgent. Result? Six months later, we’ve delivered all the urgent things, but 90% of the potential impact (“value”) is still on the table.
The New Shiny
- The new shiny trumps last week’s idea. This can be a problem in startups where the founder/ideas person is also the product owner. Excellent at generating new ideas, but no time or ability to follow-through. So the team leaves a trail of half-baked implementations but never seems to achieve anything great.
Uninspired Leadership
- The team is looking for insight and vision to drive priorities but just hears “meh”. So the results are naturally also meh.
Unreal Priorities
- A product owner who is (consciously or not) skewing priorities towards a certain theme or faction over all others, like one particularly vocal customer. Or perhaps lacking real customer insight, priorities are out of touch with reality.
Weak Team
- A weak development team that’s not able to put up a convincing case for something they believe is important.
Domineering Team
- Conversely, a development team that is too strong and always manages to spin the product owner to their way of thinking.
Group Think
- Although we use a strict planning game to prioritize stories, the team is suffering from “group think” and priorities end up skewed to one point of view.
ScrumMaster At Sea
- A scrum master that doesn’t recognise there’s an issue of balance until it is too late, or is running out of tricks to help the team fix it.

Feature Lifecycle Analysis is really just a diagnostic that can present in a picture what may otherwise just be a gut-feeling that something is not quite right.

Problem 3. When Things are Always Urgent, it may just be a Capacity Problem

We refined our scope to death, optimised all our processes, fine-tuned our tools, made all the improvements surfaced by our retrospectives, ensured all our people are well trained and working at their best… BUT we are still consistently failing to meet expectations for feature delivery.

We may just need to admit we have a fundamental capacity issue, and no amount of clever scheduling can plan our way out of the hole. Are we trying to do the work of an 8 person team with a team of 3?

If that’s the case, frankly it’s time for leaders to step up and either:

reset expectations with stakeholders
or make the case for investing in greater capacity

Listen to the Podcast

Yes, it is an old episode from 2023 but no less relevant for the fact. I’m busily catching up on back episodes;-)

After Pivotal Tracker

Tue, 21 Oct 2025 03:00:00 +0000

When Broadcom/VMware announced it was shutting down Pivotal Tracker effective April 30, 2025, it signalled the end of an era. And had me scrambling to find a replacement!

TLDR: I moved to BardTracker and LiteTracker.

Pivotal Tracker (PT) was created in 2008 by Pivotal Labs as an internal project management tool based on agile principles. It was later released as a commercial product but eventually became part of VMware Tanzu Labs after its parent company, Pivotal Software, was acquired by VMware in 2019. Following VMware’s acquisition by Broadcom, Tanzu Labs was shut down in early 2025, and PT was retired in April 2025.

2008: Pivotal Labs develops Pivotal Tracker for internal use.
2012: The company, now known as Pivotal Software, is formed.
2019: Pivotal Labs is acquired by VMware and renamed VMware Tanzu Labs.
2023: VMware is acquired by Broadcom.
2025: Tanzu Labs is shut down in January, and Pivotal Tracker is retired in April.

I was first introduced to PT while working alongside Pivotal Labs consultants on Rails projects in 2008/2009. For me, it represented the same simplicity and effectiveness in planning that Ruby and Rails brought to development itself.

I was converted, and while I’ve had to use many other systems before and since (Jira, Trello, bugzilla, even FogBugz and others), nothing has helped me to just get things done so well, without adding undue cost or complexity.

So like many others, I was in a desperate search for alternatives in 2024/2025, and even considered writing my own if I couldn’t find anything suitable. This was especially true as I’d long since internalised PT and used it for getting things done in all aspects of life.

The good news: I found answers and was able to smoothly migrate all my ongoing PT activity to alternatives. Here’s a quick summary of what I ended up using

BardTracker

I’ve moved all my personal and small project activity to BardTracker. It was specifically developed by Bot and Rose Design (BARD) as a PT replacement for their own consulting work, and they now offer it as a service for others.

What I like:

it has a nice free tier - perfect, especially for personal GTD/TODO lists
GitHub integration
looks and works similarly enough to PT
is really well supported. I’ve had very fast response to any issues or features requests I’ve raised.
it’s backed by an operating concern, so should have some longevity

To consider:

the UI is not identical to PT - there are differences, some of which may be significant for you
no API access (yet)
no mobile app, but mobile responsive view is quite OK

LiteTracker

It really is the most complete and “identical” PT replacement that has made it into full operation. If you want something exactly like PT, this is the best I’ve found. As it has no free tier, I haven’t adopted it for personal projects, but it would be my first choice the next time I start a new project with a larger team.

What I like:

every feature you ever liked from PT is here
it really is pretty much identical
after the initial focus on migrating from PT, they’ve continued to add migrations from other popular planning tools
now has a mobile app

To consider:

the developer API is still a work-in-progress
only paid tiers

For TV made as late as 1982, it brilliantly captures the immediate post-war period in Britain. From rationing and the black market, to social upheaval of returned services and the changing role of women in society, to the expectation of a new social contract reflected by the Beveridge Report and the Labour victory in 1945 - all are handled with convincing realism.
It features the forgotten history of the end of the British Mandate and the Palestine Emergency, with the Airline being dupped into smuggling guns for Zionist militias who were fighting the British at the time. The show deftly presents the moral dilemma that continues to dominate western politics to this day: sympathy and a need to atone for the treatment of the Jewish people in Europe up to and including the holocaust; yet discomfort with Zionist methods and all that means for others in the middle east, in particular the people of Palestine and Lebanon. For more on the period, I can highly recommend The Hundred Years’ War on Palestine by Rashid Khalidi.
Later episodes depict the Berlin airlift from a perspective I’d never considered before: the rapid assemblage of motley crews and operators to provide an airlift capability that had been unceremoniously moth-balled at the conclusion of WWII. For more on the history, I really enjoyed reading The Berlin Airlift by Robert Jackson.
Finally, if you appreciate the DC-3/Dakota - it is really the star of the show. There is lots of footage of it in the air and on the ground, in pieces and various liveries. And as a bonus, the show regularly co-stars a period Austin Tilly.

In short, so many aspects of the story and production will have one thinking: “crikey, forgot about that!” Or even, “crikey, never knew that!”

So what’s not to like? Well in short: “Jack Ruskin”. This is a lead character you will learn to loathe, as does his fiancée who ends up leaving him by the end of season 1. For all his drive and passion to establish a new airline, he manages to be obnoxious to all concerned, far beyond just being a “blunt no-nonsense Yorkshireman”. Perhaps the main reason there is no season 2, is that there’s no amount of success he could have with the airline to redeem him as a character!

Airline: The Synopsis

After the end of the Second World War, Jack Ruskin, a demobbed pilot, attempts to make a living from his one-plane airline business.

Newly-discharged from the RAF after World War II, Jack Ruskin, a blunt no-nonsense Yorkshireman, decides to set up his own airline, Ruskin Air Services. Something of an idealist, Jack is prepared to bend every rule in the book to achieve his goal of flying a Dakota once again. He soon does a deal with Ernie Cade, a notorious spiv who can lay his hands on any item of war surplus - for the right price - and then enlists Peter Witney as co-pilot and Jock McEvoy as maintenance engineer. But his long absences start to put a strain on his relationship with Jennie, his girlfriend.

Episode summary:

S1.E1 “Look After Number One”: In 1946 Flight Sgt. Russell tries to stay in the RAF as a pilot. A former mentor falls under suspicion of massive illegalities and needs a favor, leading to a brush with smuggling.
S1.E2 “Brave New World”: Demobilized from the Air Force, Jack Ruskin hustles to start his own private air service with a few other men.
S1.E3 “Conscience”: Ruskin Air Service’s first cargo run is a failure when the cargo of eggs is confiscated. Debts and interest on the aircraft loan pile up. A load of tractor parts headed to Palestine goes awry when a fuel stop leads to a change in cargo.
S1.E4 “Touch and Go”: February. Ruskin Air Services is grounded: locked in the icy grip of winter, Enter Ernie Cade, with a proposition the men find hard to refuse, Had they known what they were letting themselves in for, they would have remained earthbound.
S1.E5” Fool’s Errands”: March 1947, Ruskin is broke. His plane is badly damaged and Cade is putting the screws on. Hardly the time to expand, one would think, But Ruskin’s determination to succeed knows no bounds.
S1.E6 “Captain Clarke Plus One”: Spring 1947, With the forces of bureaucracy massing against him in England, Ruskin finds himself in Malta, with no fuel, no cooperation and no way out. All seems lost until the winds of fortune change - for the worse.
S1.E7 “Not Much of a Life”: Stripped of his pilot’s licence and no airline to run, Ruskin, undaunted, embarks on a new ‘money earner’ - and that’s where he comes unstuck: military training hasn’t exactly prepared his crew for carrying passengers.
S1.E8 “Officers and Gentlemen”: Spring 1948. Dark clouds are gathering over Jennie and Jack’s wedding plans, The airline is in deep -and deadly - trouble. Ruskin must make a decision which will affect the lives of everyone around him, But will he make the right choice?
S1.E9 “Too Many Promises”: Autumn 1948. With high financial rewards to be made from the Berlin airlift, independent operator Ruskin has nothing to operate. He has lost his licence, one of his planes and most of his crew. Can he save himself from disaster.

Airline: Playlist by Forgotten British Television

Available on YouTube

For Modellers: The DC3

The Douglas DC-3, also known in its military role as the Douglas C-47 Skytrain or Dakota (RAF designation), is a propeller-driven airliner manufactured by the Douglas Aircraft Company. It had a lasting effect on the airline industry from the 1930s, with examples still in use today.

In 1:72 scale, Airfix is the queen of the sky. It’s new tool from 2013 has shown up in a number of releases - most recently in 2022 as the Airfix Douglas C-47 Skytrain No. A08014.

Other recent toolings of the DC-3 in 1:72 include:

A&A Models Basler BT-67 No. 7242 from 2024
HobbyBoss C-47A Skytrain No. 87264 from 2017
Amodel Li-2P/T No. 72244 from 2011

In 1:144 Ukrainian manufacturer Roden has a 2013 tool, most recently released in 2015 as the Douglas AC-47D Spooky No. 310.

Hasegawa seems to dominate “airline scale” 1:200 offerings, with a 1994 tooling, most recently released in 2012 as the L2D Type Zero Transport & C-47 Skytrain “Pacific Carriers” 2 kits in the box No. 10687.

For Modellers: The Austin Tilly

A Tilly is a utility vehicle produced during the Second World War based on existing car designs for use by the British armed forces. They were all officially classed as Car, Light Utility 4 x 2.

The Austin variant is used in the show:

I’ve built the 1:72 Austin Tilly from ACE of Ukraine: British Light Utility Car Tilly 10HP No. 72500.

It’s a great kit - see my build here.

Tamiya have some of the best examples in 1:35 and 1:48:

Turning Points - HMS Prince of Wales

Wed, 25 Jun 2025 00:00:00 +0000

HMS Prince of Wales (R09) arrived in Singapore on the 23 June 2025, docking at the Marina Bay Cruise Centre. Many remember the last visit by a ship bearing her name, HMS Prince of Wales (53), doomed to be sunk a few days later on 10 Dec 1941 as Force Z was effectively wiped out by Japanese aircraft. In 2025, we are at an equally momentous turning point in military doctrine. Will the the new HMS Prince of Wales weather the storm?

The loss of the battleship HMS Prince of Wales (53) and her companion, the battlecruiser HMS Repulse, in just a matter of hours drove home the lesson that strategic advantage at sea had decisively shifted from the battleship to the air.

This was the same lesson painfully taught the US just a few days earlier with the Dec 7th attack on Pearl Harbor, and ironically demonstrated by the British themselves a month before with the Swordfish attack on the Italian fleet at Taranto.

This was a turning point in military doctrine that set the blueprint for much of the rest of the Pacific War.

In 2025, the aircraft carrier HMS Prince of Wales (R09) represents Britain’s continued commitment to the strategy of the Carrier Strike Group. Her main air capability comprises the Lockheed Martin F-35B fighter jets, with AgustaWestland Wildcat HMA2 and AgustaWestland Merlin HM2/HC4 helicopters.

HMS Prince of Wales (R09) was commissioned in 2019, and Operation Highmast is only her second major exercise. But is she already on the wrong side of another turning point of doctrine, just as her namesake was 84 years ago?

The world of 2025 looks very different from 2008 when she was ordered. Russia invaded Ukraine and started a very hot war that is not only showing the limits of nuclear deterrence, but that the battlefield is now ruled by drones. The UK left the EU, and the Trump administration has called into question its support for NATO and Ukraine, while continuing the US obsession with a threat from China.

We have seen two significant effects on the zeitgeist:

A dramatic shift towards uncrewed and autonomous combat systems
Questioning the wisdom of relying on the US as an all-weather ally. Many are already making moves to “de-risk” the control and supply of military technology from US dependence. For example, Portugal is re-considering its planned F35 purchase.

There was perhaps no better time for the UK to release its latest Strategic Defence Review.

While it remains steadfast in its commitment to the US as a strategic partner, indeed recommending to

double down on both pillars of the AUKUS agreement,

many of the recommendations reflect the dramatic re-centering of the role of autonomous and uncrewed systems, and that

Defence should also learn from Ukraine’s extraordinary experience in land warfare, drone, and hybrid conflict.

It foreshadows a significant shift in the role of the aircraft carrier

Carrier strike is already at the cutting-edge of NATO capability but much more rapid progress is needed in its evolution into ‘hybrid’ carrier airwings, whereby crewed combat aircraft (F-35B) are complemented by autonomous collaborative platforms in the air, and expendable, single‑use drones.

Specifically it recommends that:

The Royal Navy must continue its transformation in the skills, equipment, and ways of operating needed for the 21st century maritime domain as part of an Integrated Force. This should include:

Moving to a ‘hybrid’ carrier airwing, comprising crewed combat aircraft, autonomous collaborative platforms in the air, single-use drones, and, eventually, long-range missiles capable of being fired from the carrier deck.

Rapid evolution of anti-submarine warfare through the integration of underwater, surface, and airborne drones (including Protector) with Type 26 frigates, P-8 maritime patrol and reconnaissance aircraft, and SSN attack submarines.

Rapid evolution of mine-hunting to be delivered with autonomous platforms.

Exploring possible development from a Type 45 destroyer to a minimally crewed or autonomous air dominance system that could integrate directed energy weapons and enable better connectivity to other assets within the UK’s Integrated Air and Missile Defence system.

So while the aircraft carrier HMS Prince of Wales (R09) is not yet obsolete, one may expect dramatic changes in the way it is equipped and fought to be in the wind. Perhaps a refit when it returns from the Pacific at the end of Operation Highmast?

More references:

Chili Lime Peanuts ถั่วทอดสมุนไพร

Mon, 23 Jun 2025 00:00:00 +0000

Pailin’s Kitchen has gifted so many wonderful recipes that frequently appear on our table. It didn’t take much convincing to have a go at the latest recipe I’d seen, Chili Lime Peanuts (ถั่วทอดสมุนไพร, Tua Tod Samun Prai).

How did it go? Well let’s say I kept downsizing my storage container requirements. As we were warned, these are indeed very addictive!

I followed the basic recipe, the main variation being that I used Knorr Serbuk Pati (Seasoning Powder - Chicken) from NTUC Fairprice in place of “chicken bouillon”. I’m not sure if these are actually similar products, but it worked just fine. The first time I made this, I also left out the cashews as I didn’t have any around - also works, but I can now attest that it is better with them in.

My ingredient list:

Frying oil (canola)
2 garlic bulbs, ~15-20 cloves, sliced
15-20 makrut lime leaves. Stem removed and torn into smaller pieces.
1 stalk lemongrass
10-15 dried chilies, chopped
- Pasar Dried Chilies
400g raw peanuts
- Pasar Raw Peanuts from NTUC Fairprice
- (fried for 7-8 mins)
100g raw cashews
- Pasar Raw Cashew Nuts from NTUC Fairprice
- (fried for 5-6 mins)

And for the seasoning:

2 teaspoons granulated sugar
- I used brown sugar, as no white sugar on hand
1 teaspoon table salt
1 teaspoon lime juice powder
- Knorr Lime Flavoured Powder
1 teaspoon chicken bouillon powder, optional but recommended
- Knorr Serbuk Pati (Seasoning Powder - Chicken) from NTUC Fairprice
2 teaspoons chili powder
- I used Korean Gochugaru

Highly recommend. You may want to consider doubling all the quantities though!

The Mosquito In Film

Fri, 20 Jun 2025 00:00:00 +0000

The de Havilland DH.98 Mosquito is one of the most famous (and beautiful) aircraft of the Second World War. Its use evolved to successfully fulfil many roles, including low- to medium-altitude daytime tactical bomber, high-altitude night bomber, pathfinder, day or night fighter, fighter-bomber, intruder, maritime strike, and photo-reconnaissance aircraft.

There are of course many books covering the Mosquito, for example:

Mosquito: The RAF’s Legendary Wooden Wonder and its Most Extraordinary Mission, by Rowland White.
Mosquito Mayhem: de Havilland’s Wooden Wonder in Action in WWII, by Martin W. Bowman.
Mosquito Men: The Elite Pathfinders of 627 Squadron, by David Price
633 Squadron Series, by Frederick E. Smith.

As such an iconic aircraft, it is no surprise that many films have also made it the hero of the story. Let’s take a look at a few..

633 Squadron (1964)

An RAF squadron is assigned to knock out a German rocket fuel factory in Norway. The factory supplies fuel for the Nazi effort to launch rockets on England during D-Day.

The plot, which involves the exploits of a fictional World War II British fighter-bomber squadron, was based on the 1956 novel of the same name by former Royal Air Force officer Frederick E. Smith, which itself drew on several real RAF operations.

It can be found on YouTube:

Mosquito Squadron (1969)

In World War II, an RAF squadron leader mourns the death of a comrade and receives a bombing mission against a secret German V-2 rocket testing facility in France.

Although not a sequel, the film is similar to the 1964 film 633 Squadron and was influenced by it, even using some of its footage.

It can be found on YouTube:

The raid in Mosquito Squadron echoes Operation Jericho, a combined RAF–Maquis raid which freed French prisoners from Amiens prison in which the Mosquitos took part.

The pilots, navigators and planners of Operation Jericho tell their tales in their own words in this documentary, with copious contemporary footage:

Skyggen i mit øje (2021)

Skyggen i mit øje is a Danish film also known as “The Shadow in My Eye”, or “The Bombardment” in English.

It is a powerful story based around Operation Carthage. On March 21st, 1945, the British Royal Air Force set out on a mission to bomb Gestapo’s headquarters in Copenhagen. The raid had fatal consequences when one of the planes crashed near Institut Jeanne d’Arc, causing the school to be misidentified as the target and also bombed. More than 120 people were killed, 86 of whom were children.

I saw The Bombardment on Netflix.

For Modellers

Airfix has a long history of kitting the Mosquito. In 1:72 scale, the new tooling from 2021 is now powering a wonderful line of variants, for example De Havilland Mosquito B.XVI (A04023). I’ve enjoyed building this one.

Airfix are perhaps most famous for their massive 1:24 kit, most recently released in a 2015 boxing from the original 2010 tooling: De Havilland Mosquito FB.VI (A25001A)

Hasegawa have kitted a series of variants in 1:72 from a 1999 tooling, the latest being the 2016 release: Mosquito NF Mk.XIII ‘Night Fighter’ (02198).

Tamiya also entered the 1:72 Mosquito market at the same time as Hasegawa and have produced a few variants from a 1999 tooling, the latest being the 2001 release: De Havilland Mosquito NF Mk.XIII/XVII

Is there a good 1:48 scale mosquito? There hasn’t been a new tool for many years, but quite a few manufacturers:

Airfix: De Havilland Mosquito PR.XVI D-DAY 70th Anniversary No. A07112 - 2014 release from a 1977 tooling.
Revell: D.H. Mosquito B Mk. IV No. 03923 - 2017 release from a 2008 tooling.
Tamiya: de Havilland Mosquito NF Mk.II & British Light Utility Car 10HP No. 89786 - 2009 release from a 1998 tooling.

A similar story for 1:32:

Revell: De Havilland Mosquito Mk.IV No. 04758 - 2014 release from a 1971 tooling.
Tamiya: De Havilland Mosquito FB Mk.VI w/clear engine covers No. 60326 - 2015 tooling and release

More exciting perhaps is the range of Mosquito kits produced by Mark I Models in 1:144 scale from a 2018 tooling. The latest being DH Mosquito FB. VI Amiens Prison Raid No. MKM144124

At the very extreme end of the scale, Pit-Road produce a wonderful 1:700 scale Mosquito in their WWII Royal Air Force Wings Set 1 No. S32, last released in 2022 from a 2013 tooling. I’ve actually used it to make a little resin-encased diorama:

Close Quarters

Wed, 18 Jun 2025 00:00:00 +0000

Close Quarters (1943) is a docudrama that follows a Royal Navy submarine on a North Sea patrol during World War II. It uses vessels, equipment, and crew of the day, being filmed onboard the Royal Navy T-class Submarine N76 HMS Tribune.

HMS Tribune survived the war and was scrapped in 1947.

The film also includes rare footage of a Royal Navy submarine depot ship in action..

See details on IMDB, find it at the Imperial War Museum, or watch it on YouTube:

Submarine On Patrol (1943)

Submarine On Patrol is a British World War II information film describing to the public the technicalities and roles of Royal Navy submarine operations.

Again it features HMS Tribune masquerading as HMS Tyrant.

While it appears to have been made at the same time as filming of “Close Quarters”, most of the footage is unique.

For Modellers

SSMODEL released a new 1:350 3D-printed kit of the T-class Submarine (HMS Thrasher) in 2024. This joins an older Pit-Road plastic injection kit, also 1:350.

tardate 2026

LLM Limits: GPUs or Data?

The Bait And Switch

Skinny Data

Shadow Data

Data Black Hole

The Best Datasets

But At Least AI Can Code

Where To From Here?

More Data

Unbounded by Data

Composability

Conclusion

AISLE: The End of Zero-Days?

It’s 2026, and we still treat vulnerabilities as “Normal”

What is AISLE doing differently?

Is “Zero Vulnerabilities” Realistic?

Another AI Unicorn?

What Happens Next?

AI in the Call Centre

Tyranny of the Urgent

Problem 1. We’re Not Being Honest about Impact and Urgency

Problem 2. We are ignoring the Full Feature Lifecycle

Problem 3. When Things are Always Urgent, it may just be a Capacity Problem

Listen to the Podcast

After Pivotal Tracker

BardTracker

LiteTracker

Other Solutions

Direct PT Replacements

Other Planning Solutions

Airline: the DC-3 in Post-war History

Airline: The Synopsis

Airline: Playlist by Forgotten British Television

For Modellers: The DC3

For Modellers: The Austin Tilly

Turning Points - HMS Prince of Wales

Chili Lime Peanuts ถั่วทอดสมุนไพร

The Mosquito In Film

633 Squadron (1964)

Mosquito Squadron (1969)

Skyggen i mit øje (2021)

For Modellers

Close Quarters

Submarine On Patrol (1943)

For Modellers