ctrl is more useful

You should probably turn off Dependabot

Nonsense, most of these supply chain attacks are detected and have their problematic versions pulled within a few hours. Just set a cooldown period for dependabot.

nope, opencode is better and actually open source

aaand they both had their source code removed

“Make no mistakes” wasn’t enough?? 😮

actual open source option, fwiw

https://github.com/anomalyco/opencode

someone went through the leak and opened a proper pull request to open source it

https://github.com/anthropics/claude-code/pull/41518

the file tree looks less messy than in that screenshot, but damn, I didn’t think it would be 514k lines

1. How many grep-like ops per file?
2. Is it interactive or run by another process?
3. Do you know which files ahead of time?
4. Do you have any control over that file creation?
5. Is the JSONL append only? Is the grep running while the file is modified?
6. How large is very large? 100s of MB? Few GB? 100s of GB? Whether or not it fits in memory could change the approach.
7. You’re using files, plural, would parallelizing at the file level (e.g. one thread per file) be enough?
8. How many files and how often is that executed?

Share Tech Mono

https://www.codingfont.com/ShareTechMono

I thought it was a given that, if it’s a phone app, you’re likely to want to carry it with you, not leave it on a desk with your computer.

that would still require the OS or user to spoof a location to actually prevent tracking. I hope they’d do that, but I wouldn’t expect them to.

HEL

I’ve never worked on a codebase where using ORMs wasn’t better than rolling your own queries. What are people writing that they actually need the marginal performance gains? And even if that’s worth it, why not just use raw queries in your critical paths?

Every time I have to write or modify raw SQL it feels like I’m throwing away all my static checking features and increasing the chance of bugs, because I have no idea of the query matches my schema or if it’ll blow up at runtime.

you can’t compare it to the islands, because the GPS trace is in an area within that green circle, with a different scale. You can only look at the 300m scale in the bottom right, which looks in the ballpark of an aircraft carrier to me

The way I see it, for any code review there are going to be different levels of recommendation regarding the comments. When I review, I try to make it clear what’s optional (/ nitpick) and what I’d really like to see fixed before I can approve it.

So even making some assumptions, I can’t choose between 4 and 5 because optional and “less optional” changes are often in a same PR.

The only one I haven’t done much of is #3. That one looks better if one has questions about code that was already reviewed, merged, and it’s likely in production.

As with a lot of things in life, it depends.

I use 1-5 depending on the repo, who made the change, what the change is about, and how involved I am in the project.

Though the “time-frame” idea of #4 is usually replaced by conversations if it’s a coworker, as it’s more effective.

Q: about #3, do you mean on code that is already merged / committed to the default branch?

so… some really basic shit that should have been expected in a pre-2010 update + AI

Well done, guys. I guess you gotta start somewhere.

you’re the one comparing it to Linux

I don’t think you can have both

You don’t need that assumption. Your assumption can just be “the person and vessel (or a point in the vessel, like its center of mass) don’t diverge significantly over time”.

Then, if you treat velocity as a vector and compute the person’s average velocity vector over time, you’ll have a pretty close estimation to the vessel’s velocity vector.

After all, if those two average vectors (vessel’s and person’s) were to differ much, they would end up in different locations.

The average basically zeroes the vector for each lap the person does, so the remainder must be the vessel’s.