pbrowne011
Joined 5 years ago
Karma
496
Submissions
94
Member since
Aug 3
Recent submissions
Comment · 20 days ago
For a broader look on scaling other parts of software development outside of source control, Adam Bender's talk from earlier this year ("Software engineering at the tipping point") has some good ideas: https://youtu.be/2n41YjR5QfU
Comment · 6 months ago
Feels like this would be a good candidate for Pike's programming rules (https://www.cs.unc.edu/~stotts/COMP590-059-f24/robsrules.htm...):
"Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms the rest."
Comment · 6 months ago
Very cool! TIL about Ghostscript: https://ghostscript.com/about/index.html
Awesome to see someone continuing in the tradition of free/libre OSS: https://linuxclass.heinz.cmu.edu/doc/Open-Source-books/Free-...
Comment · 6 months ago
Interesting to see how their CLI compares with GitLab's CLI interface for stacked diffs (the only support they offer at the moment): https://docs.gitlab.com/user/project/merge_requests/stacked_.... Most things are the same (up/down/top/bottom vs. next/prev/first/last, init vs. create), but both feel quite limiting. I've heard of other systems such as Gerrit that offer better native support, but have not tried out any for myself.
Comment · 1 year ago
If you'd like to read something that is less detailed, I4R (Institute for Replication) posted threads on X (formerly known as Twitter) and Bluesky about their investigation into this paper.
X (Twitter): https://x.com/I4Replication/status/1893842119594258913
Bluesky: https://bsky.app/profile/i4replication.bsky.social/post/3liv...
Comment · 1 year ago
It seems crazy to me that vulnerabilities like this still exist today. I understand that not everything will be written in Rust, but this could have been caught by basic testing and/or fuzzing, as Nick (the person who found the vulnerability) points out: https://www.openwall.com/lists/musl/2025/02/14/1. So far, this earned an 8.1 from MITRE: https://nvd.nist.gov/vuln/detail/CVE-2025-26519, although I'm not sure if that's just a function of it being a bug in a library that so many applications use.
This also goes to show how every line matters. The one line change was from
if (c >= 93 || c>=0xc6-0x81 && d>0x52)
if (c > 0xc6-0x81 || c==0xc6-0x81 && d>0x52)
To explain the bug, EUC_KR is Extended Unicode - Korean. After ASCII characters (0-127), each character is multiple bytes. The logic adjusts to look up from a base-0 index, then checks that both bytes (variables c and d) are in the normalized range. If not, the code adjusts the characters and checks the bounds again. This second check is what contained the bug.
0xc6 - 0x81 is the upper bound of this check (69), not 93. The irony is that the second part of the check gets this correct. I wonder what a `git blame` would reveal about this particular line.
Comment · 1 year ago
Fun to see someone decide to just write a faster JSON parser because they believed it was possible. They mentioned last year that libjansson had some intermediate layer with Emacs, which led to too many memory allocations: https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00...
Also, the developer who wrote the parser (Géza Herman) was able to pass all of the tests with strange edge cases from https://seriot.ch/projects/parsing_json.html very quickly: https://lists.gnu.org/archive/html/emacs-devel/2024-03/msg00...
Comment · 1 year ago
True, I was trying to find the variable storage requirements in the UEFI specification but couldn't (is it Section 3? 8?), so I resorted to linking to the struct definition in the EFI shell package that the author used.