how on earth does openssh not only have incredibly fucked versioning but is the only package i've ever seen to mention a "privilege separation" chroot path which actively breaks non-root builds. are you fucking kidding me bruh. "privilege separation chroot" defaulting to /var/empty and it immediately errors if it can't create it????? why are your version strings like that bruh?????
140
Replies
·
0
Boosts
like that was a huge motivation for the development of AES instructions which to my knowledge were difficult to support and had some failures in the initial intel implementation. i actually think AES instructions as a corporate strategy is much more evil than SIMD which followed them, because they're actively useless for 99.999% of code, but crypto scares users who don't understand that math is what makes them safe
and then your cambrian era of portable readable C implementations become largely dead code, which not only makes the users of your crypto library subject to subtle hardware vulns, but actively stifles the development of new fucking crypto
ok. here's a reason why "implement a hash table in C" is a good exercise: it is completely impossible to avoid learning how to design a mathematical hash function in order to satisfy the "simple" public API
i would actually impose an additional constraint i would say no probing upon collision instead return an error
now i'm thinking that's actually a really good idea in general. in particular if we extend the allocation/rehashing to specify a number of buckets and a fixed per-bucket depth along with the size of each value.
not only is that just a * b * c to calculate the required allocation size and similar to index, but you have this collision budget quantity separate from your table size. and that's REALLY interesting
like when you allocate more elements the conventional wisdom is that this reduces collisions as if the discrete bits are being stretched apart. but i also seem to recall that rand() % N is not uniform over [1,N] (i think bc it favors earlier elements?)
the second conventional wisdom which i believe i recall reading specifically online (likely more than once) regarding hash function implementation tips the first thing people would say "a modulus is an example of a hash function"
@hipsterelectron few weeks ago i went "how could i make a CAS collision free" until i realised that a hash function having a fixed size return is only useful to have comparisons be in constant time, but that if you don't need that you can use anything that gives any size
@hipsterelectron compression could be a reasonable hash function, but when in use in a self referencing CAS, the hashes would just get bigger and bigger and bigger as length of chains increase
@SRAZKVT so i think the standard "more space for fewer collisions" could be saved by the same solution for ranged randomness which iirc should work like ((float)rand() / (float)RAND_MAX) * ((float)N)
@SRAZKVT but i am also very curious about two further use cases:
- reusing an allocation for multiple stages in which the data distribution may be different
- constructing a representation of the occupied slots without translation into an index offset
(2) is obviously not going to produce constant-time lookups and i have no idea what it would be useful for but the idea of a fixed collision budget as a probabilistic measure should (i feel) mean we can mix that budget across the space in more than just this regimented way a * b * c
@SRAZKVT for a vcs my big realization was that cryptographic indifferentiability is not only wasted CPU but directly means that checksum comparison gives you only 1 bit of information,
and immediately i realized that progressive forensic reconstruction of modifications which produced the distinct top-level is VERY IMPORTANT for a VCS,
and then i realized it doesn't have to be "forensic", since we could say that is kind of the whole point
@hipsterelectron yea a checksum comparison is only one bit of information, that's the whole point of checksum comparison
@hipsterelectron honestly i still think a state based VCS is probably better for most as it is easier to think about (moving a file is more natural than producing / applying a change) while being easier to implement (necessary for redundancy)
@SRAZKVT i have been pretty flummoxed trying to construct meanings for a state without e.g. branches/tags/remotes, but i think that's a dead end. i think git's push and pull are wrong, but the interface git checkout abcdf23 is great and like you said is natural and we will be able to also implement it naturally.
i also realized today that snapshots of a filesystem are (obviously) exactly what git is used to emulate, and i think that it may be an effective way to summarize to people the conceptual gap that our work is closing
