EB66
I've assumed the same as well.
I also assume that many of the companies developing these models engage in benchmaxxing.
At my company we've developed our own internal benchmarks for evaluating LLM models as they become available. The benchmarks are tailored to our particular use cases but the utility and knowledge our benchmarks assess is still fairly universally applicable. I see wide differences between what our internal benchmarks report and what the major benchmarks do.
There was a whole lot of fanfare about how amazing GLM 5.2 was when it was released, but it was pure rubbish on our internal benchmark -- far behind OpenAI, Anthropic, Gemini, DeepSeek, etc. I don't know how to reconcile the fact that GLM 5.2 performed very well on some of the major public benchmarks, but consistently performs so poorly on ours. OpenAI models tend to dominate our internal benchmarks.
I always thought it was a little odd that gpt-5-mini was the leader for so long when more popular benchmarks placed gpt-5-mini further down the roster, but it seems you had the same result too.
Regarding the acceptance rates, it's actually the opposite. GT OMSCS has a very high acceptance rate (~80%) and UIUC and UT Austin online masters are much more selective (~30%).
If I need deeper analysis or a more critical second opinion, I'll go with ChatGPT. But for generating a quick simple changeset that I can then mold into what I need, Gemini is superior, and the data in this article reflects that.
Regardless of the model, my default prompts always include instructions to avoid unrelated refactors, favor the minimal change set that resolves a bug, etc.
I had been searching for a good benchmark that provided some empirical evidence of this sycophancy, but I hadn't found much. Measuring false positives when you ask the model to complete a detection related task may be a good way of doing that.
For some people, Prozac is a very dangerous drug. It is fully deserving of its FDA black label warning (which it didn't have 30 years ago).
That street view was filmed taken two months ago, when it was still warm and nice out, so tent activity would've been at its peak.
I wish I had seen your post earlier because I literally walked that stretch of road earlier this evening -- a couple friends of mine from out of town are going to the Patti Smith show at the Paramount tonight and we had drinks nearby. No tents in sight though we did encounter someone walking around with a blanket wrapped around their head. But still, one probable homeless drug addict is hardly "overrun".
It's really not as you describe... I agree things were getting worse in ~2019 and then became way worse during the pandemic, but it's much different now.
It sounds like your last visit was during the COVID-19 pandemic. Homeless encampment conditions in downtown Seattle and throughout the city have much improved since then. Today, visible homelessness is effectively the same as it was back in ~2005.
At my company we put a big emphasis on code reviews. We encourage devs to pull request code fairly regularly to keep PRs relatively small (when possible) -- before so much code has been written that it's not really possible to change course without blowing up deadlines. We encourage our junior devs (who might not be capable of identifying bugs or proposing fixes on code written by a senior) to ask questions in their code reviews -- to verify assumptions, to request an explanation of how something works, confirm that a particular edge case has already been considered, etc. It can be hard to get a junior dev comfortable with doing this (questioning a senior dev), but even if the junior isn't identifying bugs it will often lead the senior to better understand their own code and the architectural concepts that underpin their own coding decisions. Like the author points out, this only happens because the senior dev endeavors to explain their work to the junior dev (Protege effect). Also, a good many times it leads the senior dev to re-consider how they wrote something and they might add a revision to address a possible edge case not previously considered. I hadn't thought of it this way before, but this is the Socratic method that the author talks about.
We also put a big emphasis on in-code comment writing -- largely following the commenting principles laid out by John Ousterhout's "A Philosophy of Software Design". These comments are of course for long-term maintenance purposes, but they also benefit team learning. Class, method and variable naming are obviously important too. Our internal code reviewing mantra is that 'I want to be able to read your code like a story book -- when I get to the end, I at least want to be able to understand what happened'. Not always possible, but a good goal. Writing comments and choosing class/method/variable names in pursuit of that goal massively contributes to the learning of the team. During our code reviews, one of the most common requests by reviewers is for the author to add a comment explaining something that was very difficult (or impossible) for the reviewer to grasp on a first read.
This approach has worked very well for us. Everyone learns and our product quality improves.
I frequently hear this point expressed in cloud vs colo debates. The notion that you can't achieve high availability with simple colo deploys is just nonsense.
Two colo deploys in two geographically distinct datacenters, two active physical servers with identical builds (RAIDed drives, dual NICs, A+B power) in both datacenters, a third server racked up just sitting as a cold spare, pick your favorite container orchestration scheme, rig up your database replication, script the database failover activation process, add HAProxy (or use whatever built-in scheme your orchestration system offers), sprinkle in a cloud service for DNS load balancing/failover (Cloudflare or AWS Route 53), automate and store backups off-site and you're done.
Yes it's a lot of work, but so is configuring a similar level of redundancy and high availability in AWS. I've done it both ways and I prefer the bare metal colo approach. With colo you get vastly more bang for your buck and when things go wrong, you have a greater ability to get hands on, understand exactly what's going on and fix it immediately.
Yep. Setting maths and motors aside... it's why helicopters have service ceilings and why no one has built a helicopter that can fly away into the stratosphere.
A "cash buyer" just means that the buyer didn't open a new mortgage to close the sale. Cash buyers often bring in cash from other interest-accruing loans -- such as HELOCs or portfolio loans. Foreigners or irregular income earners are a couple examples of people who might not qualify for a conventional mortgage and would need to tap into alternative loans to buy a house and thereby become a "cash buyer". Cash offers are also considered more competitive (they close faster), so someone might make a cash offer (via other loans) just to make their offer have a higher chance of succeeding.
That's not really what anyone is suggesting should have happened. The maintainer should've just taken the two minutes of extra time required to checkout the OP's code, make whatever changes the maintainer wanted and commit it with co-authorship.
That clearly would've been the best course of action for the maintainer to follow (especially given that the OP expressed his desire to the recognized for his contribution) -- the best fix gets merged in and the work of others is acknowledged/respected. That said, I'm not surprised it didn't happen -- social niceties often seem to escape the maintainers of these sorts of repos...
https://www.amazon.com/Stingmon-Pack-Sticky-Fruit-Fungus/dp/...
It's essentially a better looking version of fly paper. They're easy to place alongside indoor plants. Fruit flies and gnats are attracted to decaying organic matter and the moist soil of indoor plants is an often overlooked oasis for them. Gnats are more likely to hang out in indoor potted soils (especially if overwatered) because they feed on fungus, but fruit flies can take refuge there too.
A couple years back I had a months long battle with fruit flies. Kitchen was always clean, garage sealed up tight, no indoor compost, I used apple vinegar traps of all styles but nothing solved the problem until I placed those sticky paper inserts at the base of all my indoor plants. Within a week the fruit flies were gone.
Since when is it "bizarre" to ask someone if they've based their assertion off of hard data? I replied to at-w's fairly remarkable claim that white collar criminals are less likely to harm people while out on bail than non-white collar criminals. That assertion is not a forgone conclusion like the wisdom of "look both ways before you cross the street". Clearly it's reasonable to ask the poster if they're basing their assertion off of some hard data.
> Those two people are asshole fraudsters, but they don't present a physical danger to people around them.
We're talking about the propensity to harm others while out on bail. Harm is not limited to physical harm. The two examples I gave were of white collar criminals who continued to defraud/extort others while they were out on bail.
I'm not so sure that's true... do you have data to support that? I can think of some counter examples pretty easily off the top of my head -- Billy McFarland, Michael Avenatti, etc.
That's a pretty rude response and also invalid. He's not dumbfounded at the slower pace of life. He's dumbfounded that a nation of 300k could have a week long electricity outage and not have a single resident capable of fixing the issue or a backup plan ready to activate. It suggests exceptionally poor planning -- even for an island nation in the Pacific.
That line in the Wikipedia article seems to conflict with the book I read by Andrew Leatherbarrow "Chernobyl 01:23:40". In the book he states that if the water hadn't been drained and if the molten core had reached the water it "would have done unimaginable damage and destroyed the entire power station, including the three other reactors."
It's a shame that the Wikipedia article doesn't cite it's source on that claim. It would be interesting to reconcile the seemingly conflicting information.
I did not say that the IAEA paper was about molten rods hitting the coolant water. There is more than one way that Chernobyl could have been much much worse. According to the paper, different wind and rainfall could have made the disaster 200-400x worse in terms of radiation consequences to humans. To say that is significantly worse would be an understatement.
> Popular books have the incentive to garner sales - often through dramatization - not report accurate findings.
It seems like you've made up your mind and no amount of evidence to the contrary will change it. I don't think I'll bother to continue participating in this line of discussion.
However, it's not just Andrew Leatherbarrow who thinks so. All it takes is a simple Google search and you'll find reputable research papers hosted by the IAEA whose primary conclusion is that the accident could have been much worse. Here's one example: https://inis.iaea.org/search/search.aspx?orig_q=RN:18009127
If it wasn't close, as you suggest, then why did a crew of people wade into highly radioactive water -- a probable suicide mission -- to manually operate the valves to drain the water?