This is the right way to deliver software. Produce working product first, validate the idea, stabilize the business, start generating profit, and then you can start optimizing your costs. In fact optimization is by far the easiest part of the process because there are many system programming experts on this HN thread who consider these optimizations to be trivial.
Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
121–130 of 306 posts
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#122Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#123This is the right way to deliver software. Produce working product first, validate the idea, stabilize the business, start generating profit, and then you can start optimizing your costs. In fact optimization is by far the easiest part of the process because there are many system programming experts on this HN thread who consider these optimizations to be trivial.
not everybody is so lucky to be able to go in that order? The first part requires upfront capital/investment?
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#124This is the right way to deliver software. Produce working product first, validate the idea, stabilize the business, start generating profit, and then you can start optimizing your costs. In fact optimization is by far the easiest part of the process because there are many system programming experts on this HN thread who consider these optimizations to be trivial.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#125Frankly weird that they were resorting to high level containers for this in the first place. Also, this line struck me as odd > Big Pineapple uses jemalloc, an allocator designed for multithreaded, allocation-heavy workloads. jemalloc multithreaded performance is actually poor(ish) compared to other modern allocators, which makes it a weird choice. But even weirder is why they're even using an allocator in the first…
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#126Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#127Earlier quoted context omitted.
I wonder why Cloudflare didn’t think of this
This is Broadcom's business model
I still look after a few VMware estates and a lot of Proxmox ones (that used to run VMware).
Hilariously, VMware is described as "enterprise class", which I can only conclude means MVP and a bit wanky.
Today I repaired a Proxmox HA + Ceph node using boring old normal Linux skills and as it turns out I have 30 years of those. Part way through a remote v8 to 9 upgrade I think I lost comms due to using OpenvSwitch for networking and despite using tmux for the upgrade session. Anyway, the Proxmox ISO was useless for rescue but the classic systemrescuecd worked nicely and I could run dpkg in a chroot.
VMware "used" Linux and never really gave back. I don't miss fixing vCentres and all the other nonsense that "Enterprise" wankery has foisted on me over the years.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#128Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#129Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#130With my own MaraDNS, I aggressively optimized the memory usage of blacklist entries by having a single really big malloc() to allocate the memory for the entries, then traversing that memory block for potentially blacklisted entries. When I was using one malloc() per entry, a large blacklist took up 237 megabytes of memory. The same blacklist, once optimized to be loaded with a single malloc() call, only took up 9.5…