<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Cameleering: articles</title>
  <subtitle>Software efficiency, measured against the original: essays with sources.</subtitle>
  <link href="https://cameleer.ing/feed.xml" rel="self"/>
  <link href="https://cameleer.ing/articles/"/>
  <id>https://cameleer.ing/articles/</id>
  <updated>2026-11-13T00:00:00Z</updated>
  <author><name>Cameleering</name><uri>https://cameleer.ing/</uri></author>
  <entry>
    <title>The cost of a TLS handshake, and why a reconnection wave is a load test</title>
    <link href="https://cameleer.ing/tls-handshake-cost/"/>
    <id>https://cameleer.ing/tls-handshake-cost/</id>
    <published>2026-11-13T00:00:00Z</published>
    <updated>2026-11-13T00:00:00Z</updated>
    <summary>TLS on an open connection is cheap; setting it up is not, and after a restart or failover many clients set up at once. What a handshake asks of a server, the arithmetic of a reconnection wave, the fixes, and what our own handshake numbers do and do not show.</summary>
  </entry>
  <entry>
    <title>Cold start is a recovery problem</title>
    <link href="https://cameleer.ing/cold-start-recovery/"/>
    <id>https://cameleer.ing/cold-start-recovery/</id>
    <published>2026-11-13T00:00:00Z</published>
    <updated>2026-11-13T00:00:00Z</updated>
    <summary>A restarted or new server is at its weakest when it first takes traffic. Four clocks from process start to full speed, the arithmetic of recovery, the ladder of fixes, and what our own start-up numbers do and do not show.</summary>
  </entry>
  <entry>
    <title>How to test your headroom before an incident: the degraded-fleet test</title>
    <link href="https://cameleer.ing/degraded-fleet-test/"/>
    <id>https://cameleer.ing/degraded-fleet-test/</id>
    <published>2026-11-13T00:00:00Z</published>
    <updated>2026-11-13T00:00:00Z</updated>
    <summary>A procedure for a staging fleet: lose a third of the servers, restart one under load, reconnect every client at once, offer more than the fleet can serve. What to record, how to read it, and the pass or fail lines to write first.</summary>
  </entry>
  <entry>
    <title>Headroom: what is left when servers drop out</title>
    <link href="https://cameleer.ing/headroom/"/>
    <id>https://cameleer.ing/headroom/</id>
    <published>2026-11-13T00:00:00Z</published>
    <updated>2026-11-13T00:00:00Z</updated>
    <summary>The Microsoft 365 outage of 12-13 November 2026 was the same traffic on fewer servers. How much a fleet survives losing part of itself is an efficiency property, and it can be measured before an incident.</summary>
  </entry>
  <entry>
    <title>Code efficiency as a FinOps lever</title>
    <link href="https://cameleer.ing/finops/"/>
    <id>https://cameleer.ing/finops/</id>
    <published>2026-11-12T00:00:00Z</published>
    <updated>2026-11-12T00:00:00Z</updated>
    <summary>Measured milliseconds and megabytes turned into instances and dollars: Lambda execution time, memory and cold starts, node density, Fargate, with the arithmetic shown.</summary>
  </entry>
  <entry>
    <title>When a rewrite pays off: a decision checklist</title>
    <link href="https://cameleer.ing/when-to-rewrite/"/>
    <id>https://cameleer.ing/when-to-rewrite/</id>
    <published>2026-11-12T00:00:00Z</published>
    <updated>2026-11-12T00:00:00Z</updated>
    <summary>The case against rewrites, the ones that worked with published results, the ladder from a setting to a full rewrite, and a checklist.</summary>
  </entry>
  <entry>
    <title>AI-generated code and performance: what the evidence says</title>
    <link href="https://cameleer.ing/ai-code-performance/"/>
    <id>https://cameleer.ing/ai-code-performance/</id>
    <published>2026-11-12T00:00:00Z</published>
    <updated>2026-11-12T00:00:00Z</updated>
    <summary>Generated code ran 3.12 times as long in one benchmark: what EffiBench, Mercury, EvalPerf, PIE, METR and DORA measured, each with its limits.</summary>
  </entry>
  <entry>
    <title>Wirth&#x27;s law in 2026: measured</title>
    <link href="https://cameleer.ing/wirths-law/"/>
    <id>https://cameleer.ing/wirths-law/</id>
    <published>2026-11-12T00:00:00Z</published>
    <updated>2026-11-12T00:00:00Z</updated>
    <summary>Software growth against hardware speed since 1995: page weight, input latency, single-core speed, and the counter-argument.</summary>
  </entry>
</feed>
