ergl
Yeah, the people who disagree with you are never worth listening to. (/s)
You can also let an overdraft occur. Now the user ows the bank some money and you can charge them interest for their debt.
You tell me:
> Scroll to follow one closed strait into fuel pumps, harvests, bond markets and my own country’s winter heating
Or:
> France: a run on the pumps. [...] drivers fleeing record prices elsewhere emptied its tanks faster than trucks could refill them. [...] A price cap meant as a cushion, in a system with no slack, turned a price shock into empty pumps.
A cursory check on Pangram returns 100% AI written just from the first 4 paragraphs.
Incredible how anti-intellectualism keeps taking over the software engineering profession.
Is your objection to the word “train” in headline? Otherwise, you’re just restating the headline while calling it clickbait (which, btw, it’s not, perhaps you meant to say it is misleading, which is a different thing.)
I, too, have infinite contempt for my fellow working class members.
The paper argues that pretending that the so-called thinking traces represent real reasoning can lead users into trusting wrong answers, if the thinking traces appear convincing enough. Researchers might inspect these traces to try to determine the “intent” of a model, as well.
For an example of the latter, when OpenAI spoke about the hacking of HuggingFace at Black Hat, they repeatedly showed the thinking traces of their model as “proof” of what the model was “thinking” as it performed the attack, calling out “surprise” moments, etc.
Now, it’s possible that the employees presenting didn’t truly believe that the thinking traces would give them useful clues, and presented them only for a “wow” factor, but I wouldn’t discount the possibility that even the people working at frontier companies can fall for this tendency to anthropomorphize LLMs.
Good one!
You probably have a great deal of understanding and knowledge about Git, and this book might be a good resource.
I'm not asking you to do anything differently, and yet I think it's important to realize that people have a deep aversion to text that appears to be LLM generated.
By "shame", I meant that just from a skim of the contents of this book, it can be hard to distinguish it from any other LLM generated text by any other author who has no idea what they're talking about.
That makes people (like me) inclined to discount what it has to say, potentially losing out on good technical content.
Personally I have an extremely hard time reading text like this and it makes me lose trust in the author. Publishing potentially useful Git knowledge this way is a shame.
From chapter 1:
> When Git slows down, engineers adapt in bad ways. They stop asking questions the history could answer. They batch work to avoid sync cost. They keep messy branches alive longer, postpone cleanup, and treat the repository like something slightly dangerous.
From https://gitperf.com/epilogue.html
> Once machines start producing code at machine cadence, the model from this book does not break. What changes is the pace: more branches, more commits, more automation, and more surrounding metadata. The traffic gets louder, and the features that keep Git legible under pressure move from "nice to have" to "essential."
> These stop looking like side optimizations. They are what keep machine-scale Git traffic usable.
The online world feels much less useful now and I've been trying to read more physical books and to generally spend less time online (unfortunately one can't escape slop, as I've already seen clearly generated illustrations and photographs in billboards and subway adverts).
"Once the rockets are up, who cares where they come down? That's not my department"
> Full disclosure: iFixit has an ongoing business relationship with Lenovo, and we are hopelessly biased in favor of repairable products.