bup is focused on backups. Would you say that noms is useful as a backup utility?

Do you have any mechanisms for securing integrity, specifically repairing the store in case of inconsistencies?

Is there any plans to support any data retention policy/functionality?

Noms should be useful as a backup utility, but I'd say it's especially useful for backing up data which is not files. Think about backing up data which you only have access to via API.

You can take the JSON output of an API and drop it into Noms, then do the same thing tomorrow, and Noms will automatically deduplicate the data as well as give you a nice structured API to read and interact with it.

We have an example of this here: https://github.com/attic-labs/noms/tree/master/samples/js/fl... but it's not working atm due to a bug introduced right before launch. You can look at the code though.

Similar quirks in the Python example. Opening the file should ideally be done with a "with" statement to close the file automatically at the end. But in the Ruby example the author at least closed the file instead of doing nothing as in the Python example. :)

Looks interesting for the niche purpose! I certainly can think of a couple of use cases.

But I don't understand why the build script is written in Python? I think that either you should use a simple shell script or stick to Go.

Because I like Python more than Bash script, maybe I'll consider using a more gopher way to do the build.

Maybe I'm missing something, but if an attacker can update the firmware without Apple's RSA key, then Apple (or you self) should be able to flash it in the same way the attacker did (even though the official update procedure is blocked) and "fix it", or?

This attack "closes the door behind it" so that you can't use the same vector to undo it. Specifically it completely disables loading option ROMs.

I see, thanks for the explanation! Hopefully we'll see an EFI upgrade fixing it soon.

The attacker can essentially "seal" the firmware in by writing a modified BIOS that either skips executing option ROMs, or write-protects the flash before executing them (as Apple's firmware should've originally done); then you'd need to use hardware to reflash.

I see, thanks for the explanation! As written in the other response, hopefully we'll see an EFI upgrade fixing it soon.

This is a known method for fixing this type of problem where the solder has been damaged due to excess heat and/or improper cooling from the start. It's also known that this is most likely a temporary fix where it will fail again in a couple of months (depending on the usage etc.).

This is also why I would take great caution purchasing a used laptop (especially with a discrete graphics card). It's a real risk that the previous user did this trick to quickly sell it while it's "working".

As an owner of a 2011 Macbook Pro with AMD graphics (known to fail) I sure hope that Apple acknowledges this issue soon.