<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: donavanm</title><link>https://news.ycombinator.com/user?id=donavanm</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sun, 25 Oct 2026 14:27:25 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=donavanm" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by donavanm in "Neovim have a ~$800k Bitcoin donation sitting untouched since 2023"]]></title><description><![CDATA[
<p>The normal term would be “velocity” of money, btw. Its a key consideration in addition to total supply whenever you need to evaluate inflation or manias.</p>
]]></description><pubDate>Thu, 17 Sep 2026 15:56:12 +0000</pubDate><link>https://news.ycombinator.com/item?id=49742664</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49742664</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49742664</guid></item><item><title><![CDATA[New comment by donavanm in "Neovim have a ~$800k Bitcoin donation sitting untouched since 2023"]]></title><description><![CDATA[
<p>Your understanding of monetary theory is somewhere between 110 and 5,000 years off. Furness had a pretty cogent explanation of a monetary system without central authority or functional currency about 100 years ago with the Yap. They even managed to have bouts of inflation without the concept of a bank or state.</p>
]]></description><pubDate>Thu, 17 Sep 2026 15:53:33 +0000</pubDate><link>https://news.ycombinator.com/item?id=49742620</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49742620</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49742620</guid></item><item><title><![CDATA[New comment by donavanm in "Neovim have a ~$800k Bitcoin donation sitting untouched since 2023"]]></title><description><![CDATA[
<p>Hahahaha, oh my. You think the world was some idyll halcyon pre bretton woods? My man Enmentrna is going to come back and declare a jubilee for your great revelation. When has <i>any</i> historic monetary system been “stable” for an appreciable amount of time. Debasement is a very literal ancient word and problem.<p>Even your straw man 20th century cut off is hilarious where you just kind of forget about 1873? Or maybe that decade is your shining example of the benefits of deflation. So much joy and global prosperity the peasants just forgot how to eat. Its cool, Bismarks destruction of the bimetallic system really helped usher in that age of stabikity from the international gold standards.</p>
]]></description><pubDate>Thu, 17 Sep 2026 15:42:10 +0000</pubDate><link>https://news.ycombinator.com/item?id=49742469</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49742469</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49742469</guid></item><item><title><![CDATA[New comment by donavanm in "AWS says it can't restore some data from mideast facilities struck by Iran"]]></title><description><![CDATA[
<p>> The amount of data S3 stores "automatically replicating" to other geographical locations would make things prohibitively expensive<p>It did work like this! And it was! My recollection is that the first S3 was out of SEA and had no user concept of region. Then “VDC” was added in virginia. That provided API endpoints in what became us-east-1. A bucket could be accessed from either location, and the original intent was for object store to replicate between them. By the time dub/eu-west-1 came along that was obviously not tenable; itd take 10s of gbs to replicate.<p>So S3 became regional. But the original sea/vdc deployments still had shared APIs and data in both regions. Your object would be stored in the region of the API you geolocated to via DNS, but read from either. _eventually_ all the data migrated to IAD, but those API endpoints were transparently proxying across the continent until 2013 or so.<p>And of course glacier had much more interesting takes on this with cross dc/az/region erasure encoding. But i dont <i>think</i> any of the wacky multi dimensional cross region stuff ever materialised in practice.<p>PS: hi!</p>
]]></description><pubDate>Thu, 17 Sep 2026 01:04:45 +0000</pubDate><link>https://news.ycombinator.com/item?id=49735195</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49735195</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49735195</guid></item><item><title><![CDATA[New comment by donavanm in "Desert Ant Labs: local, fast models that run on device"]]></title><description><![CDATA[
<p>> why should you continue getting money off me and my customers?<p>Welcome to the concept of fair market value. Less snarkily you're conflating the concepts of price and cost; theyre not the same thing and theyre not the same for you or the seller.</p>
]]></description><pubDate>Wed, 09 Sep 2026 12:59:25 +0000</pubDate><link>https://news.ycombinator.com/item?id=49625826</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49625826</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49625826</guid></item><item><title><![CDATA[New comment by donavanm in "Signing TLS handshakes inside a TPM"]]></title><description><![CDATA[
<p>Thats the “what it costs” section? Im a bit impressed if they are down to ~3ms per handshake. When I last looked at TPM signing (many years ago) it was more like single digit transactions per second.<p>That said, even 3ms TPM signatures are going to be for special cases or novelty. Plain old CPU tls will do about 1ms cpu time per request <i>which will scale by cpu core count</i>. One or two orders of magnitude more throughput per host.</p>
]]></description><pubDate>Mon, 07 Sep 2026 06:49:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=49594778</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49594778</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49594778</guid></item><item><title><![CDATA[New comment by donavanm in "Portal by Spotify cut my Claude Code token usage by 90%"]]></title><description><![CDATA[
<p>yes, and you can do it entirely in developer instructions (AGENTS.md/SKILLS.md). No hooks or other executables needed. Check out `codex-subagent-router` for an example. Its overly complicated, and has a few things wrong, but it mostly works. In short:<p><pre><code>  - Write ~1 paragraph of developer instructions (AGENTS.md): Use subagents for tasks that can be decomposed, worked on in parallel, or delegated. Describe common examples. I put a reference to a "how to use subagents" skill for more details. The "skill" isnt' always read (as subagents arent always useful) which saves some tokens. But you pay the once-per-session read-skill cost when its relevant.
  - Describe how to use subagents in ~1 page or less (SKILLS.md): use them for sub tasks. select model size/quality based on task ambiguity, scope, unbounded work, or conflicting requirements. Use reasoning effort for complexity, interdependence, or ambiguous success criteria. How to evaluate complexity & common subtask examples across the spectrum. give tasks a relevant name like "model-family_version_reasoning-effort_task-description" so you can actually understand what theyre doing by name.
  - in dev instructions (SKILLS.md) provide a table of agent names (low complexity summarizer, bounded implementation, complex implementation), model+effort (gpt-5.6-luna medium, gpt-5.6-luna high, gpt-5.6-sol medium), and short description of 2-3 task "types" for each.
  - Explain they can use "default" or specify their own custom model settings if needed.
  - Define your list of subagent profiles in ~/.codex/agents/ which matches names (low_complexity_summarizer.toml) from previous. In each you'll need to set model, reasoning, and `developer_instructions` that describe *how* to do a task, *not what* to do.
</code></pre>
Details to know:<p><pre><code>  - IMO subgent profiles are "task centric" because `developer_instructions` are required. You can't just specify model & reasoning, you also have to give valid developer_instructions that will be merged in to every session/prompt. I address this by defining a few different agents for tasks that are commonly encounted like summarization, synthesis, planning, implementation, etc. The different agent profiles (~2-5 per category) will "scale" the model + reasoning based on the complexity and ambiguity. This work pretty well in practice. And you don't need to over due it, the harness/agent can still launch a "custom" profile that uses the parent sessions developer instructions.
  - You need to use agent profiles with codex because "v2" models (terra & sol) can't launch "v1" models (luna). There are a couple of code paths to avoid this, the agent profile is the simplest. 
</code></pre>
Anyways, write you skill & subagent  profiles and it basically "just works".</p>
]]></description><pubDate>Sat, 05 Sep 2026 16:56:18 +0000</pubDate><link>https://news.ycombinator.com/item?id=49578385</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49578385</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49578385</guid></item><item><title><![CDATA[New comment by donavanm in "We could save petabytes of cache storage with Zstandard and Pingora"]]></title><description><![CDATA[
<p>Maybe cloudflares workload is substantially different, but i think youre missing just how long that tail was. A “lot”, maybe half, of unique objects werent requested a second time in any meaningful period time. Like days. And edge nodes have nowhere near the iops or cycles to spend doing _any_ extra work. So yes it is a waste of resources to cache or process in any way.</p>
]]></description><pubDate>Fri, 04 Sep 2026 21:19:15 +0000</pubDate><link>https://news.ycombinator.com/item?id=49570360</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49570360</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49570360</guid></item><item><title><![CDATA[New comment by donavanm in "We could save petabytes of cache storage with Zstandard and Pingora"]]></title><description><![CDATA[
<p>When I worked on a large CDN the content popularity distribution was <i>heavily</i> skewed. Think 20-40% of throughput from top 1% if content, and 80-90% from the top 10%. Anything outside of that had a very low probability if ever being read again in the effective cache lifetime.<p>Then the <i>effective</i> cost of scaling CPU > RAM > storage > network due to power & space limitations. Spending extra processing time on 50% of your content would be wasted effort as its <i>never read again</i>.<p>And yes, increasing effective storage might increase cache width/lifetime, but its not by <i>that much</i> to dramatically inprove access rates. Especially when most content by unique bytes is compressed audio/video in the first place.</p>
]]></description><pubDate>Wed, 02 Sep 2026 23:18:09 +0000</pubDate><link>https://news.ycombinator.com/item?id=49543924</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49543924</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49543924</guid></item><item><title><![CDATA[New comment by donavanm in "Benchmarking Pocket-Scale Inference"]]></title><description><![CDATA[
<p>NPUs, at least for apple, are built for relatively small scale efficient background processing. Theyre taking care of extracting structured metadata from freetext, recognizing people & text in photos, indexing file contents, etc. they do this really well with crazy low power draw. 
Theyre generally not even a target for current inference frameworks ala ollama, pytorch, etc.<p>I did see one prototype someone built using private ios APIs a few months back. They were able to run a reasonable SLM about an order of magnitude slower than GPU but with a tiny power draw.</p>
]]></description><pubDate>Mon, 31 Aug 2026 00:49:17 +0000</pubDate><link>https://news.ycombinator.com/item?id=49504414</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49504414</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49504414</guid></item><item><title><![CDATA[New comment by donavanm in "Launching Route 53 Files"]]></title><description><![CDATA[
<p>There are, internally, and theyre pretty good. I always tried to use the AWS Docs style guide when writing internally, for example. Theyre specific on how to refer to products vs services vs features, which  nouns to use, tone, grammar, etc.<p>PS: you might get tripped up on 0x00, 0x2F, or similar control characters? As i recall any valid octet can be included in a label. We definitely saw literal ‘*’ and ‘.’ inside labels. And I wouldnt be surprised to find a bell in there either.</p>
]]></description><pubDate>Fri, 28 Aug 2026 01:33:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=49473369</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49473369</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49473369</guid></item><item><title><![CDATA[New comment by donavanm in "Launching Route 53 Files"]]></title><description><![CDATA[
<p>This is just the era of AWS (and amazon APIs). A lot of them look like SOAPy xml rpc because thats how they started, based on internal service frameworks. Check out SQS or S3 for similar examples.<p>Around 2010-11 there was a shift towards RESTish structures and json for serialization. A lot of methods and payloads still feel SOAPy, but look like json. I think it was DynamoDB which had the most unfortunate API with a literal xml-json transform live in the API service.<p>And then somewhere around 2015 you started seeing more well defined RESTish APIs with better tooling and adoption for smithy (and some openapi, iirc).</p>
]]></description><pubDate>Fri, 28 Aug 2026 01:17:29 +0000</pubDate><link>https://news.ycombinator.com/item?id=49473270</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49473270</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49473270</guid></item><item><title><![CDATA[New comment by donavanm in "Man Charged with 3 Felonies for Breaking 3D-Printed 'Decoy' Flock Camera"]]></title><description><![CDATA[
<p>The damage estimate they use will be hypothetical total replacement cost, including multiple employees time, truck use, permits etc. its very trivial for any sort of repair to have a nominal cost in the thousands.</p>
]]></description><pubDate>Wed, 26 Aug 2026 00:28:56 +0000</pubDate><link>https://news.ycombinator.com/item?id=49442651</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49442651</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49442651</guid></item><item><title><![CDATA[New comment by donavanm in "A California Program Is Bringing Down the Cost of Heat Pumps by Buying Bulk"]]></title><description><![CDATA[
<p>Same again here in AU. Pretty sure i paid about $800 for the labor of installation (inc in the $2500) on top of material. Im more than comfortable with construction/electrical/plumbing. But at that price I stay off the roof, off a ladder, dont have to muck with extending a 240v circuit, and save a solid day if my time. Worth the price.</p>
]]></description><pubDate>Thu, 13 Aug 2026 03:43:15 +0000</pubDate><link>https://news.ycombinator.com/item?id=49281553</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49281553</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49281553</guid></item><item><title><![CDATA[New comment by donavanm in "A California Program Is Bringing Down the Cost of Heat Pumps by Buying Bulk"]]></title><description><![CDATA[
<p>Yeah, vaguely aware that you could diy the entire setup with refrigerant etc. But its not relevant at local prices here in AU.<p>One of the interesting things I noticed here is that manufacturers are providing exchangers and head units that can reuse existing pipes. Makes sense for retrofit/upgrades where running pipes through utility spaces and bulkheads is a significant labor cost.</p>
]]></description><pubDate>Tue, 11 Aug 2026 08:33:19 +0000</pubDate><link>https://news.ycombinator.com/item?id=49254988</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49254988</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49254988</guid></item><item><title><![CDATA[New comment by donavanm in "A California Program Is Bringing Down the Cost of Heat Pumps by Buying Bulk"]]></title><description><![CDATA[
<p>Same in Australia/East Asia generally. Had a mid range daiken 3kw unit installed upstairs last summer; $2500 AUD and ~5 man hours to install including roof access and exterior wall mounting. A bigger 7kw multi head unit would have been about $6-7k AUD but required awkward attic and wall access.<p>Installed prices in the US are pretty silly. Theres a bourgeoning set of DIY units that come precharged. But even those are pricey compared to the rest of the world.</p>
]]></description><pubDate>Tue, 11 Aug 2026 02:33:13 +0000</pubDate><link>https://news.ycombinator.com/item?id=49252676</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49252676</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49252676</guid></item><item><title><![CDATA[New comment by donavanm in "Analyzing data from Silicon Valley ventures and founders prosecuted for fraud"]]></title><description><![CDATA[
<p>> Would be great if companies only had to report once a year.<p>Why and how would it be in the public or shareholder interest?<p>Im unaware if any public market where similar reductions in reporting led to significant, positive, outcomes. FTSE is the common example. They had a similar “reform” circa ‘14 and FTSE companies continue to generally under perform while the LSE continues to lose listings.</p>
]]></description><pubDate>Mon, 10 Aug 2026 01:47:07 +0000</pubDate><link>https://news.ycombinator.com/item?id=49238324</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49238324</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49238324</guid></item><item><title><![CDATA[New comment by donavanm in "AI's debt binge can't last, hidden borrowing reaches $1.65T"]]></title><description><![CDATA[
<p>> I have no financial stake in AI-related companies<p>so zero exposure to any popular index? Even “ex-US” is tsmc and sk-hynix in a trenchcoat. I think it was BHP exclaiming that theyre an AI play because they cover 85% of the raw materials in DC build outs.<p>In the current mania “no financial stake in AI-related” is a <i>very</i> bold claim.</p>
]]></description><pubDate>Mon, 03 Aug 2026 23:30:01 +0000</pubDate><link>https://news.ycombinator.com/item?id=49162693</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=49162693</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49162693</guid></item><item><title><![CDATA[New comment by donavanm in "AWS: Inaccurate Estimated Billing Data – $1.7 billion"]]></title><description><![CDATA[
<p>Nope, different service. We were introducing new methods using POST and (iirc) some differential pricing based on the actual request params. Which made it a different code path, metering value, price, etc than the existing GET requests.</p>
]]></description><pubDate>Sat, 18 Jul 2026 04:44:28 +0000</pubDate><link>https://news.ycombinator.com/item?id=48955301</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=48955301</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48955301</guid></item><item><title><![CDATA[New comment by donavanm in "AWS: Inaccurate Estimated Billing Data – $1.7 billion"]]></title><description><![CDATA[
<p>It was the same old kona files for metering until at least a ‘23-24 when I last did metering/pricing work. “Luckily” the size of the EC2 pricing plan was so stupidly large that it was forcing improvements to how those were serialized, and how private pricing plans were created/assigned to different payer ids.</p>
]]></description><pubDate>Sat, 18 Jul 2026 01:02:41 +0000</pubDate><link>https://news.ycombinator.com/item?id=48954086</link><dc:creator>donavanm</dc:creator><comments>https://news.ycombinator.com/item?id=48954086</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48954086</guid></item></channel></rss>