Quick reminder that most commercial software doesn't actually have the problem that git was designed to solve - multiple masters.

I'm not sure that git solves the multiple masters problem. There are two things I wish Linus had done differently with git:

1. The multiple masters - If I make a change on a branch, and you make a different change on the same branch, when we try to pull from each other we should not have to decide which one "wins". Monotone solved this with "divergent heads".
These things need to be resolved, I just dislike that git forces you to do it up front rather than first have the two heads and then resolve it. There are ways of working around this, but they depend on people following a process rather than it happening by default.

2. That most file metadata isn't a first class object in git. I understand why Linus didn't want timestamps, and didn't care about anything other than the execute bit, but it would have been nice if this was supported as a first class thing that is then disabled/ignored based on repository flags. I understand that this makes things like merging more difficult - harks back to my first comment - but as a result we end up with things like etckeeper to work around these limitations in git.

Then people might be able to find what they want rather than what amazon wants to sell and without 50 pages of a completely identical product one after the other.

You pay him for access to his insider trading information?

I'm not sure that most algorithmic trading firms could touch this with a bargepole.

The US has fairly lenient laws when it comes to insider trading, but the EU, for example, is much stricter; laws which basically boil down to "trading while in possession of MNPI". The regulator neither has to prove that you used the information, nor that you benefited from it, merely that you possessed it and you traded in a way that could have been influenced by it.

The main requirements that have to hold for the EU is that the information is "precise, non-public, and price-sensitive"

I don't know other regulators rules so well but my googling says that "Canada: generally prohibits trading while posessing undisclosed information obtained through special relationships"

There is, of course, some confusion on whether the information is "non-public" which I suspect Trump will play on, but I think these posts will be seen as Trump announcing that he is going to enact some government change, not that he has, and as such is unlikely to satisfy any non-US regulator as to it being anything other than MNPI (or worse, market manipulation - firms trading in the EU could be sanctioned even if Trump himself cannot be)

It was a civilian plane afterburners! As somebody who lives about 500m directly under one of Heathrow's landing flight paths,

But Concorde didn't use afterburners during landing. Very occasionally on a go-around it did but that was rare - this is "abort the landing", not "we need you to circle longer"

Concorde did use reheat on takeoff. That was for up to about 2 minutes on hot days, more usually around 90s. Concorde didn't carry enough fuel to run the afterburners unnecessarily. (Around 60s is acceleration to rotation speed, the rest the initial climb)

The only other time Concorde used afterburners was the acceleration to cruise speed - and that always happened over the ocean.

I think the OP is saying that a better quality UPS will "improve" poor input quality, while a cheaper one will just disconnect.

However, I don't know enough about grid stability to know whether this is reasonable. My guess would be that abrupt disconnect for over-voltage, rather than just draw less current and down convert will tend to increase the grid instability, while an abrupt disconnect for under-voltage would tend to improve grid stability.

I would bet that the engineers at the power company have already thought about all of these things and told management what should be done. It's 50/50 whether management then wrote these requirements into the contracts with these big consumers or whether the big consumers have claimed to be doing whatever is required while actually choosing the cheapest option (which I would assume is abrupt disconnect on over or under voltage and switch to site power)

I skimmed a few of the referenced papers back to something in 1986.

It turns out that the practical implementation of a theoretical perfect (quantum) random bit generator (the example given in one paper was a zener diode[1]) always has some skew. This might vary over time but, for example, a random bit stream that is biased to more ones than zeros over the last 10s is more likely than not suffering from some temporary bias that an attacker can at least theoretically use.

Using classical physics it's possible to remove this bias so that you have a pseudo-random stream that is, for all practical purposes perfect however it's (apparently[2]) provable that doing this in the classical domain is theoretically open to attack due to the original bias.

What this has done is allowed a quantum process to do that post filtering so that even the theoretical attack on the pseudo-random stream driven from an almost perfect RNG is gone.

[1] example here - different paper:
https://www.researchgate.net/f...

[2] I took it on trust - one paper said it was proved in another referenced paper, I didn't try to check if it really did say that and I certainly didn't even try to follow a proof...

I don't think you understand the distinction that "a constrained set" brings to the discussion.

Of course the halting or not halting of some programs is decidable. Exactly the same way that the travelling salesman problem is boring for some cases.

But the halting problem is intractable for single instances of programs. A single short program that halts on the first counterexample to the Goldbach conjecture is currently beyond mathematics to decide if it halts. It is possible (although unlikely) that it is beyond the capabilities of ZFC to decide if it halts. It's also beyond the current capabilities of mathematics to tell if it's intractable or not.

NP, on the other hand, is trivial for *any* constrained set of problems. Given an oracle, you can write a program that solves any instance and prove it correct. Given sufficient time and computing resources, an oracle for any constrained set of NP problems is trivial by exhaustive search. The haltingness of the oracle to solve any instance of an NP problem is known. The search space is finite so the maximum run time is computable, and so the program halts.

There is a known 600 state Turing machine starting with a blank tape (you could reasonably type it out by hand) whose halting behaviour is provably undecidable in ZFC (assuming ZFC is consistent)

Recent population growth is due solely to immigration.

I've not seen the figures for Switzerland so it could be an exception to the rule but for almost every western european country, a significant proportion (in the UK it's about 50%) of population growth over the last 3 decades or so is down to increased life expectancy.

Again, for the UK that effect appears to be flattening out, excluding the pandemic, the recent years in the 2020s are the first years since the 1970s that deaths have exceeded births. When you consider that the population has been aging over that entire period, that's an astonishing result.

I very recently saw a report that 2026 is expected to be the year when deaths are expected to exceeding births every year for the foreseeable future. The population has finally stopped growing because of increases in life expectancy.

The halting problem is not a problem for constrained sets of programs.

What's up with the huh?

I was commenting on that first line.

I assumed you were thinking of NP, because the halting problem definitely is unsolvable even for constrained sets of programs.

The halting problem itself is completely intractable. When I was at school, Goldbach was the standard example of a program whose halting we can't determine (and which might even be unknowable). These days the Yedidia-Aaronson construction is probably the more common illustration.

I agree that terms like "find all bugs" or "find any bugs" are inherently ambiguous. If halting is considered a bug, then it's trivial to modify a program that halts on a Goldbach counterexample into one that never halts: simply remove the break condition, print the counterexample, and continue.

In my professional work, the systems I work on traverse trillions of states per day and are designed never to revisit one. The only reason they remain analyzable is that their logical structure is far simpler than their state space. In principle, the system should run indefinitely without repeating a state, so - aside from intentional shutdown paths - identifying bugs that cause it to halt is equivalent to solving the halting problem. My hope is that the code is not so convoluted that it becomes an intractable instance of it.

And of course, there are intentional halting states for critical error conditions that "should never happen." Removing those to "solve" the halting problem, as in the Goldbach example above, would itself introduce a bug.

huh?

Write a program that tests each even number in turn to see if it's the sum of two primes and halt when it finds one (greater than 2) that isn't.

Does it halt?

There is a turing machine (750 or so states) which halts when it finds a contradiction in ZFC. It is unknowable if it halts. It is, infact, a proof that BB(750) is non-computable and sets a low upper bar on program size (but not memory size)

It needs more skill than I have to come up with an example where finding a bug is equivalent to the halting problem, but I don't see why that cannot be true. Obviously, real machines have finite memory but to all intents an purposes even a small machine has too many potential states to exhaustively reason about the way LLMs do.

We may, however, be reaching the point where finding more bugs of a particular class is going to be all but impossible.

It basically brute forces the solution, the same way a chess computer does, the problem is that it just doesn't have nearly enough context yet.

Some people have never heard of the halting problem.

Still more don't understand what the halting problem is and when it might or might not be relevant to a programming question.

40 years ago the best chess playing computers could beat almost everybody except good club players
30 years ago few other than top GMs could beat them
20 years ago even GMs struggled to beat them
10 years ago a GM was doing well if they could draw.

I see "AI" programming going the same way. Claude is really good at writing code given good constraints but some things are completely beyond it. It's written code in seconds that would have taken me hours, and it's taken a day to fail to solve a single repeatable crash that I solved in two hours.

It basically brute forces the solution, the same way a chess computer does, the problem is that it just doesn't have nearly enough context yet. Humans don't consciously remember 10 million lines of code, but a good programmer on a known codebase knows which bits matter, which bits to refer to etc to solve an issue. Claude (and any other LLM) just doesn't have enough context to be able to brute force something that depends on too much "across the code base" knowledge.

They smashed protons together at relativistic energies and found particles in the debris. That's not "particles emerging from empty space" â" that's particles emerging from a high-energy collision.

That's not how I read it (although I'm also only relying on the summary)

I read it as:

It's a given in the standard model that even in a perfect vacuum at absolute zero virtual (pairs of) particles are constantly being created and destroyed. While we can detect some side effects of that, the particles themselves cannot be detected or measured but we know that these virtual pairs must obey certain "rules" and, in particular, must be correlated in particular ways.

However, provide enough energy and those virtual pairs of particles can become real. When they become real they still have to obey the constraints that the virtual particles had to have.

What they have done here (assuming I've understood enough) is to provide enough energy so that the virtual particles can become real (surely this isn't surprising) and, additionally, detected the required correlations that the virtual particles made real must have.

I know nowhere near enough to know how they distinguished these virtual pairs made real from coincidence pairs created through "normal" proton-proton collisions but I assume that's covered in their paper.

it seems the current administration is focused on the former, but not the latter.

Obviously! One company creates pollution and makes money as a result. Another company makes money by charging you to deal with the pollution.

This is the free market at work - markets know best.

Let me translate:

"... it often depends heavily on external crates, which can introduce complexity and auditing challenges, especially in enterprise environments."

"If you write code in rust, you may link to a library in your code. I think this is somehow unique to rust, but I have no experience in software development. That makes rust more challenging in Enterprise environments."

The difference is that everything is statically linked in Rust. This isn't a problem if you rebuild the universe and release every day anyway, fix the library and everything will pick it up.

But it's an issue for Canonical (and Debian) because they don't rebuild every one of the tens if not hundreds of thousands of packages for each update of the Release file. And this would have to include older releases too that are still supported.

With many languages, if you rebuild the .so then that's all that is needed. Sure end users need to restart processes to be sure of picking up the fix but that's all. Debian tries quite hard to avoid library bundling where possible but rust sort of makes it implicit anyway.

The downside of the shared library model is that any and every incompatible library change requires a soname bump. ABI stability is critical to the .so model.