hlandau

I haven't laughed this hard in a long time.

I'm honestly having difficulty telling whether this is real or an extraordinary piece of performance art.

I'm a bit confused.

This is described as being related to 'NitroTPM', which is described as a 'virtual device [...] which conforms to the TPM 2.0 specification'.

Ordinarily, the way you do attestation with a TPM is to perform a TPM quote operation, which provides a TPM-signed attestation of a set of PCRs.

This is... not that. This appears (judging by looking at the source code for some of the provided tools) to be invoking an undocumented(?) vendor-specific command on the TPM device which appears related to the previous Nitro Secure Enclaves support. When AWS introduced Nitro Secure Enclaves, they came up with their own signed attestation document format rather than reusing the TPM standard, then added support for that format to KMS.

The documentation also states: "An Attestation Document is generated by the NitroTPM and it is signed by the Nitro Hypervisor."

This seems to suggest that different entities are responsible for generating AWS's Attestation Document and for signing it, which seems rather odd. What's going on here?

If AWS's claims that NitroTPM is TPM 2.0 compliant are true, it seems like there are now basically two completely different APIs for remote attestation exposed via the TPM virtual device: TPM 2.0 Quote operations and AWS Attestation Documents via an undocumented(?) vendor-specific API.

I can understand wanting to take this approach for consistency with their previous Nitro Secure Enclaves API but it's at the expense of consistency with the existing TPM 2.0 standard. Presumably if you want to use KMS with this you have to use their Attestation Document format rather than a TPM 2.0 Quote, forcing you to use a vendor specific API with it.

Just some thoughts, and this is just my quick impression. I could be mistaken. In any case, having this functionality with a viable KMS tie-in is certainly valuable, so it's nice to see in the sense that you no longer have to create a Nitro Secure Enclave to get this kind of functionality if you don't need the dual compartments separated via a vsock.

Most webapps would be dramatically improved if the developers were banned from using any JavaScript on the client side in the first version, and allowed only to apply progressive enhancements from there.

This seems overcomplicated. Maybe I'm missing something, but is there some reason not just to define a psuedoelement on the current option?

  option::picker-current { ... }

With every new PostgreSQL release we see yet more features and sugar added to the frontend, yet seemingly no meaningful improvement to the backend/storage layer which suffers these fundamental problems.

I wish the PostgreSQL community would stop chasing more frontend features and spend a concerted few years completely renovating their storage layer. The effort in each release seems massively and disproportionately skewed towards frontend improvements without the will to address these fundamental issues.

It's absurd that in 2024, "the world's most advanced open source database" doesn't have a method of doing upgrades between major versions that doesn't involve taking the database down.

Yes, logical replication exists, but it still doesn't do DDL, so it has big caveats attached.

The underlying lesson here should be that centralised package registries are unnecessary, yet new language ecosystems keep making the same mistake.

There's really no reason for NPM or crates.io to exist.

Go got this right.

Very nice!

Not free, but the "Technic", "Simplex" and "ISOCP" fonts included with AutoCAD are also of this aesthetic, if people want an exhaustive list of candidates.

Personally I've always considered it bad hygiene to commit generated outputs, but this article notes that this takes on a new significance in the light of supply chain security concerns. Good changes from PostgreSQL here.

Generated output, vendored source trees, etc. aren't, or can't be, meaningfully audited as part of a code review process, so they're basically merged without real audit or verification.

My personal preference is never to include generated output in a repository or tarball, including e.g. autoconf/automake scripts. This is directly contrary to the advice of the autotools documentation, which wants people to ship these unauditably gargantuan and obtuse generated scripts as part of tarballs... an approach which created an ideal space for things like the XZ backdoor.

The problem (at least for me) is input format support.

Assorted foobar2000 plugins support every obscure tracker format, every obscure video game music format (.vgz, etc.), and then foo_midi lets you render MIDIs not just with Soundfonts but with whatever VSTi DLLs you like. Also support for music files in ZIP files as well as music files in ZIP files in ZIP files (don't ask). That's hard to compete with.

foobar2000 is so good, and so unmatched, especially with its plugins ecosystem, I use it for my music playback needs under wine on Linux.

Interesting.

Are there better MCUs on the market for these applications (other than massively expensive actual 'rad-hardened' space chips)? You can get MCUs with lockstep dual CPUs, for example (TMS570 etc., and I assume the automotive sector has loads of stuff).

The context of this discussion is my claim that "the adoption of electric, centrally controlled doors was naturally motivated in major part by timeliness."

You're claiming that this is refuted by the Wikipedia article, but I don't see any evidence for that. To be clear, I'm open to evidence that this isn't the case, there just isn't any there, because it discusses motives for adopting centrally controlled doors in the 1990s when the technology for centrally controlled doors was already widely available. It doesn't tell us anything about the initial motives for developing the technology for centrally controlled train doors many decades earlier, just that later on an additional motive showed up which drove some additional (late) adoption.

I would absolutely consider prisons a technology, most obviously because we can see human societies where prisons are not a viable technology. If a member of a more primitive tribe starts killing people, the pragmatic solution is to kill them, not incarcerate them. Incarceration imposes technological (e.g. can you build buildings strong enough to hold people involuntarily?) prerequisites and high or extremely high logistical costs (see the cost of housing a prisoner for a year in the UK). You ultimately also need guards and the spare labour in society to be able to allocate to that task instead of potentially more important tasks, like obtaining food. Whether that is feasible will in turn be determined by human productivity in the various fields of production, in the case of food which is determined by the availability of agricultural technology (50% of the UK workforce used to be working on agriculture, now only about 2% to my recollection). Incarceration on the scale we see today is a relatively recent phenomenon.

Obviously such technology can be good or bad.

In my view the IT community falls into the trap of a narrow definition of the term, which now has been supplanted by an even narrower definition where technology just means "IT".

See the other thread above for my thoughts on the latter part. The adoption of a technology is done by the decision of a human. Nobody's claiming that computers have imposed themselves on society...