nuxi7
Joined 16 years ago
Joined 16 years ago
https://www.cia.gov/library/readingroom/document/cia-rdp85-0...
https://github.com/nuxi/acme-tiny
For now I've just done enough to get a cert for a mail server.
I love it!
https://sourceware.org/bugzilla/show_bug.cgi?id=6527
Basically for many years now glibc has been knowingly doing the wrong thing just to keep malloc_set_state/malloc_get_state working. Which as far as anyone knows, is used only by emacs. Keeping this interface alive for the sole benefit of an emacs optimization when it is blocking the fixes for fairly serious bugs is a pretty big bar to meet for justification.
In the end this is largely a non-issue as an Emacs developer noted that their configure script probes for the special glibc malloc API and if it doesn't exist then emacs will use its own malloc implementation. The conclusion is that once the glibc devs get their changes up, everyone can meet up again to make sure existing emacs binaries still run and that the API detection in the emacs configure script works right.
So props to Paul Eggert for being the only sane man in the room and pointing out that the drama was all for nothing.
This is a fact often forgotten when projects switch to github and just start using the automated release tarballs github will make from the repo.
I would call this a bug fix since someone has found what is probably an unintended behavior in the cubic algorithm. The cubic algorithm itself though would be a feature improving on the original tcp algorithm (nagle, if I remember right)