I don't see why that would make any difference? The generated C code is just a build artifact in this case, similar to IRs often used by compilers internally. You don't think about e.g. gcc IR when you optimize hotspots in code written in C, though - you just look at the C source and the generated asm code. If you have, say, Zig transpiling to C (which it can do with `-ofmt=c`), you'd similarly look at the Zig source and the generated asm code.
I know of at least one instance in which an employee at a $BigTechCompany was put on a PIP, successfully completed the PIP, and was fired the following week anyway. Box-checking exercise indeed.
The point of a PIP is to reduce legal liability for the company. It shows that someone was fired for not meeting the requirements of their role, and not for race/gender/sexuality/whistleblowing/etc. When you get sued later, I believe the idea is the company can point to the PIP and say "we documented the real reasons for the firing and gave the employee the chance to address them".
If someone successfully completed a PIP and gets fired, the company has effectively put in writing that the employee was fired for other reasons. I wonder if that would look worse in a lawsuit than not having a PIP at all.
If your wheel is turned because you are in a curve, your “right turn” button will be on top or maybe even on the left of the wheel, depending on how sharp the curve is. This can be disorienting and cause you to look away from the road and at your wheel to figure out where it is. The turn signal stalk is always in the same place regardless of your wheel turn angle because it attaches to the steering wheel column rather than to the wheel itself.
Just confirmed that my brain is much worse at producing randomness than python's random module. The site predicted my own "random" key strokes with ~67% accuracy. It was able to predict the output of a trivial python program that chose randomly between 'f' and 'd' with only 53% accuracy, and that probably would have converged to 50% with a larger sample.
I may be wrong, but I thought it’s that you can’t have any fields with non trivial destructors, because the union wouldn’t know which destructor to call. So POD types / raw pointers / arrays of the above / structs of the above are allowed, and that’s pretty much it.
You would probably use std::variant in C++ if you want tagged unions.
So you could have a struct or class with one std::variant field and some methods which can match on the type of the variant. But it would be kind of clunky.
I wrote an unsafe library at a FAANG and used similar naming conventions.
The init function was named along the lines of “MyClassName_UNSAFE::initUnsafeIUnderstandTheRisks()”
And the library itself was called something like “library-name-unsafe-my-team-name-must-approve-diff”
So anyone trying to use it would have to add a library with that name to their list of dependencies and would come to us asking for a code review, and more than half the time we would redirect them to a safer alternative (valid use cases for the unsafe library were few and far between).
Disclaimer: I’m one of the authors of the paper/blog post/code.
If you want to use signatures over the hash as proof of data set integrity, you need two things. 1) you need to make sure that hash({a}) + hash({b}) == hash({a, b}). 2) ensure that hash() is collision resistant - in other words, it needs to be computationally infeasible to find hash(S) == hash(T), S != T for any sets S and T. We prove that LtHash with our choice of parameters has this property in the paper (which is linked from the blog post).
My reading of the post is that the Hash({a, b}) is infact computed as Hash'(a) + Hash'(b) given that a and b are "rows". And thus my question is why Hash' has to have any special properties.
I can think of hash functions that are homomorphic, but are not secure. A simple example is something like “sha256 each element separately and XOR all the resulting hashes together.” This would not be collusion resistant.
We offer a proof that LtHash with our choice of parameters provides over 200 bits of security. You would have to read the paper for the details.
I can see how you might lose collision resistance with a normal 256-bit hash function, but it's not clear why a "stretched" hash with 2048 bytes of output wouldn't work.
E: Ah, there it is, in the paper:
> However, Wagner [Wag02] later showed an attack on the generalized birthday problem which could be used to find collisions
> for AdHash on an n-bit modulus in time O(2^(2√n)), and that the AdHash modulus needs to be greater
> than 1600 bits long to provide 80-bit security. Lyubashevsky [Lyu05] and Shallue [Sha08] showed
> how to solve the Random Modular Subset Sum problem (essentially equivalent to finding collisions
> in AdHash) in time O(2^(n^ε)) for any ε < 1, which indicates that AdHash requires several more orders
> of magnitude larger of a modulus just to provide 80-bit security.
Assuming a trusted system, could you go into more detail on the qualities or guarantees a Merkle tree using XOR would or would not give you and partial mitigations for any of these disadvantages? i.e. How does the entropy of a leaf node's 256-bit signature disperse into the tree up to the root? How does the birthday paradox come into play with regards to collisions at the root of the tree?
For synchronization purposes in a trusted system, a Merkle tree based on XOR seems elegant and efficient, but I can't seem to find accessible papers on this.
Just so I have this clear: is the issue the simple solution above doesn't work (at all) with multisets, and the birthday problem combined with potentially billions of rows means even sha256 will have a significant chance generating a collision?
Unless you are doing embedded programming ...