It can be interesting to know something (or even a lot) about enumerative combinatorics, and certainly there are some specific programming contexts in which that's a hard prerequisite, but it's not a topic that necessarily concerns every programmer.

OTOH I think it would greatly help programmers, especially beginners, to have fewer click baity titles around.

> Expecting each individual person to be their own EPA and research how every single item they consume is produced idiotic and doomed to failure.

That's a false dichotomy. There are many middle grounds between researching every single item you buy and dropping the problem as a whole. You can focus on items which are most likely to bring negative impact, you can draw information from journalistic reports and material produced from dedicated associations. There are many ways to be sensitive to economic externalities of the things you buy without getting insane and without considering the whole problem moot on general phylosophycal principles.

There's a better viewpoint on that, though: ignore moral responsibility, think in terms of agency. Choosing from whom you buy is one of the few ways you (as an ordinary citizen) have to make the world a little steer towards a better form of itself. My own choice alone won't change much (which is correct, otherwise we'd be in an economic dictatorship), but if many people consistently care about that capitalism will work its magic and make wonders happen.

EDIT: That's not meant to be dismissive of it. It looks like a very beautifut book, and I'll probably buy one.

Do not look for the super-core stuff like user32.dll and ntdll.dll. There is already a lot of folks working there and it's hard to make an improvement if that's your first contribution. But there are a plethora of random forgotten libraries in dlls/ which usually nobody cares about until some application depends on those, and they are quite likely to have a good amount of low hanging fruits. Look for the todos in the tests, for example.

Disclosure: I work for CodeWeavers, but I am not involved in the hiring process.

* After each change you have to review the whole MR, either because you have to rebuild the context or because it's not obvious how the new changes interact with the old ones. Hopefully the new review won't take as much as the first one, but still it's linear, and the number of changes request is also likely linear in the MR size, so that's already total quadratic.

* More iterations often mean higher review fatigue, at some point I don't want to rehash the same code over and over again, and I tend to postpone bigger MRs in favor of smaller ones.

* Larger MRs are correlated with the author not having a full grasp of what they are doing, and therefore are unable to segment it properly and organize the code properly. Sometimes there are not many alternatives to a large MR, so that's not a hard rule, but there is certainly a decent correlation.

In my experience (admittedly with a company that is not necessarily statistically meaningful) when I began doing code review that helped with my own MRs getting reviewed (and also contibuted positively to performance reviews). First and foremost because it helped me getting a better understanding of the whole code base, not just the parts that I ended up touching; and then, I suppose, also because it made me more trustworthy towards the code maintainer.

If your system doesn't do overcommitting, then I guess that with some mmap() trickery (using the appropriate flags) you could do more or less the same thing, reserving the virtual address space that you need and then actually backing with memory as you need.

My personal end goal is speculation. Each time a technology is discussed it's pretty automatic for me to think about what are its weaknesses and strengths, and how its behavior can be subverted or the same thing can be used in unintended ways.

No doubt he is very curious, but there might be some selection bias here.

In this specific case it seems particularly necessary. I don't think I will take this manifesto at face value.

You can't measure their position to the millimeter range, but with some interferometry techniques you can measure their movement to the millimiter range, relative to close points. Some variation of https://www.sciencedirect.com/science/article/pii/S092427161... was likely used in that work, I've seen it done for many other structures (and I even tried to setup a pipeline for doing that for commercial customers, but in the end we didn't manage anybody to fund us).

You can probably get better measurements with an onsite survey, but using satellite data has the advantage that with a handful of satellites you can map an entire country once every one or two week, and after throwing some computing power at it you can theoretically monitor all the bridges and houses at once and get early predictors of possible problems.

These case studies give you a hint of what can be done: https://www.sarproz.com/case-studies/ (I'm not and never have been affiliated with that product, just linking some cool pages).