Regarding the anti-nutrient thing, I recall reading that letting the beans (or grains) sprout will also break some of those down. I tried it once with some chickpeas and it does give them an interesting flavor, although it's a bit of a hassle and I haven't bothered to do it again.
How about this... some of these will probably be sold to unwitting gamers, right? So push a driver update with the hot serial numbers and have it pop up a window saying "tell us who sold you this GPU and not only will we let you keep the card, but we'll even throw in a free year of GeForce now" (EVGA can foot the bill). Then track down the thieves, done.
A Wayland compositor is responsible for quite a bit more than an X11 window manager. Compositing, as you mentioned, but also display modesetting, input handling, clipboard management, and so on. Although, of course, one can use a library like wlroots or libweston to handle most of that stuff if you just want to focus on the desktop experience.
The article didn't say you should always use subshells for functions, no exceptions. Just that most of the time it probably makes more sense to do so. And subshell functions can still have side effects like interacting with the filesystem, they just can't modify the parent shell's environment.
With the proprietary driver, the GPU is controlled by their closed-source kernel module, so Mesa's GBM code wouldn't know how to talk to it. However, as of the latest version, NVIDIA is shipping a GBM back-end library that Mesa can load which is able to talk to their module.
I suspect trying to maintain a remote-X11-based workflow is going to become increasingly annoying as more applications prioritize the Wayland / Xwayland use-case like Firefox has done here.
Would it not just be a matter of time until the orbs are reverse-engineered and you can sign arbitrary input? Especially if this currency were to actually gain significant popularity.
I remember reading that when they were first brought to Europe via the Columbian exchange people were reluctant to eat them fearing they were also poisonous. Now it's hard to imagine, e.g. Italian cuisine without tomatoes.
Do you worry you might get in trouble if a technician sees some strange device attached to your meter? I know you're not actually doing anything wrong, but I feel like it could be awkward trying to explain that to some angry representative of the utility company.
It should still be possible to solve the problem manually, though. Inevitably someone will run into some special case where clicking the button doesn't work and more control is needed.
I think it's just that the cuts suited to slow-cooking techniques tend to also be the cheaper cuts. Maybe that's because they are generally from larger muscles and therefore in comparatively greater supply.
The underlying model of git is not too hard to understand, and is actually pretty elegant. There are a number of good explanations online, including the one you linked.
The git tool itself, though, often operates at a much higher level of abstraction. I think that's more where the reputation of being hard to learn comes from. For instance, you'd probably need to write a paragraph or two to explain what "git checkout <branch>" does in terms of the actual object store. Add to that that the CLI is poorly designed - many commands have misleading names, a given command will do completely different things depending on the flags, there's a lot of implicit / counterintuitive behavior, and so on. See https://stevelosh.com/blog/2013/04/git-koans/ for some funny examples.
The advantage of that, though, is that you can still benefit from the many "how do I do X in bash" posts on various fora, Stack Exchange, etc. With the more esoteric shells you have a much smaller community.