Hacker News: lclarkmichalek

New comment by lclarkmichalek in "The silent death of good code"

lclarkmichalek — Sun, 08 Feb 2026 01:07:03 +0000

Hilarious. The code being produced previously was crap - it was just your crap. Baseline agents produce something similar, but can at least be guided, durably, towards producing less crap code.

New comment by lclarkmichalek in "Amazon strategised about keeping water use secret"

lclarkmichalek — Mon, 27 Oct 2025 15:20:40 +0000

In absolute terms, yep. In marginal terms, not so much. See also: paradox of value

New comment by lclarkmichalek in "US probes Waymo robotaxis over school bus safety"

lclarkmichalek — Fri, 24 Oct 2025 02:23:44 +0000

Highways are pretty safe. The road is designed from start to finish to minimise the harm from collisions. That’s not true of urban streets

New comment by lclarkmichalek in "EU court rules nuclear energy is clean energy"

lclarkmichalek — Fri, 12 Sep 2025 21:09:47 +0000

I think if you regulated coal on a linear no threshold risk model, you'd find the costs to be somewhat closer.

New comment by lclarkmichalek in "2025 Infrastructure Report Card"

lclarkmichalek — Sat, 19 Jul 2025 21:39:59 +0000

There's also the converse argument, to governments that look to infrastructure as the secret to all prosperity - America succeeds without infrastructure, somehow.

New comment by lclarkmichalek in "Mark Cuban offers to fund former 18F employees"

lclarkmichalek — Sun, 02 Mar 2025 17:01:49 +0000

Natural monopolies exist, for sure. Your insurance example is odd though - insurance markets are generally highly competitive. The recent cases where we’ve seen a loss of competition in the market (CA home insurance, for example) have been driven by regulators imposing price controls.

The issue with healthcare is that providers have leverage over insurers, not that there is a lack of competition for insurance.

New comment by lclarkmichalek in "Systems ideas that sound good but almost never work"

lclarkmichalek — Tue, 31 Dec 2024 23:28:34 +0000

The usual issue is the addition of control loops without much understanding of the signals (CPU utilization is a fun one), and the addition of control loops without the consideration of other control loops. For example, you might find that your cross region load balancer gets into a fight with your in-process load shedding, because the load balancer's signals do not account for load shedding (or the way they account for the load shedding is inaccurate). Other issues might be the addition of control loops to optimize service local outcomes, to the detriment of global outcomes.

My general take is that you want relatively few control loops, in positions of high leverage.

New comment by lclarkmichalek in "Netflix buffering issues: Boxing fans complain about Jake Paul vs. Mike Tyson"

lclarkmichalek — Sun, 17 Nov 2024 02:13:20 +0000

What does this have to do with the topic being discussed?

New comment by lclarkmichalek in "The perils of transition to 64-bit time_t"

lclarkmichalek — Mon, 30 Sep 2024 01:02:00 +0000

There is a limit on reliable usage of the FS. Call it what you want. The user doesn't particularly care.

New comment by lclarkmichalek in "The perils of transition to 64-bit time_t"

lclarkmichalek — Sat, 28 Sep 2024 20:21:17 +0000

It does happen in prod. Usually due to virtual FSes that rely on get_next_ino: https://lkml.org/lkml/2020/7/13/1078

New comment by lclarkmichalek in "Bento: Jupyter Notebooks at Meta"

lclarkmichalek — Fri, 20 Sep 2024 18:09:54 +0000

I think a fair few of them were created because they knew a bit too much about FOQS

New comment by lclarkmichalek in "Launch HN: Fortress (YC S24) – Database platform for multi-tenant SaaS"

lclarkmichalek — Tue, 03 Sep 2024 00:39:18 +0000

You rather explained the value prop of this product then. The benefits of isolation without the 1 business day wait.

New comment by lclarkmichalek in "Launch HN: Fortress (YC S24) – Database platform for multi-tenant SaaS"

lclarkmichalek — Mon, 02 Sep 2024 23:44:15 +0000

Personally, there's no way I'd want a customer initiated operation to trigger something like terraform or mess with DB schemas. On the security side, it would significantly complicate the permissions structure from the application to the database. And on the performance side, I have absolutely no mental model for how operations like that scale, and how trivial of a DoS I'm exposing myself to. At the same time, I love the isolation (mostly operationally, the security & privacy side is also nice) that db-per-customer would bring. If this product helps bridge the gap, then it sounds good to me.

New comment by lclarkmichalek in "Will we have a negative leap second? [pdf] (2022)"

lclarkmichalek — Mon, 03 Jun 2024 08:23:16 +0000

Doesn’t astronomy already use TAI, which has no leap seconds?

New comment by lclarkmichalek in "American drivers even more distracted by phones. Pedestrian deaths are soaring"

lclarkmichalek — Fri, 23 Feb 2024 13:11:21 +0000

Penalties for being on your phone while driving are fairly different between different countries. In the UK it's 6 points and £200 if you're caught. It's a fair deterrent

New comment by lclarkmichalek in "Power grab: the hidden costs of Ireland's datacentre boom"

lclarkmichalek — Thu, 15 Feb 2024 07:53:33 +0000

The impact on the energy market always seems a tad misstated in these articles. Datacenters are often funded through corporate power purchase agreements, committing them to purchasing power directly from the generator over periods of multiple years. Those CPPAs are often tied to the development of new renewable energy generation (ex: https://www.matheson.com/insights/detail/matheson-advises-br...). Now, that still puts pressure on the grid for transmission, raises the marginal cost of renewable energy, and in cases where the generator cannot meet demand, presumably increases demand on other generation sources. But it makes the “40% of energy being used by DCs” stat seem a little misleading - a reasonable amount of generation exists because of these DCs.

(I work for Meta, who’s Clonee datacenter is mentioned in this article)

New comment by lclarkmichalek in "Pkl, a Programming Language for Configuration"

lclarkmichalek — Sat, 03 Feb 2024 17:20:31 +0000

Never used Bazel in my life, so while I can appreciate your passion, I guess I don't share your perspective. Generally the pattern I've seen has been providing a skylark interface to allow folks to define rules or configurations, which are then consumed through by whatever service via starlark-rust or similar implementations.

New comment by lclarkmichalek in "Pkl, a Programming Language for Configuration"

lclarkmichalek — Sat, 03 Feb 2024 11:58:23 +0000

In a competition with sky/starlark, I feel skylark would win here. “Safe subset of python” is what a lot of people presented with this problem want, and skylark gives them almost exactly that.

OTOH, curious to see what advantages Pkl gains from not having the constraints of maintaining familiarity with another language.

New comment by lclarkmichalek in "Retries – An interactive study of request retry methods"

lclarkmichalek — Thu, 23 Nov 2023 17:59:18 +0000

I mean, they can and should be both. Local decisions can be cheap, and very simple to implement. But global decisions can be smarter, and more predictable. In my experience, it's incredibly hard to make good decisions in pathological situations locally, as you often don't know you're in a pathological situation with only local data. But local data is often enough to "do less harm" :)

New comment by lclarkmichalek in "Retries – An interactive study of request retry methods"

lclarkmichalek — Thu, 23 Nov 2023 14:31:48 +0000

This still isn't what I'd call "safe". Retries are amazing at supporting clients in handling temporary issues, but horrible for helping them deal with consistently overloaded servers. While jitter & exponential backoff help with the timing, they don't reduce the overall load sent to the service.

The next step is usually local circuit breakers. The two easiest to implement are terminating the request if the error rate to the service over the last is greater than x%, and terminating the request (or disabling retries) if the % of requests that are retries over the last is greater than x%.

i.e. don't bother sending a request if 70% of requests have errored in the last minute, and don't bother retrying if 50% of the requests we've sent in the last minute have already been retries.

Google SRE book describes lots of other basic techniques to make retries safe.