Blog
Welcome to the Blog.
Jumbo Frames on Ethernet
2026-06-19
Jumbo frames are one of those networking topics that never quite go away. They keep returning in design reviews, storage checklists, virtualization guides, vendor best-practice documents, cloud tuning pages, and endless forum threads where somebody asks a simple question and receives the old infrastructure reflex: “Yes, enable them.”
That reflex had a rational historical basis. Operationally, in most modern networks, it has become much harder to defend.
Jumbo frames were a rational optimization for an era when hosts, drivers, and
NICs had a much harder time keeping up with 1 GbE and early 10 GbE bulk
traffic. That is the historical core of the feature. Modern CPUs, multiqueue
NICs, interrupt moderation, TSO/GSO/GRO, and better driver stacks attack the
same packet-rate problem without demanding end-to-end MTU choreography across
the whole path.
The raw upside today is usually modest: best-case wire-efficiency gains are only single-digit percentages, while the operational cost remains exactly the kind of cost operators hate to carry forever: path-wide coordination, PMTU black holes, silent mismatch failures, debugging ambiguity, and permanent configuration burden on every future change.
So the modern default answer should usually be 1500, not 9000.
The burden of proof is on jumbo frames now.
Even many of the classic “strong candidate” cases from storage and
virtualization are weaker than their old best-practice documents imply, because
dedicated jumbo paths have a habit of turning into ordinary VLANs carried over
shared infrastructure, overlays, and eventually other operational domains.
Outside a few true specialty fabrics, jumbo frames are mostly a complexity tax
chasing marginal gains. ... continue
Less Cinema, More Paperwork
2026-04-20
The most popular analogies around AI are usually the worst ones, because they jump straight to apocalypse, utopia, or machine rebellion and miss the transformation already happening in front of us. A far better analogy is older, less glamorous, and much more revealing: the history of writing becoming administration.
The strongest historical analogy for LLMs is not Skynet, industrial automation, or a new species. It is the old pattern in which an expressive medium expands access and then hardens into records, templates, procedure, governance, and bureaucracy. Less cinema. More paperwork. Unfortunately that is usually where real power hides.
You may ask: if natural-language AI feels like a liberation from rigid interfaces, what historical pattern does it actually resemble? Is there an older moment where a flexible medium spread widely and then slowly turned into structure, procedure, and control?
Yes. Writing.
Or more precisely: writing after it stopped being rare. ... continue
Consequential, Not Just Useful
2026-04-20
For a while, the industry kept talking as if tool access merely made models more “useful”. That description is too soft by half, because the real shift is harsher: once a model can perceive and act through an environment, its outputs stop being merely interesting and start becoming “consequential”.
Model Context Protocol (MCP) does not just make language models more capable in some vague product sense. It moves them closer to “consequence” by connecting model output to trusted systems, permissions, tools, and environments where words can become actions.
You may ask: if MCP is just a protocol for tools and context, why treat it as such a serious threshold? Why not simply say it makes models more “useful” and leave it at that?
Because "useful" is marketing language. "consequential" is the serious word.
An LLM on its own is still mostly trapped inside text. Yes, text matters. Text persuades, misleads, reassures, coordinates, manipulates, flatters, and occasionally clarifies. But absent tool access, the model remains largely confined to symbolic output that a human still has to read, interpret, and turn into action. ... continue
From Prompt to Protocol Stack
2026-04-18
The future of AI control was never going to fit inside one clever paragraph typed into a chat box. What looks like prompting today is already breaking apart into layers, and each layer is quietly starting to serve a different audience: humans, agents, tools, infrastructure, and, eventually, other layers pretending not to be there.
Prompting is evolving into a full protocol stack. Natural language remains at the human boundary, while deeper layers increasingly carry schemas, tool definitions, memory layouts, compressed state, and possibly machine-native agent communication. The chat box survives, but it is no longer the whole machine.
Have you ever wondered whether we are still dealing with prompting at all once prompts become longer, more structured, and more system-like? Or are we actually watching a new software stack form around language models?
I think we are very obviously watching a new stack form, even if the industry still likes talking as though everything important happens inside the visible prompt.
The mistake is to imagine the prompt as the unit. That made some sense when language models were mostly single-turn text machines. It makes much less sense once we ask them to persist, use tools, collaborate, manage memory, or act inside workflows. At that point the useful object is no longer the prompt alone. It is the entire communication architecture around it. ... continue
Hidden Language Beneath English?
2026-04-16
Most prompt engineering is written in English, and the industry often treats that fact as if it were almost self-evident. But once you ask whether English is truly the best control medium or merely the most overrepresented one, the ground starts moving under the whole discussion.
There is no strong evidence yet for one universal hidden “control language” beneath English. But there is real evidence that useful control can happen through non-natural-language mechanisms such as soft prompts, steering vectors, and latent or activation-based agent communication. So the idea is not crazy. It is just easier to say crazy things around it than careful ones.
You may ask: if models live in a high-dimensional latent space, why are we still steering them with ordinary English sentences? Could there be a shorter, more efficient machine-native control language hidden under natural language, especially for agent-to-agent communication?
This is one of the most interesting questions in the whole field, partly because it contains a real idea and partly because it attracts nonsense like a magnet.
So let us separate what is plausible, what is established, and what is still an extrapolation, because this is exactly the kind of topic where people start sounding profound five minutes before they start lying to themselves. ... continue
Prompting Is Not Conversation
2026-04-13
The phrase “just talk to the model” is one of the most successful half-truths in the current AI boom. It is good onboarding and bad description: useful for getting people in the door, and deeply misleading the moment anything expensive, fragile, or embarassingly public depends on the answer.
Prompting is conversational only at the surface. Under real workloads it behaves much more like specification-writing for a probabilistic component inside a larger system, except the specification keeps pretending to be a chat.
Have you ever wondered why everyone says prompting is basically conversation, yet good prompting looks less like chatting and more like writing instructions for a very literal, very strange coworker with infinite patience and inconsistent memory?
Because “conversation” describes the feeling of the exchange, not the job the exchange is actually doing.
If I ask a friend, “Can you take a look at this and tell me what seems wrong?” the friend brings a whole life into the exchange. Shared background. Common sense. Tone-reading. Social repair mechanisms. Tacit norms. A strong instinct for what I probably meant even if I said it badly. Human conversation is robust because it rides on an absurd amount of shared context that usually never gets written down. ... continue
Freedom Creates Protocol
2026-04-06
Natural-language AI was supposed to free us from syntax, ceremony, and the old priesthood of formal languages. Instead, the moment it became useful, we did what humans nearly always do: we rebuilt hierarchy, templates, rules, little rituals of correctness, and a fresh layer of people telling other people what the proper way is.
Natural language did not abolish formalism in computing. It merely shoved it upstairs, from syntax into protocol: prompt templates, role definitions, tool contracts, context layouts, reusable skills, and the usual folklore that grows around every medium once people start depending on it.
You may ask: if LLMs finally let us speak freely to machines, why are we already inventing new rules, formats, and best practices for talking to them? Did we escape formalism only to rebuild it one floor higher?
Yes. And no, that is not a failure. It is what happens when a medium stops being a toy and starts carrying consequences.
When people first encounter an LLM, the experience feels a little indecent. You type something vague, lazy, half-formed, maybe even badly phrased, and the machine still gives you back something that looks intelligent. No parser revolt. No complaint about a missing bracket. No long initiation rite through syntax manuals. Compared to a compiler, a shell, or a query language, this feels like liberation. ... continue
TP Toolchain 7: TPW -> Delphi
2026-03-13
The transition from Turbo Pascal for Windows (TPW) and Borland Pascal 7 to Delphi was not merely a product upgrade. It was a mindset shift: from procedural resource wrangling and manual message dispatch to a visual, component-based, and event-driven workflow. Developers who had mastered TPW’s message loops and resource scripts found themselves in a different world—one where the form designer and object inspector replaced the resource editor, and where component ownership and event handlers replaced explicit handle management.
This article traces that transition from the perspective of a practitioner who lived it. It covers workflow changes, delivery model shifts, debugging adaptations, and team process evolution. The goal is not nostalgia but practical guidance: what to watch for when migrating, what patterns hold, and what pitfalls to avoid. The TPW-to-Delphi path was well-traveled in the mid-to-late 1990s; the lessons learned then remain applicable to any transition from low-level, imperative UI development to a higher-level, component-based framework. This article assumes familiarity with TPW or BP7; readers new to that era may find Part 5 and Part 6 of this series useful for context.
To keep chapter quality even, the article uses a fixed ten-part structure before going deep into each topic:
Each chapter is intentionally expanded with similar depth: mechanism, pitfalls, and practical migration guidance.
Delphi development started internally at Borland around 1993. The first public release shipped in February 1995. That release introduced the Visual Component Library (VCL), which became the central framework for visual, event-driven Windows development in Object Pascal. Delphi 2 arrived in 1996 with a strong focus on 32-bit Windows, consolidating the shift away from 16-bit TPW. ... continue
TP Toolchain 6: Windows Transition
2026-03-13
Parts 1–5 mapped the DOS-era toolchain: workflow, artifacts, overlays, BGI, and the compiler/linker boundary from TP6 to TP7. This part crosses the platform divide. Object Pascal extensions, Turbo Pascal for Windows (TPW), and the move to message-driven GUIs forced a different kind of toolchain thinking. Same language family, new mental model.
This article traces that transition from a practitioner’s perspective: what stayed familiar, what broke, and what had to be relearned. We cover the historical milestones (TP 5.5 OOP, TPW 1.0, TPW 1.5, BP7), the technical culprits that bit migrating teams, debugging and build/deploy workflow differences, and the mental shift from sequential to event-driven execution.
Version timeline (conservative): TP 5.5 (1989) introduced Object Pascal. TPW 1.0 appeared in the Windows 3.0 era (c. 1991). Borland Pascal 7 (1992) offered unified DOS and Windows tooling including DLL support. TPW 1.5 followed TP7 (c. 1993). OWL matured alongside these releases. Exact dates for some variants vary by region and packaging; the sequence is well established. The transition spanned roughly four years; many teams maintained both DOS and Windows targets during that period.
Before drilling into details, this article follows a fixed ten-chapter plan so the narrative stays balanced rather than front-loaded:
Each chapter carries similar depth: technical mechanism, failure mode, and practical operator/developer workflow. ... continue
VFAT Shortname Rules
2026-03-10
The second story begins with a floppy label that looked harmless:
RELEASE_NOTES_FINAL_REALLY_FINAL.TXT
By itself, that filename is only mildly annoying. Inside a mixed DOS/Windows pipeline in 1990s tooling, it can become a release blocker.
Our fictional team learned this in one long weekend. The packager ran on a VFAT-capable machine. The installer verifier ran in a strict DOS context. The build ledger expected 8.3 aliases. Nobody had documented the shortname translation rules completely. Everybody thought they “basically knew” them.
“Basically” lasted until the audit script flagged twelve mismatches that were all technically valid and operationally catastrophic. ... continue