shoo

A related concept is liability. Suppose you're a service provider - a contractor who performs maintenance services. You sign a contract with your client, BigCo, where you will service their plant's fancy $1m machine every month, and in return they pay you a modest $500 per month. One month you make a mistake in your work which causes their machine to become defective, but you & they don't notice in time before the defective machine creates a large mess. The defective machine causes BigCo to lose $3m due to lost revenue while the machine is offline & their costs to replace the machine. There's a pretty good chance BigCo may be able to sue you for the $3m losses they suffered from your mistake, even though this is disproportionately higher than the value of your $500 / monthly fee. As the contractor you avoid or limit this by making sure there is language in the contract to limit your liability & maybe arranging an insurance policy.

Now, how do things change if you sell a software product instead of a service? & how do things change if you give that software product away for free, instead of selling it? There's still a chance that some user of your free open source software product suffers real harm because of it. Particularly if they're using your free software in a commercial context with a lot of scale, perhaps they've suffered millions of dollars of losses because your free software product was defective. Are you liable to compensate them for their damages? Maybe!

Am I right to guess that neither your dev nor prod machines ran IA-64? If so that's not ideal, but beggars can't be choosers & a spare box from the infra team available right now is better than getting a box built to meet your exact specs available after the usual multi-quarter internal lead time.

Superficially it sounds a little crazy, but it's probably a lot less crazy than far more mainstream antipatterns (e.g. 'lets have our CI download all the dependencies from npm over the internet each time the build runs')!

Did running the unit tests on IA-64 ever flush out genuine issues that were 'working by accident' on x86?

It depends wildly on the type of game.

e.g. if you're playing a single player turn-based strategy game, you might be taking a few seconds between each decision & UI interaction. Some hard turns you might step away from the computer to think things through for minutes without touching the controls. 30fps for a game like that could be fine. 15-20fps might even be fine, especially if the game engine manages to avoid adding unnecessary input latency & is able to process input events at a faster rate even if the render runs at a low framerate.

If you're playing competitive FPS games, where reflexes matter, you'd want to get input, network & video latency as low as possible, within reason. Not high-frequency trading low. I have no idea at what point it stops making a competitive difference. If you have +100ms more latency than I do, I suspect that'd give me a noticeable advantage. If you have +10ms more latency than I do, I'm not sure that matters.

Dan Luu wrote an article about input latency [1] in 2017 where he measured latency by running experiments pressing a key & measuring how long it takes to see a response on the screen. New computers from 2017 would have around 70ms-170ms latency, depending on the model.

[1] https://danluu.com/input-lag/

Couple of guesses:

your usage patterns may have been similar to usage patterns of other customers that are often problematic, so some automated anti-abuse system made some statistical decision & banned you. you're a false positive, it's not worth their time reviewing the decision as most people they ban are problematic customers, and they've estimated that you're probably problematic.

Perhaps the cost of providing a 20x subscription exceeds the monthly subscription revenue, if a customer uses it heavily. Perhaps most heavy users only have a single subscription, and they can account for running at a small loss as a marketing expense & hoping you may convert to a profitable tier in future. But if you have 13 subscriptions of their 20x consumer plan at once, maybe they lose so much money from it that they decide it's not worth continuing to doing business with you -- purely commercially -- so at their discretion they ban you.

In both cases, they've decided it isn't worth doing business with you, for different reasons, so if they estimate that a new customer signing up is in fact you, the same person they previously decided to ban, they'll keep banning your attempts to open new accounts. They're not going to explain how they figure out you're the same person as that undermines the effectiveness of their banning process.

If you were banned purely because you're costing them too much money vs what you are paying, in theory that's fixable if you are willing to pay enough money to sign up for a proper business plan & can find some salesperson to negotiate with. but in practice presumably they have all their salesfolk pointed at enterprise customers because that is where the real money is.

I'm not a potential customer for this, but i have worked on a few commercial projects involving combinatorial optimisation.

Misc thoughts:

- I'm not familiar with the LABS problem, but the LABS benchmark page is interesting & compares against Gurobi. I'd be curious to see how an existing commercial non-mip approximate solver such as Hexaly (formerly LocalSolver) compares here.

- the other two benchmarks aren't very convincing as they don't compare against other methods or show running times

- the front page mentions peer reviewed methodology - consider linking to the publications

- good idea to have case studies of applications. I was a bit confused to see this listed under 'References' but on comparison the Gurobi & Hexaly marketing websites also do this (references -> case studies & references -> customer stories, respectively)

- re the client API, you may want to make the server URL have a default, so your trial users / customers don't have to specify it. It may be easier for you to roll out changes to your server URL in future if you can do it by changing the default server URL in a new version of your client library rather than requiring your customers to update their source code.

All the best!

there are no plans at all to improve the last mile infrastructure

The economics of laying fiber to the premises are heavily driven by density of potential customers * probability that a potential customer will sign up if you run fiber down their street. You can get reasonable intuition by focusing on the density alone & ignoring the competition / pricing side of things.

I'm not familiar with current US construction costs to install fiber but have some intuition from Australia.

With Australia's national broadband network project from a decade or so ago, it'd cost in the ballpark of $100 AUD per meter to run fiber down the street in an underground trench - most of the capex is digging the holes in the ground etc, the cost of the cable itself is essentially free. The construction budget for a suburb would be something like $2000 / premises. To give a ballpark estimate, suppose 25% of your budget is the premises-specific work to connect the house to the cable running down the street, if they choose to sign up for your broadband plan. That leaves at most $1500 / premises for the rest of your capex budget, so the economics only work if you've got a neighbourhood with a density of least one house every 15 meters. Those numbers aren't exact but they'd be in the ballpark.

There's a bit of variability in the cost per meter to install, if you can reuse existing poles & run the cable aerially that might be only 30%-40% of the cost of digging holes, so you might be able to support a lower density suburb that way & still stick to your construction budget.

In Australia for the lower density rural / semi-rural areas they'd use fixed wireless, & finally satellite for the remote extremely low density areas where it didn't even make sense to build a wireless tower.

things like employer matches in retirement accounts

seems completely reasonable to model this as income.

health insurance contributions

If your employer provides a health insurance benefit that would otherwise cost you $X / yr, you could model that as +$X / yr income and +$X / yr expenses.

Simple FIRE calculators like that Networthify one assume that your expenses in retirement are the same as when you are working, but that's probably not true for many people, for numerous reasons: health insurance once you're not longer working, paying off a mortgage, children launching into the workforce, increasing health expenses as you age, lifestyle changes when you're not working, potentially moving to a different area with a different cost of living.

But as a 0-th order approximation, assuming expenses in retirement are the same as when you are working is a place to start when assembling a rough plan.

When thinking about years of work until financial independence, its worth understanding the impact that savings rate has - the fraction of post-tax income remaining to invest in growth assets after expenses.

If you're not familiar with savings rate, here's a simple calculator to help build intuition. The assumptions of asset returns & portfolio required to sustain retirement are a bit optimistic, but it's directionally correct: https://networthify.com/calculator/earlyretirement

You need roughly a 15% savings rate to support traditional retirement age. If you're fortunate enough to create & sustain a situation where your income net tax is a lot higher than your annual expenses, the timeline accelerates significantly.

If the client has an extensive suite of automated tests assessing if the software is meeting its requirements, it should be possible for them to flush out most regressions within minutes or hours, not weeks.

If the client hasn't invested in setting that up, the resulting situation is the clients' responsibility.

The paper could be improved by including a strong classical non-Ising-machine solution approach as one of the methods benchmarked against.

E.g. take the same 8-core Ryzen machine they use to implement their simulated Ising Machine HbSB method & use it to run a standard classical solver as would be done industrially to tackle these kinds of problems outside of academia - perhaps an industrial grade commercial MIP solver (Gurobi) for those problem classes that are known to have reasonable MIP formulations, or a good constraint solver for Sudoku, etc.

Depending on how hard the specific test problem instances are, perhaps a commercial MIP solver would be able to solve some of these problems optimally & instantly using its black box of presolve witchcraft tricks.

In some cases it could be driven by the shape of the work & where the funding is allocated:

If there isn't enough guaranteed recurring work, it might not make sense to have a full time position, particularly in a country where its difficult to lay people off & if employees have additional overhead (pensions, employer funded heathcare or insurance, etc) vs contractors.

But, if there's funding allocated for some key project that's framed as a 6-12 month project, there might be a good business case to hire a contractor. Maybe the funding comes out of the project bucket, not the core funding for legacy product X bucket.

If the contractor is someone who was recently let go & has a good reputation within the company as someone who gets stuff done and is easy to work with, it's probably a no-brainer to re-engage them as a contractor vs rolling the dice on an unknown quantity.

Whoever is managing the budget of their old team gets a win as they were able to reduce headcount to fit in their budget

Whoever is managing the new project gets a win as they find a great contractor for their key project

The former employee returning as a contractor probably gets a win, as they get paid at a better daily rate while the project is rolling, provided they're able to line up more projects or land a new permie job once the project is completed.

If there's an outsourcer involved, they win by taking a cut. The former employee might also win by having the outsourcer involved if the company has some baroque process for engaging contractors with many compliance hoops to jump through -- in extreme cases (think banks, or public companies that need to demonstrate they don't do business with suppliers engaged in slavery, or so on) it could save the worker months of paperwork and tens of thousands in legal expenses to set up their own one-person agency and go through the compliance process to be able to work for their former employer, so they might not be able to win the contract work without piggybacking on an outsourcer who already has the contracts & compliance stuff sorted out.

when i worked for an australian bank, one co-worker in a nearby team had been working on the the banks systems as a sysadmin for over a decade.

the bank would go through cycles of "we need to reduce our headcount and outsource everything" and then 4 years later "we need to reduce spend on contractors and retain more knowledge and expertise in house". he'd survived multiple waves of it, switching back and forth between being an employee or a contractor through some external agency, as management trends changed, while essentially doing the same job.

Like you say, there's a fair bit of nuance. Data representations that prevent invalid states being represented are extremely helpful in many domains. I'd strongly recommend making invalid states impossible to represent for schemas at external interface boundaries - although that could also create problems if the definition of what's valid changes over time!

A niche example of this kind of thing is when solving commercial/industrial combinatorial optimisation problems. Maybe the goal is to maximise profit or minimise capex subject to a large number of constraints. Sometimes it is intractable to solve the true problem, but there's some approximation of the problem by relaxing one or more constraints that's much easier to solve. In some of these business contexts its completely OK if the optimiser ran overnight before spitting out a solution, provided it found a 5% better one. In that setting it'd be natural to decouple the internal representation(s) of a black box optimiser from the high-level way you represent the true problem & its solutions elsewhere in the system.

Some of these systems might end up feeling a little like a compiler toolchain - high level descriptions of problems & solutions that get transformed into / recovered from lower level implementation-specific representations.

If your context has high performance needs, e.g. needing to solve the problem 30 times per second in a real-time game or control system, or react as quickly as possible in a low-latency trading system, maybe it could be less of a good tradeoff to introduce avoidable copying of data between a strict correct representation & a relaxed representation. Could write the clean thing first & then profile and see if the overhead of copying is relevant. If the representation of your solution is small, there probably isn't that much overhead in copying it, unless your performance needs are extreme or your hardware is severely limited.

I conducted a few hundred software engineering interviews while working for a non-tech corp. Aside from technical problem solving & programming interviews we'd also ask a few behavioural questions -- including asking about times where the candidate had made a mistake at work, or a time at work where they were very frustrated.

What we were looking for

- people unwilling to admit they'd ever made a mistake -- red flag

- people who could reflect on the situation and say what they'd do differently in the future

- ideally, people who could use their mistake / failure / bad situation as an example of how they then took initiative to improve things by doing blah blah blah

People who were able to give an ideal response had clearly practised for this kind of question & knew how to play this part of the interview game.

Behaviours valued by one type of potential employer may not be valued by another. Small businesses & startups might value folks who take initiative and have a bias for action. In contrast, regulated megacorps might value folks who are great at consulting stakeholders and getting buy in before making changes, and steer clear of people they believe will go off and do stuff unilaterally.

One rule of thumb for handling these kinds of behavioural questions is "STAR" -- situation, task, action, result. Use the prompt for the question as a way to pick an example, then figure out how to frame an answer that shows you doing something to improve the situation. There's a fair chance that your interviewers are trying to mash your response into a STAR format in their own notes, even if they don't hint for you to respond in this way.

Doubt it. No linux-native application would be designed to use a Windows API.

I am a fan of the HARD FAIL.

It reads as if the change was made to some library code that was depended upon by someone else's program that would "yay, done", which was in turn depended on by some workflow.

It's probably a non-starter to change library code so it hard fails if it detects its being used incorrectly, in situations where it previously ran and did something. That's a severe breaking change in behaviour.

Easing it in by printing a warning message sounds like a reasonable step toward hard failing. But then we get the situation yosefk relates.

creating isolated staging & prod environments -- good idea

allowing an AI agent to get hold of creds that let it execute destructive changes against production -- not a great idea

allowing prod database changes from the machine where the AI agent is running at all -- not a great idea

choosing a backup approach that fails completely if there's an accidental volume wipe API call -- not a great idea

choosing to outsource key dependencies to a vendor, where you want a recovery SLA, without negotiating & paying for a recovery SLA -- you get what you get, and you dont get upset

Are the patient emails real patients or could they be test accounts?

Hindenburg Research is great. They also did the Nikola expose (that bunch of shysters who claimed to have electric truck technology where their truck couldn't even move under its own power so they filmed it rolling down a gentle slope).

For anyone wanting to get into the weeds about detecting accounting fraud, the book "Financial Shenanigans" has lots of historical examples of ways company executives have cooked the books to make their public company financial statements appear more appealing to investors than they actually are.

Josh Haberman has a good 2013 blog post discussing LL & LR parsers, theory vs practice, context-free grammars & Parsing Expression Grammars (PEGs): https://blog.reverberate.org/2013/09/ll-and-lr-in-context-wh...

it could be better than a nudge -- if you could get a mandatory `go fix` call into internal teams' CI pipelines that either fixes in place (perhaps risky) or fails the build if code isn't already identical to fixed code.

Great example, illustrating go1.26.1 go fix source inline transformation breaking program semantics. Raise it as a bug against go fix?

If I follow, this isn't a compile time inline directive, it's a `go fix` time source transformation of client code calling the annotated function.

Per the post, it sounds like this is most effective in closed-ecosystem internal monorepo-like contexts where an organisation has control over every instance of client code & can `go fix` all of the call sites to completely eradicate all usage of a deprecated APIs:

For many years now, our Google colleagues on the teams supporting Java, Kotlin, and C++ have been using source-level inliner tools like this. To date, these tools have eliminated millions of calls to deprecated functions in Google’s code base. Users simply add the directives, and wait. During the night, robots quietly prepare, test, and submit batches of code changes across a monorepo of billions of lines of code. If all goes well, by the morning the old code is no longer in use and can be safely deleted. Go’s inliner is a relative newcomer, but it has already been used to prepare more than 18,000 changelists to Google’s monorepo.

It could still have some incremental benefit for public APIs where client code is not under centralised control, but would not allow deprecated APIs to be removed without breakage.

you can get pretty far without programming at all, using spreadsheet templates

it's a classic. 2001 Spiel des Jahres Winner.

see https://boardgamegeek.com/boardgame/822/carcassonne

there's also a bunch of dedicated constraint programming solvers / high level modelling languages for these kinds of constraint-y combinatorial optimisation problems

e.g. https://www.minizinc.org/ offers a high level modelling language that can target a few different solver backends

might be pretty good results to completely ignore writing a custom algorithm and drop in an existing industrial-grade constraint programming solver, model your procgen problem using a high level language, and use the existing solver to find you random solutions (or exhaustively enumerate them). then more time to iterate on changing the problem definition to produce more interesting maps rather than getting bogged down writing a solver.

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