[dead]
Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
271–280 of 305 posts
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#272Are they selling that RAM?
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#273Earlier quoted context omitted.
> is it possible to buy a reasonably nice home located in a reasonably nice amerikkkan city… for $300k in 2026? What does "city" mean to you? For some, it's 500 people, or 5,000. For some, it's 5 million. Define that first. The US is a big place, and I know people that don't live within 50 miles of another human. Otherwise: https://www.zillow.com/homedetails/424-Olive-St-Kansas-City-... 4 bed, 3 bath, 1,580 sq ft, be…
That’s 350, which you can’t buy for 300..
If the extra $200/month means you can’t afford it, you probably shouldn’t be buying a house…
Yeah that sounds cruel and messed up, because it is. I don’t like how expensive real estate is and I wish we could have another 2008 without a bailout. But the point stands. If you hafta pick between eating and paying your mortgage, you made a bad financial decision. Blame whoever you want, I am of the opinion that people still have agency and are responsible for their decisions, as unpopular as that seems to be these days.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#274Earlier quoted context omitted.
> This is a misconception Pretty sure they were joking.
For anything you do, no matter how novel and difficult, someone on HN will tell you it’s trivial and done since the 70s.
Would you rather be doing GB with 70s hardware or TB today?
I would not understimate what folks in 70s had done.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#275I wonder at their scale, why wouldn’t it make sense to store the entries lightly compressed in memory?
Definitely. Even a custom compression/encoding that knows to treat the different fields differently -- just a 4-byte binary IP address for A records, normal LZ-based text compression of the domain name (perhaps using a custom starting dictionary and/or Huffman table), etc.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#276Earlier quoted context omitted.
Every distributed system serves stale data. You can define away ‘stale’ by picking a consistency model, but look inside the consistency machinery and you will see fresher data you aren’t allowed to have yet.
That's like refusing to use a fridge, insisting on letting your produce gradually spoil on the counter because "all harvested produce is in a state of decay anyway".
No, it's using a fridge in the understanding of the fundamental limitations of fridges.
You asked ‘why would I want to use a service that serves stale data’. The answer is you don’t want to. But if you have a distributed system your only choices are about the nature of the possible staleness, since global instantaneous consistency is known to be impossible due to fundamental features of the universe.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#277This reminds me how you can save a bunch of bytes just by making sure your structs are aligned. In go for example: type Wasteful struct { a int16 b int c byte } type Aligned struct { b int a int16 c byte } Will have sizes of 24bytes and 16bytes (on a 64bit system). Same data 8bytes more. If you are storing millions of those objects, then it adds up.
Why this is not done automatically by the compiler? That seems something quite easy to calculate to me.
Sibling comment touched on it, and I guess rust does offer just that, but void casting and doing explicit offset checks for a field is one reason. You can kind of think of it like a tuple in that way and a db engine might use a similar technique.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#278This reminds me how you can save a bunch of bytes just by making sure your structs are aligned. In go for example: type Wasteful struct { a int16 b int c byte } type Aligned struct { b int a int16 c byte } Will have sizes of 24bytes and 16bytes (on a 64bit system). Same data 8bytes more. If you are storing millions of those objects, then it adds up.
Why this is not done automatically by the compiler? That seems something quite easy to calculate to me.
It is not very hard, but it is additional complexity, and it then requires the language to have a way to opt out so you can handle things like FFI or explicit ordering (usually for padding to avoid false sharing and friends).
So most languages opt to follow what their predecessors did: do nothing and task developers with reordering the structure if they want to minimise its size.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#279Earlier quoted context omitted.
Can you ground the discussion by mentioning what you think these cities are? Taking Columbus, OH as the most average of American cities and a 20m isochrone map from city center, there are currently 0 parcels for sale with 3+ ("several") acres under $300k. There are a few within 30m drive, one of which even has a possibly habitable structure. The rest are bare agricultural land you'd need additional investment to actu…
I'm just looking at Kansas City as an example right now. Tons in the $200s btw, and this is in the city less than 20 minutes from the Nelson-Atkins Museum, WW I museum, the river, farmers market, KC Chiefs / Royals / Sporting KC / KC Current teams, parks, schools, newly rebuilt international airport, etc.
I picked the convention center as city center (union station would also be a reasonable choice) and I was only able to find 2 improved lots under $300k. Notably, neither is quite 3+ acres or within 20 minutes of the things you listed, and both are on septic. And this is in a metro where home prices are 36% below national median.
[0] https://www.realtor.com/realestateandhomes-detail/3711-N-67t...
[1] https://www.realtor.com/realestateandhomes-detail/20118-E-Tr...