Parliament can also impeach ministers. It hasn't bothered trying for about 180 years because a vote of no confidence is simpler, but it hasn't given up the power (and it's hard to argue that it's somehow fallen into abeyance through lack of use, as there's precedent for a gap of a couple of centuries between impeachments).

I think the postgresql maintainers don't claim to support moving a database from x86 to arm without a dump-and-reload. The docs tend to say "same hardware architecture". Though if they don't intend to support this case I think it's a shame if the pg_control checks allow the server to start after such a migration.

> I think the postgresql maintainers don't claim to support moving a database from x86 to arm without a dump-and-reload

I would be very surprised by that because that means replicating a database between the two platforms would lead to corruption.

btw, this bug breaks dump-and-reload too. If you use partitioning, each partition is dumped and restored individually. In this case though, you'll get an error when you try to restore the data because it's trying to put data in the wrong partition. That's better corruption, but still an issue.

The physical replication docs say "the hardware architecture must be the same", though they don't define "architecture".

GitHub also centralises abuse detection. I'm not thinking about sophisticated attacks here so much as dealing with plain old spam. That's fairly easy to deal with on a tiny scale, and possible on a huge scale, but it's a great pain at a medium scale.

Do they though? Slow PRs have been a consistent pain point for GitHub hosted projects lately.

It's common that if you extract a function or a module with a well defined interface, that function or module can't tell whether a "bad" input indicates an expected or an unexpected error.

For example division by zero often indicates an "unexpected" error, but it wouldn't if you were implementing a spreadsheet.

So to me the approach of using different forms of error reporting for the two kinds of error doesn't seem promising: if you imagine you had to implement division yourself, which kind of error should it report? Should you have two variants of every fallible function so the caller can choose?

That's a deficit of most programming languages. One solution is to pass every error value up and let the caller decide. Rust does this to some extent. This leads to verbose code however.

For modules inside your application, designing a good interface involves exposing the right errors and crashing for the rest. This creates some coupling of course (shared assumptions of which errors need to be handled across modules). Trying to avoid that probably just leads into the circle of hell where you have more abstract beancounting than useful code.

In the end, this is another reason why overreliance on external libraries leads to mediocre, buggy software.

Not any more, according to this article you're commenting on, no.

the comment you are replying to is talking about marginal cost pricing, which wasn't addressed by this article.

> This price-setting dominance is being eroded by renewables, with recent analysis from the UK Energy Research Centre showing that gas set power prices 90% of the time in 2025.

> If a package hosted by Fedora or Debian or PyPI or crates.io, etc claims to correspond to an upstream git commit or release, then the hosting system should build the package, from the commit or release in question plus whatever package-specific config and patches are needed, and publish that.

For Debian, that's what tag2upload is doing.

They weren't in any way attempting to rely on security by obscurity.

They didn't assume nobody would guess the URL.

They did take active steps to ensure the data was only available at the correct time.

But they didn't check that their access control was working, and it wasn't.

Is this a real judge, or is an "Immigration Judge" one of those not-actually-a-judge decisionmakers employed by the executive?

The latter. They're not even real administrative law judges.

I think what you've written is pretty much what the "almost all programs have paths that crash" was intended to convey.

I think "perhaps the density of crashes will be tolerable" means something like "we can reasonably hope that the crashes from Fil-C's memory checks will only be of the same sort, that aren't reached when the program is used as it should be".

It makes tab completion work.

At the start of a line? So you want to run a script or executable in the current directory. PATH doesn’t contain . and ./ is necessary.

As an argument in a line? My shell offers completion from the current directory without ./ just fine.

Let's say you have 100 programs in your PATH that start with the letter "g", but only one program in the current folder that starts with "g". You type `./g[TAB]` so it autocompletes automatically to the local program instead of cycling through dozens of results you know you don't want.