

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


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.


yeah, I think the whole “water” argument really dilutes the case against data centers.
On a serious note, the argument works for areas that already struggle to supply enough water for consumers. Otherwise, we should be focusing more on the power stress to the grid, and the domino effect on supply chain of hardware cost increases that it’s happening across many industries. It started with GPUs, now it’s CPU, storage, networking equipment, and other components.
If these prices are too high for a couple of years, we’ll start seeing generalized price increases as companies need to pass along the costs to consumers.


It’s not, I read the code. It’s not merely asking the LLM for recommendations, it’s using embeddings to compute scores based on similarities.
It’s a lot closer to a more traditional natural language processing than to how my dad would use GPT to discuss philosophy.
Ok, I’m not suggesting replacing humans with AI and I despise companies trying to do this unsustainable practice.
With that out of the way, I’ll restate that LLMs follow some rules more reliably than humans today. It’s also easier to give feedback when you don’t have to worry about coming across as a pedantic prick for pointing out the smaller things.
On your point that LLMs are not improving; well, agents and tooling are definitely improving. 6 months ago I would need to babysit an agent to implement a moderately complex feature that touches a handful of files. Nowadays, not as much. It might get some things wrong, but usually because it lacks context rather than ability. They can write tests, run them, and iterate until it passes, then I can just look at the diff to make sure the tests and solution makes sense. Again, something that would fail to yield decent results just in the last year.


No, it also doesn’t do that. It gets embeddings from an LLM and uses that to rank candidates.


that’s how it looks when you walk/run in circles in a vessel that’s moving


no one is saying everyone has to ask an LLM for movie recommendations


wow, this dystopic update is reality not disappointing
yet another reason to not use Google


chill, this is extracting text embeddings from a local model, not generating feature-length films
that’s like saying “no jet use is benign” meant for comparing a private jet to a jet-ski
the generative aspect is not even used here


There’s no training, the LLM embeddings are used to compare the plots via a cosine similarity, then a simple weighted score with other data sources is used to rank the candidates. There’s no training, evaluation, or ground-truth, it’s just a simple tool to start using.


that’s pretty cool, this is just the wrong crowd, don’t worry about the downvotes


tmpfs is a memory filesystem, they all do
https://man7.org/linux/man-pages/man5/tmpfs.5.html
one-liner to get the total used size
/usr/bin/df --type=tmpfs | awk 'NR>1 {sum+=$3} END {print "tmpfs used (MiB): " sum / 1024}'


for a more readable output
df -ht tmpfs
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.