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.

I assume my phone is less secure than my desktop, because it's less frequently updated and probably a preferential target.

And fscking impossible to firewall properly. I've never tried with an apple phone but an android phone with always on VPN will still bypass the VPN when it feels like because "the OS is too important to be inconvenienced by such things"

The easiest way to see this happening is to remove the sim, so it has no mobile data at all, connect to wifi and turn on always on VPN.

Then monitor for traffic that tries to bypass the vpn.

Sure, there are some things that have to not go via the vpn, there's the vpn itself, of course, dns might be necessary for the vpn too if it cannot use static addresses, but it's also reasonable that captive portal detection stuff needs to happen before the vpn.

But even that leaks information to google - and we should be able to ensure that literally only the VPN software itself is allowed to talk to the outside world (via data).

On my latest phone there's a lot more than just captive portal detection going out.

Bloomberg is doubtless making a profit at $24k to $27k per user per year,

I doubt it, but I don't know.

Bloomberg has positioned itself as a premium service at a premium price.

Currently, it delivers premium service for that premium price, and that costs. You are a Japanese (only) speaker working at 1am Tokyo time and you have an issue, and your call to Bloomberg will be passed to a fluent Japanese speaker in minutes.

Pretty much anything that a company issues, news, reports, financials, will make it to the Bloomberg terminal quickly. Obviously, where possible, this is a digital link, but they transcribe things released as paper too.

I do wonder what will happen to Bloomberg (the company) once Bloomberg (the man) is no longer in charge. In the short term it seems trivially easy to turn the company into a $20K per terminal cash generator, but that will be achieved by stopping spending money on all the things that provide the premium service. There are plenty of alternatives that are good at a fraction of the cost and there's constant pressure on the people who have Bloomberg to use something else instead. Currently it's easy for the people who want Bloomberg to justify it - there's plenty of information only available on Bloomberg - but after five years of milking the company for cash instead of spending the money on premium service, and it will be harder to justify taking Bloomberg over one of the alternatives.

There again, what they actually want is the long days of summer to happen year round.

Is this really it?

Living in Northern Europe, when the clocks change in October is the most depressing day of the year. It's knowing that I won't see daylight for 4 months. And it happens on the day that the clocks change, there's no gradual "it's getting dark when I leave work" it goes straight to "it's nighttime when I leave work". The morning is already dark when I leave in the morning and it stays dark.

Having sunset at 5pm rather than 4pm on the shortest day is going to make it feel like what the day in October where the clocks change. Not great but "it's going to be getting better from here on".

The correct meaning of that sentence is that most particle accelerators are unable to steer two particle beams to crash head-on into one another.

Then it's utter bullshit. Probably by count most accelerators were either not intended to generate collisions at all or were fixed target accelerators. In either case there was only a single beam so talk about steering two beams is foolish. "Most accelerators are unable to steer two beams" would have been sufficient.

Once we went past the CoM energies that are reasonably achievable with a fixed target accelerator we needed colliders. Most colliders could only operate with a single mass of particle.

I'm pretty sure by count that most colliders could only accelerate electrons/positrons but again, as CoM requirements increase, e-e collisions become less productive.

If we're talking heavy ion accelerators, then yes, there are only two colliders currently in operation currently capable of colliding heavy ions, but that's all of the hadron colliders in operation. I don't know how many fixed target heavy ion accelerators there might be.

I would guess that there will be no hadron collider built in the future that couldn't collide heavy ions. It may not be possible to supply them with heavy ions as it may not be deemed worth building the infrastructure to do that, but if so, that will be a political decision to save a few hundred million on a multi billion machine, not a scientific decision.

Yes, but same mass collisions are trivial, the only requirement is that the accelerator is able to handle the mass.

The main ring at cern requires relativistic particles, it depends on the speed being (almost) constant while accelerating, so depends on the various feeders being able to accelerate Pb to sufficient energy.

And it depends on the magnets being able to contain the higher mass.

So
"Most particle accelerators are unable to steer two particle beams to crash head-on into one another."
is a strange comment. I'm not sure if they meant:
"Most particle accelerators are unable to circulate two particle beams of this mass" or
"Most particle accelerators are unable to be loaded with heavy nuclei"
but it's hard to imagine any accelerator that can meet those requirements not being able to steer the beams to collide.

I think it's interesting. C compilers aren't that complicated but C is just enough "uncooperative" that neither is it "feed the right file into lex/yacc and it will work". 20K seems cheap.

What I'd really like to see though is what they can do with reverse engineering, binary to C seems eminently sensible, C is low enough level that it can easily reflect the binary code without artificial constructs, but it's also expressive enough that it can express the semantic meaning of the code. And unlike compiling, where the global view matters, decompiling is almost exclusively local in scope.

It's not far off what qemu does when emulating an architecture, but it's really hard to go from that "JIT view" to something that a human can look at, understand, and improve.

We can be absolutely sure that China, the US and other major powers already have "state of the art decompilers" and are using them to seek vulnerabilities in closed source software. We, the people, need to know what "state of the art" really means. Perhaps it's useless in practice, no better than looking at the raw assembly for an expert, or perhaps it's "amazingly good" to the point where an expert doesn't need to know the architecture at all to understand the code.