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.

  option::picker-current { ... }

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.

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

Go got this right.

Comments URL: https://news.ycombinator.com/item?id=41497876

Points: 2

# Comments: 0

This feels like a new genre of hardware hacking to me, where someone is motivated to make a device out of compassion for their family or others. It reminds me of this instance where someone designed their own peristaltic pump to ensure their grandfather can eat:

https://hackaday.com/2015/11/10/3d-printed-peristalic-pump-h...

I seem to recall another similar device to this posted on HN also, but with audiobooks.

On an unrelated note, the modern digital age does deprive me of my longtime love of removable media, whether analogue or digital. There's a mechanical satisfaction in having a physical token which is decisively inserted into something. USB drives just don't have the kinetic enjoyment of a floppy disk or tape. (Clearly the next iteration of the OP's design needs a motorised NFC card loader, ATM-style. ;))

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.

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.

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.

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

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.

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

The second quote relates to the greater adoption in the 1990s. But this is far after the initial adoption by the London Underground in the 1920s, and presumably these safety issues during the period 1920-1990 weren't so great as to be a showstopper, even if a safer design is preferable. This suggests to me that there was some other, much stronger motivating factor behind the development of the technology in the 1920s on the London Underground, with safety being a trailing motivator.

The third relates to a design issue entirely orthogonal to the design of the doors.

In a word: yes. The universe is cold, ruthless, and does not care about us. I make no claims otherwise.

Society isn't that, though. Not least because nobody is particularly happy about the above fact and most people are trying to get away from it, not embrace it. And so, society is made up of people who have the capacity for empathy and adaptation to the nuances of others. So the relevant comparison here is not the timeframe before human civilization came to exist, but the society which existed prior to computerisation.

The adoption of computers within a society largely replaces human-to-human interactions with human-to-computer interactions, or interactions between humans which are now modulated and controlled by a computer (human-computer-human). That adoption trend inherently converts relationships between humans which are adaptable and contain a component of empathy, to interactions controlled by non-adaptive machinery with no capacity for empathy.

The adoption of computers as a technology within the context of a society seems, to me, to make society inherently more oppressive and less humane for this reason. (The main exception I would grant is computers only used by the people who have freely chosen to own them (as per comment above), and to which other people aren't subject to non-consensually.)

This misses the point that computers are a technology. Like any technology, the choice to adopt a technology is always made by a human actor with some knowledge of the relevant tradeoffs. Ergo, wilful adoption of a technology which (necessarily) possesses the attributes I describe can be taken as tacit consent to those attributes and the collateral damage they cause. There is a human actor hiding behind every life ruined by "computer says no".

Saying that no technology is inherently oppressive is strange to me. Are prisons not by design an intentionally oppressive technology?

The human perception of agency in inanimate objects is curiously variable. To my understanding, this is a factor in why some people are more religious and some people are less so. Since my article is intrinsically written from the capacity to perceive agency as present in an inanimate object, it's perhaps less compelling to people who aren't wired this way, is my guess. This is not a criticism of anyone, just an observation of an interesting human neurological variability. Other constructions of the same argument are of course possible.

In any case, the point here is that a human actor decides to adopt computers as a technology; and that that act generally replaces a human interaction which was previously social, human-to-human, and therefore on some level adaptive and modulated by empathy, whereas a human-computer interaction is inherently uncaring. The adoption of computer technology in society has led to a generalised trend of replacing human-human (social) interactions with human-computer or human-computer-human interactions, which generally remove all opportunities for adaptation or empathic variation.

This leads to my view that computers as a technology in society are inherently oppressive.

Though I suppose one possible qualification would be that this possibly is only the case when applied as a technology by a different party to the party which will be subject to it. A computer in someone's home by their free choice, which is purely controlled by them (which is therefore not any modern computer, I should note) seems like an exception.

Can you elaborate? I don't see anything to support this claim from the link you provide.

You are correct that the completion of the phase-out of slam-door rolling stock in the UK will relate to modern safety (and accessibility) regulations, amongst other factors. But that is different to what motivated the initial introduction of remotely controlled doors, which as that article states, dates back to the London Underground in the 1920s.

While it might be the case that centrally controlled doors are mostly more safe (with some exceptions), that mere fact doesn't imply that it is the primary motivating factor behind the historical adoption trend. So it's an interesting claim, but unless I'm missing something in the link I don't see it as supporting this claim?

I suppose a cookie could be used in a "trust, but verify" approach if the free function takes both a pointer and a cookie. You would have the usual sidecar data next to the allocated region, but verify that the cookie matches. This would avoid the lookup issues you discuss.