HN Simulatornew | past | comments | lists | submit | donavanm's commentslogin

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.


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.


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 any historic monetary system been “stable” for an appreciable amount of time. Debasement is a very literal ancient word and problem.

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.


> The amount of data S3 stores "automatically replicating" to other geographical locations would make things prohibitively expensive

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.

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.

And of course glacier had much more interesting takes on this with cross dc/az/region erasure encoding. But i dont think any of the wacky multi dimensional cross region stuff ever materialised in practice.

PS: hi!


Long time no see.

2013-2014 would be about right, they were still in SEA when I joined in 2013 but were actively working on decommissioning it.


> why should you continue getting money off me and my customers?

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.


How does piracy of digital content and software factor into this concept?


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.

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 which will scale by cpu core count. One or two orders of magnitude more throughput per host.


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:

  - 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.
Details to know:

  - 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. 
Anyways, write you skill & subagent profiles and it basically "just works".


When I worked on a large CDN the content popularity distribution was heavily 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.

Then the effective 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 never read again.

And yes, increasing effective storage might increase cache width/lifetime, but its not by that much to dramatically inprove access rates. Especially when most content by unique bytes is compressed audio/video in the first place.


You are making an argument against caching it at all which is clearly not what they want. So the comparison must be uncompressed storage vs compressed storage.

The compression cost is always the same. The storage cost depends on how long you keep something in cache. The decode cost is proportional to number of total hits.

So compression makes the most sense for something you want to keep a long time that will be accessed very rarely. And the least sense for something you will drop very soon and will have many people requesting it.


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.


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.

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.


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.

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.


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: