@nprofile1q... it is also interesting to look at how it changes when you go back from a higher level language to writing C (e.g. some glue code between the high-level language and the system).
In my case (where I write OCaml day-to-day), going back to C makes me realize just how much code is *not for the thing*: there is a lot of code to handle allocation, and manual error handling.
You need much less manual error handling when you have exceptions, or result types in your language (where the compiler tells you if you forgot to handle an error).
And having a GC means you write less code that deals with memory management (not 0, because you still need to think about limiting memory usage).

@nprofile1q... OpenSSH started warning about the lack of PQ, which should help adoption (when will browsers start to warn about this?) https://www.openssh.org/pq.html

Unfortunately this has also been used to justify deploying PQ standalone: https://abyssdomain.expert/@filippo/116358410869265202, which I don't agree with https://discuss.systems/@edwintorok/116360322947930083 for similar reasons as you https://archive.cr.yp.to/2026-02-21/18:04:14/o2UJA4Um1j0ursyVgHbk3ovrFjGuHkwaf7cKQXyPATM/https/mailarchive.ietf.org/arch/msg/tls/2Dfu4x678DEKCzF-fkdvJHJkS-8/.

Although I'm also worried about classical implementation bugs of PQ algorithms, i.e. rediscovering all the side-channel attacks that are largely mitigated for RSA already, or various mathematical corner cases that affect only some implementations.
Although one could also then make the same argument about ECC, I'm not sure whether all common ECC implementations have sufficient protection against side channels.

And given that https://heartbleed.com/ is still unfixed (and thus constant time CPU instructions don't really exist, see latest 2025 attack) would RSA+ECC+PQ be the safest (or maybe RSA+PQ).
Sounds somewhat overkill, although safe ECC approaches like https://artifacts.iacr.org/tches/2023/a4/ do exist.

@nprofile1q... reminds me of Turris's dynamic firewall (https://docs.turris.cz/basics/sentinel/dynfw/) and Razor2 antispam (https://notes.sagredo.eu/en/qmail-notes-185/razor2-pyzor-spamcop-and-dcc-setup-251.html). Would be interesting to see how distributed defense approaches could be integrated with an antibotty-like system. (The 2 examples I mention are still largely static once they get an update, but what if each host got a slightly different update, e.g. to A/B test defenses and evolve a better defense using a model)

@nprofile1q... I still think hybrid is the way to go. PQ crypto algorithms and their implementations are still very new, with undiscovered flaws. If you use hybrid and PQ is broken by a bug or flaw, no problem, you still have the same protection or better than the classical one.
Even when quantum computers exist you'd have to break both the classical one (with a quantum computer) and the PQ one (with an implementation flaw, or mathematical breakthrough).
If you deploy only PQ and a flaw is found you are *worse* than classical, depending on how bad the flaw is you might not be much better from transmitting in plain text.

Of course implementation flaws in a classical+PQ hybrid could be worse off than just classical too (e.g. some C memory bug), but that might be an acceptable risk.

I'm not sure what the best ordering for a hybrid would be, but I guess PQ encryption first, then classical? So you always have to break the classical first (which won't be instant, even with quantum computers).

There is of course a performance cost, but AFAICT encryption isn't really the bottleneck in TLS, from some testing with 'curl' and 'stunnel' they achieve much lower speeds than what 'openssl speed' reports, so increasing encryption time may not affect overall time that much.

@nprofile1q... I didn't know about the Analog Library! It is so much faster and cleaner than the ACM DL, thanks for recommending it.

@nprofile1q... I still think it is a bug though, because I didn't get any error message when sharing the file within the web interface, and it allowed me to generate a link (both of us had emails on the same company domain).
If the org policy is configured such that you cannot share these files within the org either, then it should've given me an error message during the share operation.

@nprofile1q... I think M365 fails at the sharing part though. I got a form to fill out via email, so I uploaded it to office.com, filled it in, and shared it with someone else in the company via the web interface.

They couldn't open it.

I tried exporting as PDF, but security policies prevented it, because it detected sensitive data (it had my home address and phone number).
I could save it to OneDrive, and download it from there, but then I couldn't open it myself on a Mac (I was able to open the original without a problem).

In the end I just downloaded LibreOffice, edited the original document, emailed it back as both document and PDF form, and then they could finally open it.

I don't know what MS has done here, but they seem to have completely broken compatibility with their own format (or maybe they broke the security checks, and sharing of sensitive documents doesn't work anymore, I didn't try to debug why the other person failed to open it). I would've thought that at least the web version (somewhere on SharePoint) would always work. But actually LibreOffice is more compatible than MS's online suite...

@nprofile1q... perhaps a `lint` tool could check the consistency between information in the repository, and information in the VCS. They are both useful for different reasons (e.g. disclosure in the commit itself can help reviewers, and may be required by some projects; whereas the info in the repo is a good way to tell at a glance how AI is used in a project, or in places where VCS is unavailable, like an `opam` release).

@nprofile1q... the Linux kernel requires the use of Assisted-By tags in git commits https://docs.kernel.org/process/coding-assistants.html#attribution. (be careful when parsing, this is used to declare both AI assistance *and* regular analysis tools like `sparse`. AI is distinguished by having an `AGENT_NAME:MODEL_VERSION` format).
Also some AI tools add a Co-authored-by tag. Adding support for parsing these conventions may help in classifying existing code/commits (at least in the 'unknown' -> 'ai-assisted' direction).

It is also useful to list what *cannot* be used as an indicator of AI assistance, e.g. the presence of a `CLAUDE.md` file and similar. I've seen projects that added such a file containing and instructed the AI to refuse to contribute to that repository (and for Claude sometimes including the official refusal magic string).
Although the presence of such a file could still be used to issue a warning, or a hint when trying to update the classification of `unknown` disclosure states.

@nprofile1q... long ago I used to file my taxes in Romania by taking a USB drive to their office (I don't live there anymore, but nowadays you can file them online).
Every single time I got some kind of malware in return (well I used Linux, so an unwanted .exe could only have been malware). So whatever antivirus solution they were using, it was ineffective. Similarly whenever students would ask a professor for a copy of their slides on a USB drive: they'd sometimes get some malware along with it.

It seems like in places like this a very simple anti-malware solution would've been to flag any new executable being copied from or to a removable and writable drive as malware, especially if it is accompanied by autorun.inf. Autorun.inf on a writable removable drive is a very bad idea (not that it is a better idea on a CD-ROM, but it is too late to change that).

@nprofile1q... nginx is going to be hard to beat. But it is interesting that the scalability shape between OCaml and nginx is not that different. Nginx just has the advantage that its single core performance starts from a much higher point.

I'm assuming these are all HTTP/1.1 benchmarks? Unfortunately `wrk` and `wrk2` don't support http/2, but I found this tool that does: https://nghttp2.org/documentation/h2load-howto.html

@nprofile1q... https://github.com/llvm/llvm-project/blob/main/clang/tools/clang-format/git-clang-format would this help? IIUC it only formats what you changed.
If the 2 styles are too different from each other you'll end up with an inconsistent style in the file though.

If you do reformat the whole codebase then a merge driver could help (it reformats all 3 sides of a merge, and is usually able to avoid conflicts most of the time that way) https://github.com/emilio/clang-format-merge.
(Or equivalently if you use `jj` there is a configuration option to autoformat each commit).
You can also define certain commits to be ignored by 'git blame', e.g. the reformatting commits.

I haven't tried this with clang-format, but the equivalent steps with `ocamlformat` work great (and we've done several repo wide reformats on version upgrades).