pradn

The key is that the probes

a) are fast: they certainly incur the same network cost of a regular request. But more than that, all they do is read two counters, so they're super quick for backends to serve.

b) cheap: they don't do nearly as much work as a "real" request, so the cost of enabling this system is not prohibitive. They simply return two numbers. The probes don't compete with "real" requests for resources.

c) give the load balancer useful information: among all the metrics they could have returned from the backend, the ones they chose led to good prediction outcomes.

One could imagine playing with the metrics used, even using ML to select the best ones, and to adapt them dynamically based on workload and time period.

Optimizing tail latency isn't about saving fleet cost. It's about reducing the chance of one tail latency event ruining a page view, when a page view incurs dozens of backend requests.

The more requests you have, the higher the chance one of them hits a tail. So the overall latency a user sees is largely dependent on a) number of requests b) tail latency of each event.

This method improves the tail latency for ALL supported services, in a generic way. That's multiplicative impact across all services, from a user perspective.

Presumably, the number of requests is harder to reduce if they're all required for the business.

It makes total sense for European farmers to cry foul if cheaper imports get to masquerade as the real thing. This has been a big sticking point for the EU-Mercosur deal that recently concluded.

The price seems entirely reasonable. $200 is about 1-2 hours of a professional's time in the USA.

It's in everyone's interest for the company to be a sustainable business.

Cookie banners are just one more reason why it's so painful to use the web. They are nothing but required pop-ups! Making it painful to visit sites hurts the internet ecosystem. Might as well stay in walled-gardens, where ads are occasional, but less intrusive.

Twitter used to have an app, Periscope. You could start a livestream any time, anywhere. And viewers could fine live streams on a world map.

For a few months, it was possible to feel the incredible simultaneity and richness of human lives. Someone biking, another person cooking. Day in one place, night in another place.

It was ahead of its time. And too expensive for Twitter to keep running for too long. But it was a precursor to today's Snapschat's map view and Instagram live streams.

Honestly, for any serious query, the links serve mostly so you can double-check the AI. That's a useful function however.

I think we're going to see even fewer site visits as a consequence of AI search engines. The internet's ad-based funding model is going to dry up further, but the impact will be disproportionate. It'll be a few years til we see where the cards land.

Well the whole point of this product is to link back to websites. There’s no necessary link between the text and the links, which are chosen after the fact from an index. That’s different from traditional search engines, where links are directly retrieved from the index as part of ranking.

Valve is trying to obsolete Windows, so they can prevent Microsoft from interfering with Steam. Apple could team up with them, and help obsolete Windows for a very large percentage of game-hours.

There will always be a long tail of niche Windows games (retro + indie especially). But you can capture the Fortnite (evergreen) / Dragon Age (new AAA) audience.

Anyone know how well this works with Godot?

That's great to know - business customers require a lot more stability, I suppose!

I suppose business customers are savvy and will do enough research to find the best cost-performance LLM. Whereas consumers are more brand and habit oriented.

I do find myself running into Claude limits with moderate use. It's been so helpful, saving me hours of debugging some errors w/ OSS products. Totally worth $20/mo.

Great progress from Anthropic! They really shouldn't change models from under the hood, however. A name should refer to a specific set of model weights, more or less.

On the other hand, as long as its actually advancing the Pareto frontier of capability, re-using the same name means everyone gets an upgrade with no switching costs.

Though, all said, Claude still seems to be somewhat of an insider secret. "ChatGPT" has something like 20x the Google traffic of "Claude" or "Anthropic".

https://trends.google.com/trends/explore?date=now%201-d&geo=...

Advanced civilizations get good at using unusual materials like lead and mercury. Some of these come with unforeseen consequences. Plastic and oil are the two substances most like these for us in present day.

I've stopped carrying my over-ear noise-cancelling headphones for this reason. They take up like a quarter/half of a normal item-sized backpack. I can sleep with plane noise. But I always bring a sleep mask, because I can't sleep with bright lights turning on and off all the time. I did recently get some in-ear headphones w/ noise cancelling, perhaps they're enough.

There's always the fear of losing stuff when you're moving objects around so much, too. One less thing to worry about.

The paper is at [1], and the summary chart is at [2].

The top chart shows which of the three bodies escapes the system given initial starting conditions. The bottom one makes it easier to see patterns by reducing noise. It uses the k-nearest-neighbors algorithm to find the dominant color near each pixel. More than the large pools of stability, what's interesting are the bands of stability - like electromagnetic fields.

I have no idea how one codes this up in a computer, with fixed precision math and all. Numerical methods is a black box for me.

[1]: https://doi.org/10.1051/0004-6361/202449862 [2]: https://www.aanda.org/articles/aa/full_html/2024/09/aa49862-...

I wonder if you could just madvise the entire address space. My hunch is that it's for performance reasons only - fewer pages to scan, hash, and de-duplicate.

Ah, good to know! Thank you for explaining.

I guess much of this is why its hard to use shared libraries in the first place.

It's possible for the OS to recognize that several pages have the same content (ie: doing a hash) and then de-duplicate them. This can happen across multiple applications. It's easiest for read-only pages, but you can swing it for mutable pages as well. You just have to copy the page on the first write (ie: copy-on-write).

I don't know which OSs do this, but I know hypervisors certainly do this across multiple VMs.

You can still download specific files from torrents of many files, yes. You can pick a subset of files to download.

In theory, you could extend torrent clients to support archiving some subset of the files. You just tell it to keep around 100 GB of files in a 10 TB torrent. Since the client knows the status of each chunk in the swarm, it can make smart decisions about which chunks to download and seed. Clients already let to set preferences to seed the "least-seeded" chunks. So this isn't so far fetched.

The big problem with this is that it lets you work only with a fixed archive. Torrent files can't be mutated after they are created. So you'd be able to get people to archive a fixed version of a shadow library, but not an evolving one.

In practice, this should be fine enough. If we had high assurance that all the books added to the library before 2022 (or something) were copied in 50 machines, that's quite useful.

Being able to layer deltas on top would be amazing - you could evolve the collection as new books are added.

I like IPFS, and want it to continue improving, but it is just too slow, uses too many resources, and is often unreliable.

https://annas-archive.org/blog/putting-5,998,794-books-on-ip...

You’re talking about possible sibyl attacks. Yes that’s a concern but there’s a large literature on how to reduce their threat.

This might be a place where “proof of x” concepts from crypto land work.

But we don’t need to go all the way to the maximal solution for it to be practical.

The critical thing here is that regular people can help. The archive is already split into many O(GB)-sized chunks. We need to ensure each chunk has many, many copies.

Torrents are a widely-understood, robust way to mirror large files. But there's no "meta-coordination" built in to the protocol. It's not possible, using just torrents, to have the swarm cooperatively assign who stores which chunks. The optimization function here is maximal chunk availability, subject to individual storage limits and reliability (ie: how often they're online).

It should be easy to just press a button to join a shadow library, allocated 100GB, and be part of the mission.

The best effort I've seen in this space is some guy running a script that crawls the number of seeders for a list of SciHub torrents. Users manually pick the ones with the lowest seeds. All very cumbersome, and prone to staleness.

Of course, this is all a technical problem, separate from infringing copyright or whatever. In the same way as torrents being a technical solution for sharing files, in a general way.

The use-case for having isolated objects with parameters, much like classes in Java, is to be able to a) share code, b) hide internal details, and c) have object behavior be governed solely by a constrained set of inputs.

So the point isn't to have your web component be different from the rest of the page. The point is that you can pass in parameters to make an off-the-shelf component look how you want. However, exactly how much freedom you want to give users is up to the component author. It is possible for there to be too little freedom, true.

See here [1] for a concrete example of someone writing a reusable web component, and figuring out how to let users customize the styling.

[1]: https://nolanlawson.com/2021/01/03/options-for-styling-web-c...

How has Systems Theory changed how you think? Is there a good book you recommend on the topic? Thank you!

Graphs are inherently "chatty" because there are more shapes in which you could store them. The same goes for querying. Similar to "degrees of freedom".

Even storing a graph in memory, you're going to have load a lot more cache lines to traverse/query its structure. For remote graphs, this translates into more network calls.

The smart thing Netflix did here is finding the minimal abstraction that supports their online querying needs. Turns out that they need a few things above a bare KV store:

1) Idempotency keys allow multiple reads/writes without reordering issues. You can use them to do request hedging, which greatly helps w/ tail latency, at the cost of higher resource usage.

2) KV, with the value being a map. A little more structure, which can use the backing store's native structure.

3) Passing client/server parameters back and forth in a handshake. This allows clear request policy propagation, so the whole path behaves the way the client op wants it to.

4) Filtering/selection - to reduce the set of items returned, on the server side. So the network + client don't have to bear the extra burden.

The summary is: "minimal viable structure", "maximal chances to hedge requests / reduce data movement".

This isn't all so unusual if its written into the job description. SREs in tech companies are expected to respond within a few minutes if they're paged in the middle of the night. They are usually compensated for their oncall time, however.

Expecting a worker to come to the factory out of fear or good will is not the way. Just write it into the contract/expectations/evaluations.

If image sensor / lens system quality are orthogonal to the final megapixel output, why bother with 48MP output JPEGs? They take up more space, so the practical benefit to smaller files is there.

The optical zoom on the Pro is so good! I often zoom in 3-5x and still get great results. I've gotten comments from people saying they thought photos of far off building features, etc, were taken with a DSLR.

It's a no-brainer to get the Pro for this reason, if you care about photos.

Thank you, that's useful!