At some point I accidentally changed the default to 24.04 when refactoring things. This means it won't work for some older Debian-based systems like bookworm, primarily for x86, since ARM was correctly using an override. This change just reverts the default back.
A looooong time ago, we had to manually hijack stdio for FreeBSD to suppress a bogus stderr warning (see
#798). I filed an upstream report at GuillaumeGomez/sysinfo#875, but the real issue was actually with FreeBSD itself. From the upstream upstream bug report at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228432, it looks like this has been fixed since 2022 for FreeBSD 13, so I think it's safe to remove this hack at this point on our end, especially given that I don't build binaries for older than FreeBSD 13 anymore (oldest is 15 now).
This PR allows us to entirely remove the filedescriptor crate for FreeBSD since we no longer use it entirely.
I made the assumption that the max length of the comm field is 16 bytes. This is wrong though - it's now 64.
Note we may want to change it in the future to work regardless of potential length.
Bumps the netbsd-vm action to the SHA equivalent of 1.4.2.
Would like to get rid of this but cross doesn't work for tests for BSDs :/
Hopefully I can figure it out at some point.
Because of the way I was initializing things, this caused it to report a huge spike at the start since it was doing a subtraction against 0. This fixes it by just using a hashmap (which also fixed another FIXME) and initializing the prev comparison structure on first view + skipping the first instance.
The bug would cause something like `(sd-pam)` to be missing, because what would happen is this:
1. We have something like `"123 ((sd-pam)) blah blah blah"`
2. We parse `start_paren` to be index 5.
3. We parse `end_paren` to be index 13.
4. Our `comm` is `"(sd-pam"`, and the rest of our string is `") blah blah blah"`... which is problematic, as then the rest of the parsing will be incorrect, and the entry gets rejected!
Adding this as I've been getting some AI interaction lately - while I'm fine with it, I think now is a good time to add some guidelines at a repo level.
Deals with a possible issue with kitty and its `cursor_trail` functionality, where it supposedly does a bit of extra calculation work when the cursor's location after drawing is too far from the previous location when kitty is checking whether it should recalculate things for the trail, even if the cursor is hidden (at least this is my guess by looking around in https://github.com/kovidgoyal/kitty/blob/c1d507dbe8cd12830d8b97b0d350d9dc2e4d383f/kitty/cursor_trail.c). The fix is (apparently) to just park the cursor at the origin after drawing each time, and this seemingly helps as a workaround.
If this is right (and it very well could be wrong, I'm making a guess here), IMO the actual fix is that kitty should _probably_ skip cursor trail calculation work if the cursor is hidden I guess?
Clement Tsang