@nprofile1q... did those bots use curl to fetch curl.se? :)

@nprofile1q... I think that when the title, or CWE of a vulnerability and a package name is publicly known it should be assumed that the actual vulnerability is easily rediscoverable.
Maybe at that point the security advisory should already be published (referencing a git commit/branch/PR even if not a full release yet). Delaying the release of the details puts defenders at a disadvantage, with only minimal impact on attackers (which can rediscover those details with other tools).

@nprofile1q... @nprofile1q... @nprofile1q... I found one of those papers which have native HTML output in addition to the PDF (it is from 2019)
https://dl.acm.org/doi/10.1145/3229062
IT has both an HTML and a PDF/eReader button, the HTML one is a lot faster to load.
I don't know why so few papers have HTML enabled, if it was under the author's control then we should see more.

@nprofile1q... does KB mean KiB in this context and M a power of 10?
I was surprised at first why it'd transfer 5.12M when you asked for 5000K, but it works out exactly if assuming a mix of units.
Would be good to be consistent, either always use K and M to mean powers of 2, or powers of 10. But avoid mixing a K that is a power of 2 with an M that is a power of 10....

@nprofile1q... @nprofile1q... @nprofile1q... arXiv has also been experimenting with HTML output for papers. Notice how it is all continuous, and there are no artificial page divisions anymore: https://arxiv.org/html/2402.08954v1
Also see how much faster arXiv's is to load (ok it is not the same paper, so not a 1:1 comparison)

@nprofile1q... I don't really understand the point of the web based pdf reader, since Firefox would use a pdf.js-like reader anyway (and it is way faster to load than ACM's), and Chrome has its built-in PDF viewer too. It might've made sense before 2013 when Firefox didn't have a built-in PDF viewer. And if they do want to embed a web based reader why not embed pdf.js which is a lot faster?

@nprofile1q... why don't they contact Microsoft support to help them figure out which application installed that file and how to update it, or to improve their OS so it can automatically track this information?
I don't have access to a Windows machine anymore, but I would've right clicked on the file to find its version and digital signature, and hopefully that would've told them who built the file.
There are also various scripts to try to find the (un)installer that'd be responsible for a particular file https://github.com/Zero3/windows-installer-file-search, and the uninstallers might also be cached somewhere.
Although there are multiple installer formats, multiple package managers, etc. so it may not work.
(Although maybe standardising on .MSI and Winget could help)

Taking a step back though, if an organisation can't find out why one of their machines has an executable file/DLL and how it got there, then they have a bigger security problem than an unaddressed CVE in libcurl.dll, and they should work on fixing *that* first.

@nprofile1q... nice speedups!

It feels like there are some things missing from the standard library, and it'd be nice if the stdlib was improved so that in future versions you wouldn't have to rely on runtime internals like `caml_ba_update_proxy`.

What do you think could be added to Bytes and Bigarray to make your implementation simpler?

@nprofile1q... nice. One caveat with running benchmarks on the local dev machine: ensure that CPU turbo/boosting is off, and governor is performance. Otherwise you could get one benchmark influencing the next one, or an inefficient implementation (that raises CPU frequency on a core) appearing faster than an efficient one (which doesn't run long enough to raise the frequency).
I got this wrong enough times that I have a script to do it and undo it (unfortunately the API to turn it off is different between Intel and modern AMD CPUs).

@nprofile1q... good point, OCaml is similar, but it doesn't have a similar packaging policy (it creates statically linked binaries, unless you go out of your way to create dynamically loadable plugins).
Maybe now that Rust and Go have vendoring support (at least in Fedora), it could be used to allow something similar for OCaml.

@nprofile1q... nice! Looks like Rust, Go and Haskell have good support for dealing with dependencies: https://docs.freebsd.org/en/books/porters-handbook/special/#using-cargo

Interestingly Fedora says that Go programs *must* vendor their dependencies (which contradicts the usual no vendoring for system packages...) https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_vendored_dependencies

Although it seems like a better way forward would be to add better support for emitting distro packages into the upstream language-specific tooling. That'd be a one-off effort / language ecosystem, rather than having each library/application having to figure out how to do this on its own.
It'd probably require augmenting the upstream language-specific packages with more metadata, although it feels like a https://xkcd.com/927/ problem.

@nprofile1q... @nprofile1q... I'm surprised that `g` would use `long`, instead of a fixed width integer type. If this is part of a compiler pass it would've had to assign known sizes to the types by this point. I don't think the transformation would be valid on an ILP32 or ILP64 system. Or maybe because the compiler only supports one model, it is valid under that one?