Notices by Marcus Müller (funkylab@mastodon.social)

@alcinnz @simo5 @david_chisnall on soft bits to do decisions based on analog signal observations, and the fact that aes blocks are relatively small and locally decryptable, would make me guess that channel decoders are the power-wise worse problem at the same rate.

@alcinnz @simo5 and @david_chisnall is also seeing the right problem there: the error correcting code decoders are usually pretty energy-hungry per payload bit, even as they are all specific silicon these days, because nobody can do 30 iterations of a giant graph message passing algorithm on frames far beyond 15000 bits in length in software.
I don't know how these decoders compare to an AES accelerator in power per bit, but my guess is that the fact alone that they are working1/2

@alcinnz @simo5 @david_chisnall you'd be right, and none of the high speed interfaces that even get remotely close to 1 Tb/s do it without extensive error correction.
State of the art is that we correct errors, mostly using block codes with blocks as long as the requirements and medium permit.

@Conan_Kudo @lanodan @marcan ah sorry, didn't mean to imply it was a *good* idea, just that if you're designing something to be easy to implement, going sector=page is an easy choice.

@Conan_Kudo @lanodan @marcan somewhat relatedly, I haven't been following things, but did memory folios actually get a lot of traction?

@lanodan @marcan the MMU / mmap() can only map pages between kernel space and userland, so it *does* make a lot of sense

@pid_eins hm. But that basically necessitates solid RPC between an unprivileged client and a privileged system management daemon, which in itself is exactly where we tend to find parsing bugs for decades (like the glibc one triggering this discussion is).
I'd honestly rather see a kind-of-single-syscall-suid mechanism that only works with a sensible verifiable pledge()-equivalent. Like, think of an xattr that contains ebpf code describing that a privileged open can open exactly one file, and...