mjw1007

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).

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

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.

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.

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?

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

> 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?

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.

One of the things that this group of "stewards" could do to get their costs down is get together and implement a high quality free software caching proxy that understands all their back-ends.

But that would compete with the commercial offerings of at least one of the organisations sponsoring that message. So I expect they won't do that.

It's clear from that bug tracker that you shouldn't let libxlst see untrusted stylesheets or xpath expressions.

I haven't yet seen a problem with running your own transformations against untrusted XML.

Maybe a new maintainer could aim to make the second case fully supported but not the first.