mattashii

How can you use the same signer when the signer's keys are lost?

Or, if the signer's keys are compromised, how do you switch to a non-compromised signer without alarms triggering?

The problem is almost exactly the same as one with a delegated CA -- if the CA keys are compromised, you have to re-issue all certs. When the client pins the CA key then the chain of trust is permanently broken.

> The browser would be able to take policy of simply never trust a certificate whose signer has changed

This assumes that the signer's keys can't be compromised, and re-introduces the issues of key pinning that the WebPKI community has been pushing very hard to eliminate from its dependents. I don't think it's a workable solution.

I remember that PR for similarly interesting reasons:

Someone on the pgsql-hackers@ mailing list noticed that, with a then-recent OpenSSL version on graviton, there were issues validating the "control file" of a PostgreSQL instance [0] (control files contain some basic ground truths about a cluster).

The report included a lot of detailed information about the program state, sufficient for me to figure out that one of the registers was definitely getting clobbered during the pg_strong_random() calls[1], but without access to the environment I couldn't prove whether it was the OpenSSL library, or a compiler bug.

A few days later an Apt developer was debugging the same issue from another direction, eventually figured out that this was caused by a typo in openssl's register restoration code (which was written in ASM introduced in the PR linked by parent post), and then submitted a PR to OpenSSL to fix the issue [2], now (presumably) for good.

[0] https://postgr.es/m/Z4VjonBTm6IG8mGa%40msg.df7cb.de

[1] https://postgr.es/m/CAEze2WiRijBaoeFgi1JvsZeO6qXvpYkh4ax1bUV...

[2] https://github.com/openssl/openssl/pull/26469

The accused was found guilty, and this looks like it was a low hanging fruit for the defense to get the sentencing reverted.

> Having secondary indexes point the primary key enables things like undo logging

That's neither here nor there. Heap-oriented tables can have undo logging, too; and index-oriented tables don't strictly require undo logging.

It's just that you're much more likely to want something like undo logging for index-oriented tables, because maintaining uniqueness for rows that are not in-place updated in the index becomes very expensive as more and more versions of the same key value may need to be checked for visibility and liveness, and removing old deleted versions becomes a maintenance hassle, too. It can be done without undo logging, but apparently that wasn't a sufficiently robust (or performant) design.

Only in the worst case when the plans are equivalent: If one plan is significantly faster, then it'll finish first, and the loser can get canceled before it finishes.

That's fair criticism. The deeper reason why it's not a constitution is because it's not the cornerstone of legal, moral, and existential rights of the signatory constituent countries. These countries each have their own constitution that they are beholden to, with no higher authority to fall back to.

The Treaty of Maastricht (and later, Lisbon) can't be guaranteed to have precedence when called upon if they conflict with the constituent countries' constitution(s), and all legislation covered under the treaties must be implemented separately and completely as locally applicable laws before going into effect. The EU regulations generally prescribe a deadline for implementing such regulations, but a country could (and sometimes does, see e.g. Hungary under Orban) break its obligations under the Treaty and ignore or never implement the agreed-upon regulations, and the EU would be unable to do much to enforce its regulations.

Nope, it doesn't. It's current legal basis is a series of treaties, the attempt to create a constitution failed when in 2005 the various countries' local referenda on supporting an EU constitution failed to garner the required support. FRA' referendum failed 45-55, and NLD's consultative referendum on June 1 also gave a solid "no" (38.5% yes vs 61.5% no).

Assuming a given fixed key size, where does RSA need non-fixed-width arithmatic? AFAIK you can do all RSA maths with registers just double as wide as the key, no variable width anything required there. And I don't think that this is much different from ECC maths, apart from ECC's keys just being way less wide for an approximately equivalent security level.

Moving hot air around with a fan in a closed car will save dogs nor kids from overheating.

Whilst they may provide a strong signal, I wouldn't call it a guarantee. If I wanted to avoid vibe-coded contributions I might add such files, but with instructions for the agents that they're not allowed to read or touch any of the files in the repository.

I don't think it's that different from pointing out that registering and/or operating a company in e.g. Delaware or Texas is a very different experience from doing so in New York.

If the status column changes, and an index depends on the contents of that status column (be it by referencing it in its columns, or in the index's WHERE filter) then an update of the status column will prevent the HOT optimization from being applied.

Possibly, ballot sheet size?

The national elections in NLD have a single ballot in the whole country, with 10+ parties who each get a column of their candidates on the ballot, and with one box for each of the candidates. In these elections for the 150 seats of parliament, often there are 200+ candidates listed total. As a result, the ballot sheets need to be quite large and so are quite far into the 'unwieldy' part of the handling spectrum.

This size issue also complicates verification and counting, because you have to verify that of all checkboxes, exactly one is filled in, and sorting/counting needs to do this for practically every ballot.

There has been some experimenting with changing the ballot to a 'party' and 'list number' ballot, where you fill in the party of your chosen candidate together with their number on the party list, but AFAIK that has not (yet?) been approved for wider use.

The order returned from the Index Scan is not the ordering requested by the user, so there would still have to be a full (or topk) Sort over the dataset returned from the index scan, which could negate the gains you get from using an Index Scan; PostgreSQL itself does not produce merge join plans that merge a spread of index scans to get suffix-ordered data out of an index.

Epic wasn't fined for putting things on sale. Instead, it was fined for putting pressure on children to buy things that were put on sale; e.g. through wording like "Get it now" and "Grab it", and through design.

For details, check the ruling here (Dutch): https://uitspraken.rechtspraak.nl/details?id=ECLI:NL:RBROT:2...

There is also a lot of money, there is also good management, and there are also lots of incentives.

But management depends on your manager; at scale it becomes likely there are bad apples in every management tree. Incentives may not align with what you want or need, with work From Home policies getting shrunk. Even money sometimes is a point of contention.

That's why they're called generic parameters, not template parameters; the code is generic over all possible parameters, not templated for every possible parameter.

It's true that the transistors are on the order of 50nm, but the conduits for getting the electrons to those transistors are presumably a bit smaller than that.

Probably not 7nm small, but not the full 50 nm either.

Facebook Nederland B.V. is just one of the defendants; the other defendants are Meta Platforms Ireland (based in Ireland), and Meta Platforms Inc. (the main company, based in the USA)

The Dutch subsidiary has been acquitted, as it only managed advertisement income, not the app design.

Meta Platforms Inc. has been acquitted, as it itself doesn't directly provide apps or services in Europe (nor the Netherlands) - legally that's managed by Meta Platforms Ireland and so not Inc.'s responsibility.

Meta Platforms Ireland has been ordered to implement these changes, enforced by the up to 5 million euro fine (see pages 20 and 21 in the verdict)

Judgement (dutch): https://www.bitsoffreedom.nl/wp-content/uploads/2025/10/2025...

The judgement requires Meta to change their platforms within 2 weeks so that the user's choice is persistent. If not implemented in 2 weeks, there is a daily penalty of €100'000, up to a maximum of €5 million.

If stocks are on fire then you should probably value them for their ash contents.

> They do handle minor versions upgrade so the code handling upgrading is there but devs seems to be quite adamant against adding major version upgrade

Minor versions of PostgreSQL have constraints that major versions don't have; in that minor versions in principle don't see new features added. This allows minor versions of the same major release to run against the same data directory without modifications.

However.

Major versions add those new features, at the cost of changes to internals that show up in things like catalog layout. This causes changes in how on-disk data is interpreted, and thus this is incompatible, and unlike minor releases this requires specialized upgrade handling.

Doesn't look like it, no. At least not to the degree that it has updated the table AM interface.

Those are some great features. More than I remembered, and it's only been a year.

Personally, I'm very happy to see parallel builds for GIN indexes get released - (re)index time for those indexes is always a pain. I'm looking forward to further improvements on that front, as there are still some relatively low-hanging fruits that could improve build times even more.

(Opinions are my own, not of my employer)

I think that "under review" claim is doing some very heavy lifting, especially when it relates to their changes to index tuple lifecycle management. The patches that have been submitted are unlikely to get committed in full anytime soon, even after substantial changes to the patches' designs.

PostgreSQL just has not been designed for what OrioleDB is doing, and forcing OrioleDB's designs into PostgreSQL upstream would a lot of (very) sharp edges that the community can't properly test without at least a baseline implementation - which critically hasn't been submitted to upstream. Examples of these sharp edges are varsized TIDs, MVCC-owning indexes, and table AM signalled index inserts.

There are certainly ideas in OrioleDB's designs that PostgreSQL can benefit from (retail index tuple deletion! self-clustering tables!), but these will need careful consideration in how this can be brought into the project without duplicating implementations at nearly every level. A wholesale graft of a downstream fork and then hoping it'll work out well enough is just not how the PostgreSQL project works.

I think what they refer to is that while the interests of the individual and the country almost never align, the government can work to align these interests; e.g. through tariffs on trading with that other country. By doing so, a country can reduce/remove the incentive to trade with that other country's individuals, thus aligning the interests.