I really want to see the point-of-view video of that tumble.
544 karma · joined May 31, 2016
This is a small typo in the text. It's spelled "ZeroMQ".
The title of the figure is ambiguous about what "SD" really means but I guess it is plotting the number of standard deviations of the 1991-2020 data measured from the mean of that data and plotted per day for the 1982-2026 data.
Here's the link that I read off the figure.
https://climatereanalyzer.org/clim/sst_daily/json_2clim/oiss...
Going up the URL path I get redirected to here:
https://climatereanalyzer.org/clim/sst_daily/?dm_id=world2
That shows measured temperature and 2026 as very hot (surprise) and in fact is the hottest to date for June+July. The standard deviation of that data is not 3.5 C but something less than 1.0 C. It is plausible that current temperature is about 3.5 sigma from the selected mean.
It's worth recognizing that the analysis is applying a biased conclusion prior to making the plot. It singles out post 2020 data to compare to pre-2020 data. and then concluding the held out data is a significant deviation with a cause. It almost certainly is but this is not a proper way to analyze data (unless one is pushing an agenda, be that for good or bad).
I think the sst_daily plot stands on its own without crafting this SD plot to emphasize the point. Especially when the accompanying text doesn't even explain it. It's a disingenuous message.
The poling requires tmux (not screen nor dtach, as far as I could find). And, silence for N seconds is just that, the poll doesn't know if that really means waiting for input or something else. With agents (like claude) that have a throbber/spinner going while "thinking", silence is a good indicator.
Kitty terminal can be polled for current text and then see if that has changed in N seconds. This would allow not having to depend on tmux which may be preferable to some kitty users. Generally, using tmux always surfaces some annoying problems for me.
In particle physics, as more of the code is being GPU-accelerated, there is now another integer ratio to worry about optimizing: CPU core per GPU device. Across the landscape, some jobs have zero GPU acceleration, others may need 100 cores to keep a GPU busy, or only 1 core. Yet others can tune their CPU/GPU ratio to optimize throughput given what hardware ratio a given facility provides. Only a fraction of the software in the ecosystem takes up this challenge.
Most physicist pretending to be software developers or vice versa who are involved in the field do not consider any of these computing realities. At some level, that's natural and excusable. It's hard enough to develop the simulation and reconstruction and analysis algorithms. Simultaneously optimizing their implementation for throughput on a given hardware assumption is even harder. Harder still is to do that optimization over the variety of hardware assumptions. There are only a few cases where this holistic thinking has driven the design of the software.
They look a little silly but cat-ears work surprisingly well.
As a consequence of this fixed RAM/core ratio, substantial software development effort goes to either making jobs fit in 2GB or if that is not possible then to utilize multithreading. Generally, particle physics processing does not particularly benefit from MT except in this fixed RAM/core situation. Sometimes large memory jobs are needed (inherently or because of bloat that is too costly to improve). When run on the "grid", these jobs must allocate multiple cores just to get "their" memory. If those jobs can use the extra cores, overall throughput does not have to suffer.
That's for conventional software, which still makes up the bulk of the computing. The situation for the growing amount of GPU-accelerated software is different and more varied. One trend can be seen relating to VRAM. Research groups with easy access to big GPUs like A100 write code to fit or exceed the relatively copious VRAM limits of the data-center GPUs, while groups that lack easy access to DC GPUs but have access to more modest "gamer" GPUs write more advanced software that can fit the smaller VRAM. In some cases, they write the software so it can scale the computation, keeping GPU utilization high while staying just under the VRAM limit.
General budget crisis and limited resources in the particle physics field are in part responsible for all of this tailoring of the software to fit the hardware. If better funded, particle physicists could spend more time doing physics and less time squeezing last drops of processing power.
A fight-fire-with-fire is to insert an LLM to judge and/or respond to new pull requests and issues. This brings its own risk as it lets anyone who can make a PR/issue inject a prompt. It would also put one more wedge between the real human contributors and the real human developers.
A "humanity score" could also be an ingredient. GitHub or 3rd parties, could maintain a score of how human an account is. The "humanity" of all text produced by an account could be judged by LLM and/or humans. This could be centralized or based on a web-of-trust. Actually, I'd also like to have such a thing for reading HN and reddit comments.
But still, any system we can dream up can be attacked and we are back to an arms race.
Unfortunately, I see the choice space here as having "developer effort" anti-correlated with "negative repercussions".
On one end of the distribution, a "hair trigger ban" strategy is low-effort for the developer but will have some fraction of false positives and some fraction of those impacted will complain to "the socials" and some fraction of those complaints will gain traction and, as we have seen, can unfairly taint the project or worse. Responding and managing the false positives also requires developer effort, unless the developers can sustain a "fsck the haters" attitude.
On the other end of the distribution, the developer can spends substantial effort to engage each submitter to ascertain and correct bad behavior, educate them on how they should engage other humans as a fellow human in this LLM era.
There is developer effort needed of different types along this distribution.
A divide-and-conquer strategy might go something like this:
- Rank each submission in some low dimension space (llm<-->human, malicious<-->helpful)
- When enough samples are collected, perform clustering in this space to determine stereotypes, name these clusters, and develop mitigating strategies and implementations as needed.
Mitigations from easy/extreme to hard/accommodating could include:
- Hair trigger ban button.
- Copy-paste a link to an explanation in a comment before closing and/or banning.
- Customized explanation in comment before closing and/or banning.
- Link or customized explanation of what must be done to move the sample to a more favorable category and close/ban if resistance or silence is returned.
- Ongoing engagement in the face of resistance or silence.
This "meta development" program to provide such a system/facility could of course be highly automated with LLMs, fighting fire with fire.
(Despite the length of this reply, it was written entirely by a random human on the internet and not an LLM).
Isn't this simply having your mechanistic script call `claude "Prompt that is well honed to provide a mini, guided, 99%-of-the-time automated LLM action to $THE_THING"`? And, possibly including some `--allowed-tools`?
But, does every prompt need the entire codebase?
Common Python Pain Points That Rust Addresses
1. Runtime Type Errors
The most common Python production bug: passing the wrong type to a function.
Type hints help, but they aren’t enforced.
Then comes calling out the existence of None, the GIL and packaging as common "pain points". None of these have posed any problem to me essentially ever. Packaging used to be honestly annoying but since uv hit the scene, not at all.
I should have known better and stopped after reading "microsoft".
And some dedotaded wam.
It's not quite apples-to-apples. It was Opus on Firefox 148, Mythos on 150. A better test of Mythos vs Opus would have been to apply Mythos to Firefox 148. Or also re-apply Opus to Firefox 150.
Do we know all the Opus+Firefox 148 bugs are fixed in Firefox 150? Do we know the number of new bugs introduced per Firefox release?
I want that. Can you give some details?
A search finds modeverv/markdown-to-org which looks 80% there but activates based on a yank or converting an already loaded markdown buffer. Perhaps it can be made to apply on opening a .md file.
You draw made up lines on made up plots and call it evidence, obviously.
Yes, but exclusion regions are.
Same pattern as say a sub-reddit subscriber count compared to the number of nicks currently in an associated IRC channel, though IRC lurkers soften that distinction.
I'm not sure how to tie this all back to the zig story other than to point out the stated premise that zig is not short of PRs and so they can pre-select for no-LLM contributions. I think that is a good move for them and I get the "contributor poker" idea. But, the game changes when the premise breaks and the flow of newbies reduces to a trickle. At that point, if there are still active zig people who still want newbies, they may need to broaden their net. But if/when that happens, it may be too late to recover by opening to LLM-assisted contributions.
The analogy is a bit broken in a way that may add confusion. The hand comes back to it's starting configuration after two 360° rotations, each along a different axis. A spinor's symmetry has 720° of rotation along a single axis.