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.

Uncommonly used system calls give user-space programmers the sensation of learning something.

> Why would you want the kernel to do these things for you? It'll do a worse job: it has less information than you do and has to use blunt heuristics that work sort-of-good-enough for the whole world, not just your program.

Yes, you're opting into non-determinism you don't control. When resources get constrained and everything can't be in memory and someone asks you why the database sucks, all you'll be able to do is shrug. Anyone who builds critical systems would never rely on the kernel making decisions like this. Don't use LMDB for anything that matters.

This is true but it's misleading. The reality is that modern out-of-order superscalar CPUs are so good at branch prediction that it's nearly always better to branch in a tight loop (to allow more ILP) than introduce a data-dependency in a tight loop (which limits ILP). Cf. https://mazzo.li/posts/value-speculation.html, https://yarchive.net/comp/linux/cmov.html

Branchless code should generally be avoided because modern CPUs are not designed to optimize that use case. There are exceptions of course, but those are exceptions.

My use of "judgmental" was to communicate that my intention was not to pass judgment on his worth as a person or his worthiness of respect as a person or professional in me providing honest feedback about his behavior.

> I don't believe there is a universal list of things that is OK to care deeply enough to cry about.

It's not about prescribing when it's OK to cry or trivializing what he's sad about, it's about deviations from average behavior. The vast majority of emotionally well-adjusted men usually only cry at the death of a loved one or during a divorce or serious break-up. Here's data on that: https://yougov.com/en-us/articles/51961-the-who-what-where-w... To find yourself crying in a situation different from those situations should raise a red flag. Yes it may be the case that it's not a sign of anything serious but given the rarity of the situation, it's reasonable to suspect there may be something else at play, e.g. low testosterone.

I don't see a reason to counter anything I said. I offered neutral information that may help the OP. If the OP's testosterone levels are indeed low due to a serious medical condition, then you've just done them a major disservice. Even if you're of the opinion that it's normal, it's reasonable for someone else to assess that feeling sadness to the degree of provoking tears in response to deciding not to use productivity software is a cause for concern.

On what are you basing that?

> it's 100% fine (and healthy) to care about things in life.

Yes it is and I didn't claim it wasn't, so this is a strawman.

There's nothing personally indicting about having low testosterone. It's relatively common and it's potentially a serious medical condition. There is no reason to take offense from this.

Failing to acknowledge the structural flaws of Liberalism just opens up an opportunity for ideological revolution. If the adherents of Liberalism prefer moderation, they better had start acknowledging how it's failing people. "Just Liberal harder" won't work forever.

To save Liberalism, rather, we must first accept Liberalism is wrong. Then we must discuss what was wrong about it. Then fix those things to invent whatever ruling ideology comes next.

Here's a hint and it comes from his own writing. The "critical theory" and "identity politics" coming from within are directly a result of the nihilism and pathological individualism, respectively, that is born out of Liberalism. The US is degenerating because it lacks a prescribed morality (an unequivocal definition of what is right and wrong) and a prescribed universal identity, respectively. Things that Liberalism eschews, and things that people will find or invent elsewhere despite how many times you bemoan the death of enlightenment ideals.

Thank you for charitably responding to the substance of my comment and especially not whatever tone you may have perceived. I appreciate you.

The key word I used is "substantial." The usability improvements over Git are marginal and if they ever become non-marginal, they can relatively easily be added to git. This is what my comment is getting at. The only essential difference between Git and JJ is that they are different fiefdoms. There is no substantial technological difference. It's just two different social factions with marginally different opinions about how to type CLI commands.

That's literally his job?

My criticism is that that's a detail that is being obscured and instead other explanations for leaving are being presented (cynically IMO).