bagxrvxpepzn

Making neutral statements in concordance with reality is the nicest thing you can do for a reader.

> One convenient fiction that many wealthy people (in the US) tell themselves, is that poor people are "lazy"; and that's why they're poor.

If they aren't physically lazy, they're unambitious or refuse to attempt nominally mentally difficult things (like math) and that is mental laziness. Poverty isn't random.

In the bay area this trend of nounifying verbs is common amongst VCs and C-level startup execs. I'm not sure if it's arisen due to peacocking or a higher incidence of ESL in those communities.

In this context, I would call it pithy sure. It's concise and direct. He's not explaining further.

He clearly isn't calling the other categories he listed (the " Retired, Unemployed, Unemployable") useful idiots, that's why he listed "useful idiots" separately. I don't know to whom he is referring as useful idiots but I don't think it's immoral in itself to use the term "useful idiot."

> his suggestion that the unemployed and retried shouldn't have a voice in their community.

I don't see him making that suggestion. It's pithy so it's hard to really pin down a meaning to the tweet but I think he's saying that these town sessions aren't a meaningful expression of democracy because only a specific section of society is in attendance and one that may not understand key issues relevant to working or young people.

First let me just say that while it's possible to interpret my original comment as uniquely applying to LMDB (or databases with similar page cache designs), in practice it applies to all general purpose databases including PostgreSQL and SQLite. This is because all general purpose databases will eventually fall short when it comes to tweaking behavior to meet application specific requirements, customizations notwithstanding. So to the extent that one should not use LMDB for anything that matters, one should also not use PostgreSQL or SQLite for anything that matters. If that corollary appears false in your frame of reference, then my statement about LMDB should also be false.

For high-stakes applications, you will have to maintain your own database code (either original or derived from an existing database) and that database code will need its own page caching layer (or a patched kernel), a generic page caching system (whether in-kernel with mmap or out of kernel) will not do. I acknowledge most applications don't operate in this regime.

> The best you will ever do, even with full application knowledge and complete control of the machine, is an LRU cache replacement algorithm.

This is not true. Applications often have specific high-priority data which should always exist in memory. That may be a moot point because you can do mlock() with mmap(). If we focus only on general-purpose caching, then even in that case there are many alternatives to LRU. SIEVE and ARC are two notable alternatives that perform significantly better for certain data. An application developer should be able to experiment with different general purpose caching strategies for different types of data, mmap() does not afford this.

Thank you Mr. Chu for your contributions to the technology commons and humanity in general.