shoo

prior ask HN thread from early feb 2026: https://news.ycombinator.com/item?id=46867190

> low air density environment. At normal air density near the surface of the Earth that ion thruster could only get a toddler up to ~10 km/h

agreed. this also provides an explanation for the otherwise surprising fact that prey animals in the savannah have never been observed to naturally evolve ion thrusters.

middling code, delivered within a tolerable time frame, budget, without taking excessive risk, is good enough for many real-world commercial software projects. homogeneous middling code, written by humans or extruded by machines, is arguably even a positive for the organisation: lots of organisations are more interested in delivery of software projects being predictable, or having a high bus-factor due to the fungibility of the folks (or machines) building and maintaining the code, rather than depending upon excellence.

in contrast, a toddler equipped with an ion thruster & a modest quantity of xeon propellant could achieve enough delta-v to attain cheetah-escape velocity, provided the initial trajectory during the first 31 hours of the mission was through a low-cheetah-density environment

or jump off, and instead grab onto the (well-deserved) sqlite-test-suite hype train.

> Brass Birmingham [...] there are often only 1-2 legal moves to play and figuring out what they are is quite a challenge for people playing the first time.

Also, some of those legal moves will set up a board state that the player taking a turn immediately after you can exploit for a lot more benefit than you got, so not only are the legal builds hard to identify for new players, half of those legal moves are also traps! If new players aren't comfortable learning the hard way, the player who is teaching the game can always call these out, explain what is going to happen & give people the opportunity to redo their move.

An alternative strategy game that is less complex than Brass is Friedemann Friese's classic Power Grid (2004) [1]. It has some of the same elements (network expansion, building stuff to make money) and parts of it are highly interactive (auctions!) but it is less complex and doesn't feature so many negative player interactions. The main down side of Power Grid is that some of the "admin" rules are pretty fiddly, but provided there is an experienced player to teach the game & be responsible for the admin, players who are learning don't need to care about the details.

[1] https://boardgamegeek.com/boardgame/2651/power-grid

+1 to pavel_lishin's Splendor suggestion. There's also Splendour: Duel [1] which is a more complex version of the game designed for 2 players.

Another quick, low-complexity game that is easy to teach & pretty good fun is Century: Spice Road [2]

Chinatown [3] (re-themed as Waterfall Park [3b] ) is a simple highly interactive game that is basically 100% negotiations between players who are trying to make real estate deals with each other. Can be played in 90 minutes, including rules explanation, plays up to 5. For a more complex asymmetric game that's more focused on engine building, with a healthy dose of negotiation, check out Sidereal Confluence [4].

For more complex games that take a bit longer to play to teach and play, that are largely focused on players doing their own thing ("multiplayer solitaire"), building their engines without much negative player interaction, check out Ark Nova [5] or Terraforming Mars [6]. These might take 3-4 hours or so to finish, provided there's an experienced player to teach everyone the rules.

For another moderately complex strategy game with a little more player interaction, check out Brass: Birmingham [7]. Takes around 4.5 hours to finish a 4 player game, including the rules explanation. If you have a group that enjoys complex strategy games and wants something with spikier negative player interactions, where one player's actions can completely wreck another player's plans, check out Barrage [8].

This probably doesn't help "without spending much money"! One trick is to find or create a regular board gaming group where everyone brings along different games. That way if, everyone buys a new game or two every year there's a lot of variety without everyone needing to buy heaps of games.

[1] https://boardgamegeek.com/boardgame/364073/splendor-duel

[2] https://boardgamegeek.com/boardgame/209685/century-spice-roa...

[3] https://boardgamegeek.com/boardgame/47/chinatown

[3b] https://boardgamegeek.com/boardgame/396618/waterfall-park

[4] https://boardgamegeek.com/boardgame/202426/sidereal-confluen...

[5] https://boardgamegeek.com/boardgame/342942/ark-nova

[6] https://boardgamegeek.com/boardgame/167791/terraforming-mars

[7] https://boardgamegeek.com/boardgame/224517/brass-birmingham

[8] https://boardgamegeek.com/boardgame/251247/barrage

standard algorithms for single-source/single-dest pathfinding scale log-linearly in the size of the graph, so compared to other combinatorial optimisation problems, optimal pathfinding is incredibly easy for computers to do & scales pretty well to industrial-sized problems. computers can also do optimal pathfinding for problems that humans would not be able to solve easily (because the graphs don't easily embed in 2d or 3d, say, so we can't bring our vision systems to bear)

other combinatorial optimisation problems - like the traveling salesman you mention - are much harder than pathfinding to solve optimally or even approximately

what a great talk with many little highlights: code archaeology of a codebase passed between many teams & companies with the full revision history being lost somewhere along the way, detective work figuring out there had been an accidental regression in floating point precision when SIMD was enabled, obtaining higher performance by specialising/simplifying the 2d geometry algorithm to axis-aligned rectangular obstacles instead of the prior convex hull code, automatically fuzz-testing the proposed "obviously valid" algorithm by AI vs AI matches & using logging/invariants to identify and harvest nasty counterexamples, growing a unit test suite of 100 harvested nasty counterexamples while fixing the identified defects in the new algorithm, finally shipping it and receiving player feedback

The underlying argument this article seems to be making is that an appropriate algorithm for any given application isn't always the one with the most efficient asymptotic performance for sufficiently large n -- for a given application (in this case routing), we have data on typical values of n that appear in reality and we can choose an algorithm that offers good enough (or optimal) performance for n in that constrained range, as well as potentially having other benefits such being simpler to implement correctly in a short amount of engineering time.

This argument is very much in line with Mike Acton's data-driven design philosophy [1] -- understand the actual specific problem you need to solve, not the abstract general problem. Understand the statistical distribution of actual problem instances, they'll have parameters in some range. Understand the hardware you're building writing software for, understand its finite capacity & capability.

It's common that new algorithms or data-structures with superior asymptotic efficiency are less performant for smaller problem sizes vs simpler alternatives. As always, it depends on the specifics of any given application.

[1] see Mike's CppCon 2014 talk "Data-Oriented Design and C++" https://www.youtube.com/watch?v=rX0ItVEVjHc

see also: "How Command & Conquer: Tiberian Sun Solved Pathfinding" (2019, non-technical, for a general audience) https://www.youtube.com/watch?v=S-VAL7Epn3o

paid time off

In Australia, full-time employees get 20 days of paid leave + paid public holidays (11 - 13 days, depending on the state).

thank you for posting a text version. to make the topic even more legible to prospective link clickers:

> How to Have a Bad Career in Research/Academia Pre-PhD and Post-PhD (& How to Give a Bad Talk)

Good on you for attempting to reproduce the results & writing it up, and reporting the issue to the authors.

> It turns out that the classification method used in their code looked at the test label as part of the decision method and thus led to an unfair comparison to the baseline results

> thought processes went "I'm a full stack engineer" > ... > "I'm evaluating classes in professional writing"

Let that one run, let's see where it ends.

maybe "I no longer build software; I now make furniture out of wood"

or "Have taken up farming"

or perhaps "I've sold all my RSUs, am taking a Sabattical" > "I'm exploring activities I find more fulfilling: yoga & angel investing" > "I'm the author of a substack blog post where I share life advice with others" [1]

[1] https://briansolis.com/2015/09/silicon-valley-hierarchy-need...

I've never worked on anything subject to medical regulation, but regarding open source tools, common open source licenses such as the MIT License [1], BSD License [2], GPL 2 & 3 [3] [4] all include "no warranty" / "limitation of liability" language to (i) state that there is no warranty & the software is not fit for use for any particular purpose and (ii) state that the authors of the software will not be liable for any damages users might suffer from using it.

[1] https://opensource.org/license/mit

[2] https://opensource.org/license/bsd-3-clause

[3] https://opensource.org/license/gpl-2-0

[4] https://opensource.org/license/gpl-3-0

Yeah, having a layer of human experts to sanity check and weed out hallucinated false positive issues seems like an important part of this process:

> To ensure that Claude hadn’t hallucinated bugs (i.e., invented problems that don’t exist, a problem that increasingly is placing an undue burden on open source developers), we validated every bug extensively before reporting it. [...] for our initial round of findings, our own security researchers validated each vulnerability and wrote patches by hand. As the volume of findings grew, we brought in external (human) security researchers to help with validation and patch development.

Based on the experiences shared by curl's maintainers over the last couple of years, resulting in them ending their bug bounty program [1] [2] [3], I'd suggest the "growing risk of LLM-discovered [security issues]" is primarily maintainers being buried under a deluge of low-effort zero-value LLM-hallucinated false positive security issue reports, where the reporter copy-pastes LLM output without validation.

[1] https://daniel.haxx.se/blog/2026/02/03/open-source-security-...

[2] https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-b...

[3] https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-s...

incremental steps like reducing or eliminating beef consumption by substituting less water intensive meat (e.g. chicken / turkey) are also helpful

Crypto -- gold -- these are both assets classes where the price is primarily driven by speculation. Sometimes speculation causes prices to fluctuate up, other times speculation causes prices to fluctuate down. There's inherently no stability. Over the last year, the mass media has been filled with news articles about the gold price so it isn't surprising that a lot of speculators have jumped onto the bandwagon (or have been trying to jump off).

Some asset classes (stock, real estate, bonds) have intrinsic value based on the net present value of their associated future cash flows, independent of whatever price the market currently offers to buy or sell them.

If you're holding a heavy allocation of purely speculative assets and that's causing you to lose sleep, consider selling some and increasing your allocation to assets that have intrinsic value.

The US stock market is probably a bit overpriced at the moment, I'd avoid piling 100% into that. A reasonable split of US stocks and international ex US stocks could be appropriate if you're investing money that you don't need for a decade or more. There are lots of low-fee passively indexed ETFs that can be used to easily and cheaply invest. If you'd like to learn more about simple and practical approaches for long-term investing, not speculation, check out the bogleheads.org website.

"In the short run, the market is a voting machine but in the long run, it is a weighing machine." -- Ben Graham

The voting machine dynamic is speculation. The weighing machine dynamic is anchoring of prices around long-term intrinsic value.

> What’s worked best for me so far is treating the code as sort of a confidence score, plus some layering in limited runtime info (e.g. what actually executed during tests) instead of relying on 100% static analysis.

> Curious how others handle this in real codebases..

I'd argue that for large Python codebases, having high automated test coverage is essential -- mainly unit tests of logic, but also a few heavier integration tests & smoke tests to confirm that the units can actually be wired together and executed in some fashion.

So, assuming [a] you're starting with a healthy Python codebase with great automated test coverage, the impact of deleting code that appears to be dead due to a false positive is actually quite low: it's immediately caught by the automated test suite, either pre-commit or pre-merge, so you back out the proposed delete and cross it off your list, and try the next ones. If the full test suite takes 5 minutes or less to run, no problem. If the full test suite takes 12 hours to run... ughh. I guess you could work around that with a statistical approach, make a few different branches, each applying a different random sample of 50 of the proposed 100 different code deletions, then kick them all off to run in CI overnight.

My main memory of Python dead code deletion is working on a Python project around a decade ago. The codebase was fresh, maybe 1-2 years old, worked on by various teams of contractors, but the focus had reasonably been on bashing out features, getting the app into production, rapidly iterating based on user feedback & as requirements oscillated. So there was a bit of accumulated cruft. I was new to the project and suggested we could use the vulture [1] dead code scanner, one of the other devs who had been working on the project since the start had a bit of spare time one afternoon, they applied it, found a bunch of dead code and deleted it all. The project had OK test coverage & we could manually sanity check each proposed delete during code review. It was a quick win. It's OK if you don't delete all the dead code, deleting the 80% that's easy to identify and low risk to remove is pretty good, then everyone can get back to shovelling more features into prod.

[a] If a Python codebase does not have high coverage of tests that are testing specific requirements and parts of functionality, the project is in an unhealthy state and that needs to be addressed first, before attempting any refactors, fixes or feature work. One way to dig out of that hole is to layer on automated end-to-end regression tests that assert that the behaviour (whatever it happens to be, quirks/defects and all) hasn't changed. Such tests are a lot worse than having fast specific tests of requirements (they merely detect if behaviour is changing, not if the behaviour meets or breaks requirements), they require a lot of toil to maintain, but they're significantly better than nothing, and provided you've got a wide enough sample of test scenarios to drive your regression tests it at least lets you tell with some confidence if a proposed refactor causes the app to crash. Then the safety net of regression tests gives you the confidence to make surgical changes (while writing specific unit tests). This is the general approach advocated by Feathers' Working Effectively with Legacy Code book (not Python specific).

[1] https://github.com/jendrikseipp/vulture

For big organisations with larger software teams, they may put value on considerations like security (automatic container image scanning, limiting which networks their container imagines are transferred through, ability to centrally manage and audit policies used by many teams), consolidating the number of vendors they need to vet and enter into contracts with, or finding a uniform package repo solution that works for container images and also for the other types of packages or artefacts. Big organisations are likely find that these other considerations matter more than the cost of cloud storage & network egress.

Maybe some of these potential adoption hurdles vanish if an organisation already has Cloudflare as a vendor. Provided Cloudflare is selling this as a solution they support under the existing contract.

Are you considering offering this as a commercial service if you find a market of other people who are interested in it? Or more thinking of it as something you could potentially open source?

How do you know this is happening?

Interesting idea, but it seems likely that the data this collects may not be very useful as a way to estimate the effectiveness of landing pages.

If I don't belong to one of the markets that the landing page is trying to sell products or services to, I shouldn't be able to vote -- if I vote, I'm just polluting the dataset of what their actual potential customers think of it.

If the two landing pages being compared aren't targeting the same market of potential customers [+], it's unclear what comparing them achieves.

It's unclear if voting on a landing page in this kind of artificial setting is predictive of something more material like how often a potential customer proceeds to sign up for a demo, or pay for something, or call sales.

[+] or given a lot of these are AI landing pages, I guess they're targeting investors.

There are some interesting examples in the "The Book of Why" [y] by Pearl and Mackenzie. This book is all about causal inference & has examples from things like drug trials where the analysis and inferences drawn from analysing experimental data depend upon what causal model you assume is generating the data, and if you pick an analysis that implicitly assumes the wrong underlying causal structure then your inferences drawn from the data may be wrong. There's a chapter about the historical scientific debate around if smoking causes lung cancer.

Andrew Gelman has an interesting review of the book [g], from the perspective of someone working within the statistical establishment that Pearl's book often critiques.

[y] https://www.hachettebookgroup.com/titles/judea-pearl/the-boo...

[g] https://statmodeling.stat.columbia.edu/2019/01/08/book-pearl...

re: SKIP LOCKED, introduced in postgres 9.5, here's an an archived copy [†] of the excellent 2016 2ndquadrant post discussing it

https://web.archive.org/web/20240309030618/https://www.2ndqu...

corresponding HN discussion thread from 2016 https://news.ycombinator.com/item?id=14676859

[†] it seems that all the old 2ndquadrant.com blog post links have been broken after their acquisition by enterprisedb

Your story reminded me of Bent Flyvbjerg and Dan Gardner's book "How Big Things Get Done". It's a pop science book communicating the research of Flyvbjerg & collaborators who collected data of actual schedule & budget outcomes for many large projects, along with recording the estimated schedule and budgets from the time the go/nogo decision was made to invest in the projects.

For accurate schedule and budget estimates, Flyvbjerg strongly recommends figuring out which broader class of projects your project belongs to, then going and looking at accurate historical data with actual schedule and budget outcomes for projects in that class, and using historical averages as your estimates.

There's a great table in an appendix at the back of the book, offering statistics for each category of project, ranking them by mean cost overrun.

The absolute worst category of project, for mean cost overruns, is nuclear storage, with a mean cost overrun of 238%.

IT projects are the 5th worst category of project, with a mean cost overrun of 73%, behind nuclear storage, olympic games, nuclear power and hydroelectric dams.

The table also has statistics on "what percentage of projects has a cost overrun of 50% or greater" and "of those projects with a cost overrun of 50% or greater, what is their mean cost overrun". For nuclear storage projects, 48% of them have a cost overrun of 50% or greater, and of those, the mean cost overrun is 427% (!).

For IT projects, 18% of them have a cost overrun of 50% or greater, and of those, the mean cost overrun is 447% (!!).

Some of the chapters in the book discuss some of the structural or political pressures that set projects up to fail --- e.g. in some fields its an open secret that estimates are always wildly optimistic, as if the estimates were actually realistic, no one would ever agree to fund a project.

There's often a tension between efficiency (say maximising throughput, or minimising latency) and robustness (being able to cope with shortages of inputs, demand shocks, work around failures). The world got to experience a bunch of logistical examples of this around COVID-19, but there's examples everywhere. Having a whole 2nd engine on a passenger plane seems wasteful, until the first engine fails.

When attempting to apply a process optimisation perspective from supply chains or manufacturing to software delivery, one way the software delivery problem space differs is that the software delivery process isn't a process that produces a stream of identical units that are independent of each other.

Suppose we abstract the software situation, we can tell ourselves that it is a repeatable process that produces an endless stream of independent features or fixes (weighed in "story points" say) that get shipped to production. This mental model maybe works some of the time, until it doesn't.

In reality, each software change is often making a bespoke, one-off modification or addition to an existing system. Work to deliver different features or fixes are not fungible and delivering the work items may not be independent -- if changes interfere with each other by touching overlapping components in the existing system and modifying them in incompatible ways. A more realistic mental model needs to acknowledge that there's a system there, and its existing architecture and accumulated cruft may heavily constrain what can be done, and that the system is often a one-off thing that is getting changed in bespoke ways with each item of work that ships.

great idea -- for sufficiently lumbering enterprisey clients you may discover that it is impossible for a mere dev to "push" a change into production without the right part of the org tree pulling, let alone for that to happen on timescales of less than a week. but even if so, that's a profoundly helpful thing to learn on week 1 so this is still great advice!

("...what do you mean that any changes going to prod need to first be socialised with and endorsed by the ABC steering committee & have their full rollout, rollback, & test plans signed off in blood by the responsible product, engineering & test managers & then sent for review by the change review board with at least 5 businesses days of lead time prior to the requested change date...")