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?????
139
Replies
·
0
Boosts
so of course i'm gonna refer to the reference implementation and having it in rust and in c is in fact a cool thing to do because rust does in fact have nice modelling capabilities appropriate for this problem. i'm gonna have to translate my ring buffer into C and while it will be happier there the lack of a trait system will be difficult
c++ with concepts is just incredibly goated because they're like traits but strictly more powerful, and then you still have standard templates for backcompat
fucking blew my goddamn mind when thephd explained their formalization of generics and compile time reflection for rust https://soasis.org/posts/a-mirror-for-rust-a-plan-for-generic-compile-time-introspection-in-rust/ i had not been able to verbalize rust's refusal of the very standard template specialization mechanism in c++, probably because they special-case it for generic const parameters
oh actually i think they don't i think you just might have to support any possible N: usize and then error if it's an N you don't like. but i think compile_error!() doesn't respect if conditionals in const fn without nightly and it somehow only respects the LITERAL GARBAGE AND INVISIBLE TO THE COMPILER cfg attrs
oh wait i forgot they literally said "sorry we can't support openmp that's too many APIs for us to maintain. we will stick with the intel-specific threading library that actively sucks shit for this problem"
https://github.com/BLAKE3-team/BLAKE3/pull/457#issuecomment-4229630358
i was like "literally i want to package this software and the intel library says contact our marketing team for support"
the AMD aocl-crypto library does this very impressive thing where it has an arch/ subdir for machine-specific code and the crypto code has meaningful function names and very clearly maps to simple steps of mathematical operations
like yes obviously all of those qualities should be table stakes for a portable cryptographic library but having official support from the processor vendor is completely unbeatable
and you could argue it's smart because this means people will use your library on your competitor's machines and now they've lost the ability to neg users into hardware upgrades
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?)
