giomasce

What Every Programmer Should Know About Enumerative Combinatorics -> Nothing.

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.

Yeah, that's the theory, and by any mean we definitely need to pursue that as well. I wish we had the luxury of making it work on its own. But since we do not, we need to pull all the levers we have, not just one.

> 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.

Sure, I am responsible for my own actions, and buying something is an action I (can) make. Therefore I bear responsibility for the side effects of my buying actions. Not the same kind of direct responsibility of those that directly make bad actions, and I don't think I should become insane over evaluating the impact of every single thing I buy, but there's a middle ground between that and ignoring the side effect of anything you buy.

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.

Giving up something you'd otherwise enjoy or find convenient because it would indirectly bring harm to other people feels a very virtuous action to me. I wish more people (including me) had the ability to do that more.

AFAIU it is essentially mass-produced (pun intended?). The master is carefully handwritten, all the others are copies taken with an industrial (if high quality) process.

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

Suppose I want to do this with my laptop, and dump my drive to the cloud (say accessible via SSH) to reinstall another operating system overwriting it. It's likely that the new operating system won't touch most of the blocks in my drive, so when restoring after having passed the boundary I don't want to transfer those unchanged blocks. Is there a good tool to do that easily?

Nice thing! I use it to let my kids play with the educational games I used to play when I was their age (mostly Sammy's Science House).

By my experience, it helps a lot to have a handful of patches in Wine already. Doesn't have to be anything especially great, but showing that you can work with the conformance tests (both write them and fix them), create good commits, go through the patch review process, interact constructively with the maintainers can get you a lot of points and make up for a not necessarily perfect interview test.

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.

You mean Full Self Security?

Agreed. Many smaller MRs are likely to get the same amount of changes accepted in far less time. Some of the factors include:

* 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.

How does that interact with cache? Does accessing the ring buffer using the second set of mapped pages ends up using the same cache line, or is it a fresh request to main memory? If it's the latter, I guess that's has good chances of making your circular buffer slower, depending on how big it is, how does your cache work and how much cache pressure you experience. I don't think I know enough about actual caches to say whether that's probable or not.

That still requires you to plan how you use the virtual address space, though. You can't just add more memory pages on the back of your vector if you've already started using those virtual memory locations for other stuff. So you have to know in advance how much space your vector might end up using, and carefully avoid placing anything else there. If you're willing to come up with such an estimate, and if your OS is happy to overcommit memory (and I think Linux is, by default at least), then you can just malloc() all that memory in the first place. With overcommitting no physical page will be used to back your virtual memory block until you really use it.

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.

Whose end goal? The tenant's goal might be, as you say, to convince the landlord that the device is unreliable, and cheat on the rent agreement. If you want to cheat, as I guess some people do (otherwise there wouldn't be need for a monitor), asking if it's ok to host a party isn't a good solution.

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.

The nice thing of intrusive sensors that sense things that are not sensed by your usual senses, like this, is that it's easy to saturate them while faking innocence. I.e., set up your laptop so that it does many scans and/or associations to the local WiFi, and then some light internet activity (the usual suspects: WhatsApp, Facebook, etc). The detector triggers, the landlord shows up to check what's going on, you show it's just you and your partner. Do that a few times until the landlord is convinced that the sensor is malfunctioning; unless they are IT technicals themselves, which I guess won't happen often, they will have a hard time understanding what's really going on, even more to prove it.