noctune

Or cloudformation, if it is just for AWS anyhow.

Locality is a property of how data is arranged, so it's a property of the data structure, no?

KD-trees select their splits according to the contained points. That tends to make them better for static sets of points, but updates become expensive. Quadtrees are often used in e.g. physics engines.

Some patterns must happen to repeat, so I would assume the offset to be larger, no?

You might be interested in https://connectrpc.com/. It's basically what you describe, though it's not clear to me how well supported it is.

It doesn't help that URLs are badly designed. It's a mix of left- and rightmost significant notation, so the most significant part is in the middle of the URL and hard to spot for someone non-technical.

Really we should be going to com.ycombinator.news/item?id=45789474 instead.

I built something similarly a few years ago for `sort | uniq -d` using sketches. The downside is you need two passes, but still it's overall faster than sorting: https://github.com/mpdn/sketch-duplicates

I overall agree with the article; GitOps is great for managing long-lived, shared, stable systems you need a good audit trail for (like production), but testing isn't one of these. Test environments should ideally just be something non-shared you can just spin up and make changes to without asking for permission.

I don't understand why features like S3's "downloader pays" isn't more widely used (and available outside AWS). Let the inefficient consumer bear their own cost.

Major downside is that this would exclude people without access to payment networks, but maybe you could still have a rate-limited free option.

You can condition IAM on Nitro attestation, so that's doable (if a lot more work than usual).

The XZ utils supply chain attack also used this to sneakily disable Linux Landlock: https://news.ycombinator.com/item?id=39874404

You can use a radix heap rather than a binary heap. I have an implementation here, with benchmarks using pathfinding: https://github.com/mpdn/radix-heap

It has the nice property that the amortized cost of pushing/popping an element is independent of the number of other elements in the heap.

S3 recently got conditional writes and you can use do locking entirely in S3 - I don't think they are using this though. Must be too recent an addition.

I think you could make by with some kind of async memory-touch system call, i.e. "page in this range of memory, notify me when finished". The application would have to call this on blocks of the mmap prior to actually reading it.

This of course means you lose some of the benefits of mmap (few system calls, automatic paging), but would maybe still be beneficial from a performance perspective.

It is very common to have dependencies outside of Cargo. Take cc, the most popular crate for calling the system C/C++ compiler. It currently has 1983 other crates that depend on it [1].

[1]: https://crates.io/crates/cc/reverse_dependencies

The xz backdoor did hide the payload in test data though. Proper sandboxing could have meant that eg. building the binary wouldn't have access to test data.

I don't really agree - I think its more the case that the build system should be able to prove that tests and test files cannot influence the built artifact. Any test code (or test binary files) going into the produced library is a big red flag.

Bazel is huge and complicated, but it allows making those kinds of assertions.

In Scala there's Future.delegate for turning sync failures into failed futures. Seems like something equivalent should be possible in Javascript.

7 digits of the hash makes for 16*7 possible hashes. I spot 4 potential "filler" lines in that tweet, so if you find log4(16*7)=14 candidates for each of those filler lines, then one combination would be expected to yield that hash.

In my experience, the problem usually is that severity is context sensitive. For example, a external service temporarily returning a few HTTP 500 might not be a significant problem (you should basically expect all webservices to do so occasionally), whereas it consistently returning it over a longer duration can definitely be a problem.

Personally, I use "regex" for the informal string-matching/rewriting engines found in most languages and "regular expression" for the formal definition.

Wouldn't it be simpler to use a trie over the hashes instead? It seems to me like it would have the properties desired here. I think the parent/child rule described here might actually result in some kind of trie.

JSON is fine for inter-machine communication (like APIs). It's IMO terrible for human-to-machine communication (like configs), which is why there are so many alternatives trying to improve in this space (TOML, YAML, RON, etc.).

JSON supports numbers of arbitrary and just fine. It's just many reader/writers of JSON does not, and those are so ubiquitous that it's often not practical to use.

It seems pretty likely that, at some point in the lifetime of a thread, it will consume a lot of the stack and thus touch those pages. And there isn't a mechanism for deallocating those pages again, right?

Tying your memory consumption heavily to the max stack depth also seems like it would be difficult to reason about IMO.

Immutable hash maps are generally O(lg n) inserts and updates, where the mutable counterpart is O(1). So it's not without cost.

Sure, but for some structures it amortizes to log(n) where mutable structures can amortize to O(1).

And persistent memory structures also tends to have a cost. For example, persistent maps are usually O(lg n) lookup and insert rather than O(1) usually seen in mutable maps.

If I remember correctly this is a pretty fundamental limitation of persistent structures, so it's not like there is a better persistent map data structure out there waiting.

You are thinking of a 'dialog box'.

100% efficiency is terrible compared to the 600% efficiency of a heat pump.