The /tags/ page in the reader theme started as a perfectly ordinary taxonomy page. That was correct in the narrow Hugo sense and wrong in the editorial sense. A plain list tells you that tags exist. It does not tell you which ones dominate the corpus, which ones are one-off curiosities, or which ones form the real conceptual backbone of the site.

The goal of the tag cloud was not to make the page decorative. The goal was to make it legible as a structural overview. A useful cloud must answer three questions quickly:

That third question matters more than people admit. Tag clouds are easy to make ugly. If you give them color for novelty, weight for count, random order for “organic feel”, and large size swings for drama, they stop being navigation and turn into a poster. This theme wanted the opposite: quiet, readable, monochrome, but still meaningfully weighted.

So the implementation followed a few deliberate rules.

Start from count, but do not trust count alone

The source set is Hugo’s normal tag taxonomy ordered by count. That part is conventional and direct:

1

{{- $allTagsRaw := .Site.Taxonomies.tags.ByCount -}}

... continue

Hugo dev server CSS changes not updating in browser

Problem

When running hugo server in development mode, edits to a theme CSS file are detected by the dev server, but the browser continues to show the old CSS. Normal reload and hard reload do not apply the change. Restarting the Hugo dev server and then reloading the page makes the CSS change visible.

Observed log example:

1
2
3
4
5

Change detected, rebuilding site (#1).
2026-06-23 13:23:58.624 +0000
Asset changed /css/theme.css
Web Server is available at http://localhost:1314/ (bind address 0.0.0.0)
Total in 26 ms

This shows that Hugo detects the asset change and rebuilds, but the served/client-visible stylesheet does not update.

Relevant template code

1
2
3
4
5

{{- $css := resources.FromString "css/theme.css" (readFile "themes/reader/assets/css/theme.css") -}}
{{- if hugo.IsProduction -}}
  {{- $css = $css | resources.Minify | resources.Fingerprint -}}
{{- end -}}
<link rel="stylesheet" href="{{ $css.RelPermalink }}"{{ if hugo.IsProduction }} integrity="{{ $css.Data.Integrity }}" crossorigin="anonymous"{{ end }}>

Diagnosis

The likely cause is the use of:

1

resources.FromString "css/theme.css" (readFile "themes/reader/assets/css/theme.css")

This creates a synthetic Hugo resource from a string. It bypasses the normal Hugo Pipes resource graph for files in assets/. As a result, Hugo may detect that the source CSS file changed, but the resource cache/live-reload chain may not invalidate the synthetic stylesheet correctly. ... continue

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.

TL;DR

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.

Why This Argument Never Dies

... continue

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.

TL;DR

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.

The Question

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?

The Long Answer

Yes. Writing.

The Better Analogy Is Older and Less Glamorous

Or more precisely: writing after it stopped being rare. ... continue

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”.

TL;DR

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.

The Question

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?

The Long Answer

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

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.

TL;DR

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.

The Question

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?

The Long Answer

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 Prompt Is No Longer the Whole Unit

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

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.

TL;DR

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.

The Question

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?

The Long Answer

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.

Why the Idea Is Plausible

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

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.

TL;DR

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.

The Question

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?

The Long Answer

Because “conversation” describes the feeling of the exchange, not the job the exchange is actually doing.

The Surface Still Feels Like Conversation

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

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.

TL;DR

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.

The Question

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?

The Long Answer

Yes. And no, that is not a failure. It is what happens when a medium stops being a toy and starts carrying consequences.

Freedom Feels Loose at First

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

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.

Structure map (balanced chapter plan)

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.

Historical grounding: 1993–1996

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