Viewing profile — another-acct

> C, a useless language without effective scopes Mutexes can be handled safely in C. It's "just another flavor" of resource management, which does take quite a bit of discipline. C…

Might want to move foo.add() out of the lock scope (assuming foo is a thread-private resource): value = nil lock { if (data.size() > 0) { value = data.pop() } } if (value) { foo.ad…

I think it's fair to comment not only on the subject, but on the writing itself, too. And it might help Justine improve her writing (and reach a larger audience -- after all, blog …

This is how it should be. IIRC -- apologies, can't find a source --, Ulrich Drepper wrote somewhere about NPTL that its mutexes were not particularly lightweight, but that you shou…

> remove locks from code and replace with some kind of queue or messaging abstraction Shared-nothing message passing reflects the underlying (modern) computer architecture more clo…

Agreed; this is what I've always (silently) thought of those fat binaries. Absolute stroke of genius, no doubt, and also a total abomination (IMO) from a sustainability perspective…

I also meant to comment about the grandstanding in her post. Technical achievement aside, when a person invents something new, the burden is on them to prove that the new thing is …

> or just want to experience and enjoy my excellent (and occasionally eclectic) taste Thanks for the good laugh :) Seriously though, your CV is impressive. I hope you'll land well,…

> For me, GitHub PR review drives me crazy. It's good for exactly one round of exchange. After that nobody can tell what the heck is going on. Matches my experience totally. It dev…

Whenever you force push v2, v3, v4 of your branch called "foobar", you can also push branches called "foobar-v2", "foobar-v3", "foobar-v4" (pointing to identical commit hashes, res…

IMO you are spot on. GitHub's worst sin is that it has mis-educated new generations of developers. My 16yo son uses github every day; I've needed to explain fetch + rebase to him s…

Agreed 100%, and it's hard to believe how many corporate software developers actively resist this concept. Once the code works, many refuse to invest any time into properly restruc…

This is the comment I've been looking for! :) High-five! Some remarks: > - The next version is a reply to the previous cover letter Not necessarily; sometimes the new version is no…

> I agree in general, but running git bisect on individual PR commits is just doing it wrong. There will always be commits that break stuff temporarily. That's unacceptable in my b…

> mail based workflows shine as reviewer is more encouraged to apply the series, compile/run it in their env not to mention: if the reviewer does this for every version of the post…

... Another thing that mailing list-based development gets right ;) Most MUAs should know about a concept called "Drafts". I can have as many draft messages concurrently as I want,…

> GitHub is [...] not very reviewer or team friendly though The problem is that reviewers / maintainers are much scarcer than contributors. Workflows and UIs should optimize for re…

On a mailing list, you used to be able to write up the big picture in the "cover letter" (patch#0). Design-level discussions would generally occur in a subthread of patch#0. Also, …

> GitLab [...] compares different iterations of the force-push "naively", so if your force-push includes for example a rebase onto master because another MR has been merged ahead o…

> have feature branches that get squashed into a single commit (erasing the history of the branch) Terrible. It makes git-blame and git-bisect essentially unusable. If you have a r…

> Because it was under 1000 layers of other bullshit Not only because of that. git-range-diff, while absolutely a killer feature, is a relatively new feature of git as well (a bit …

> all the actual details of using email are, I would estimate, about 1,000x shittier in 2024 than using GitHub in 2008 Disagree about "all". Tracking patches in need of review is b…