Yeah, you can look in the contributors' dashboard, they stopped around 2019. As any documentation, its fate is to wither and fall into decay. But hey, he got a book out of it.
That's a pretty narrow view of software too. The nature of building software systems is not always towards being able to mass-produce them. What would be the point of copying and distributing 10K copies of my script that runs migrations for one legacy database in a very specific way?
It's complete nonsense. "The total number of moves in the game is equal to the number of stones initially in the pile, which is 5000."
Similarly on the Martian question "If we transform 1 red and 1 green Martian, we get 4 blue Martians. This changes the parity of red and green Martians from even to odd, and the parity of blue Martians from even to odd." - is complete nonsense too.
"the sum of the digits of a number k modulo 2 is equivalent to k mod 2" - 12?
Basically all "solutions" are regurgitated techniques from math competitions which are used completely incorrectly but with a lot of confidence
So, "it is really mostly a matter of luck", and just do so much work that they decide to fire someone else... sigh. If only there was some way for the workers to negotiate collectively for working terms that avoid mass layoffs whenever the interest rates go the wrong way.
I think the anecdote highlights that there's no incremental way to approach gRPC, it's not a low risk small footprint prototype project that can be introduced slowly and integrated with existing systems and environments. Which, well, it is a bit of a fault of gRPC.
My model was not to demonstrate that utility doesn't go down ever, it was to show that it can do that extremely slowly, which makes the utility argument about why we discourage it societally a bit weak - we're clearly not very good at discouraging any other behaviors resulting in long-term bad outcomes (for society or the planet), and we reward all sorts of risk-taking.
I think the simpler explanation is that gambling is seen as addictive and destructive on an individual level, and there is no need for total utility to explain why that's undesirable
This is a bit of a stretch from what I said - 1% drop after the entire population has gambled through 10x their net worth is not meaningful. I also pointed out other speculative activities which we encourage, presumably because they compensate by growing the economy. Insurance might preserve or increase equality, but it also might extract so much rent that the overall utility is lower. There is simply no cut and dry explanation - for some parameter choices things work the way you say, and for some they don't
Ok, take 100 people, with $100 each, and have one round of $1 coin flips between each 2. A significant number of bets overall, 4950. Each person has wagered 1% of their net worth 99 times, something that we all agree sounds quite scary. And yet there will be no busted people, most will likely be between $80 and $120. Repeat this 10 times, a ridiculous amount of gambling - still most likely no bankruptcies, and the total utility, if we assume log, has barely dropped by 1%.
I simply do not believe that we are making such a subtle societal optimization by frowning upon gambling while encouraging all kinds of other risk taking, like investments and properties.
And the other scenario where insurance just acts as a drain on the overall system seems to indicate that it is not inherently positive for utility either
You haven't demonstrated most of these assertions. For example, if everyone gambled against everyone else every second, then that system has a pretty good chance of staying close to equilibrium for a long time, whereas your model indicates that the total utility would be depleted almost immediately. Whereas if everyone was fully insured for absolutely every risk in their life and immediately received a replacement of the exact same value on any loss, then the overall system would just steadily trend to all the money ending at the insurer, which doesn't seem like increased total utility
Ah, a brilliant idea, design all languages so people who only know C can make small changes to existing Ruby code without getting confused. Definitely don't want to enable different abstractions or models of computation. Are these core principles in codebases you mentioned mostly "how to write stuff using C paradigms"? After all, "the Real Programmer can write FORTRAN in any language"
I'm not gatekeeping proofs here, and I'm glad you got math pizza :) If proofwiki had exhaustively printed all possible arrangements, or the decision tree of constructing them, or if they had even included the code that would do the checking (like, say, https://www.richard-towers.com/2023/03/11/typescripting-the-...), then I would agree it counts. But without even a rough ballpark estimate of possible arrangements to check, asserting "brute force" does not make a proof. If I incorporate understanding of the problem, I can see that at most we need to check 8!, which is reasonable. But if the constraints were not so simple, then we might be dealing with 64-choose-8 cases instead, which is heading into not-reasonable.
They can add the same sentence under every finite fact in their wiki, but then it won't be a proof wiki, it would be a list of numeric facts they checked by brute force and we can either trust them, or check ourselves.
Their "proof" that there are only 12 solutions to 8 Mutually Non-Attacking Queens on Chessboard is just "That there are only these 12 can be proved by brute force." :/
There is extensive research on key finding attacks. Often they only need 30% of the bits. Things can be sped up by exploiting entropy - keys are really random, unlike most of the rest of your memory, so that filters things down, and as you said, an incorrect key produces total garbage on decrypt, which is easy to detect, so you can automate testing and discarding key candidates. Lastly, if you have knowledge of the applications or algorithms involved, you often get some extra data structure around the keys, which makes searching the memory dump trivial.
All that is to say, yes, this is a viable attack vector, even if some or many of the bits are flipped
I think the dunk is funny, and at the same time recognize that glibc is invaluable. At least here the attackers had to do some memory tricks - in other (apparently safer) languages they just get arbitrary code execution directly implemented in the logger!
You can't simultaneously have that key strength is maintained as long as they don't know how many bits are flipped, or where in memory the key was, but also that leaking any number of bits is catastrophic. If your memory dump creates a different distribution on the space of possible keys, it has already compromised the cryptographic security of the key, it's just a question of how much, and the answer here is a lot - even if we had GBs of garbage data, that is still tiny compared to the whole space and can be sifted extremely quickly
The original comment said "One bit flip and it's game over". Which is clear nonsense, I don't have to specify that there's exactly one bit flip, I just need to know that the key is in that general neighborhood and its security is already compromised.
I think this needs its own cognitive term, it's not a survivorship or selection bias, it's just skipping the selection entirely and just focusing on the sample. So here people go "This plane is an outlier, there must be something special about it", as opposed to "We would just be talking about another missing plane instead". Or in the immortal words of Tim Minchin "If I didn't have you, someone else would do"