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
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)
@hipsterelectron for a VCS, a message digest to identify data objects is fundamentally flawed, as cryptographic hash functions are temporary on the scale of hundreds of years, and change is slow, and an incompatibility in the way we identify data objects would make two parts incapable of working together, which is something we don't want out of a collaborative VCS
@SRAZKVT so especially before i understood snapshots i was only able to think about the current state of the filesystem tree and minimizing checksum recomputation upon changes. the other big problem with checksums of directory trees (which is neither about indifferentiability, nor the interoperability goal you describe) is that if a single bit flips in a single file the entire dataset needs to be re-digested from scratch (i'm super disappointed zfs just dgaf about this at all)
