I'd be happy if things stopped interfering with standard X11 select/paste. It's now a random crap shoot if I have to hold Shift or not to regain that elegance.
And, the whole idea of copy/paste having to use both mouse AND keyboard (select Ctrl-c click Ctrl-v) is barbaric. X11 got it right and it seems all "modern" apps are trying really hard to introduce barbarisms.
True. Though, I self censor to appease myself as I have caught myself picking up claudisms. I was mortified when I realized that I had started to use "land" as a verb related to finishing some bit of work.
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.
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.
Another way to interpret it is that a massive sample bias is governing your premise. Programmers are embracing LLMs to scratch their own itches and programmers tend to work in terminals (yes, many use IDEs) so they build to their own environments and HN readers and contributors tend to be programmers talking about programming things.
It's not so straight-forward. Either you must add hooks the the agent to notify tmux directly or you must use an external tool that polls tmux to determine one of its panes has gone silent and then based on that, send notification to tmux.
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.
This split in what different people or groups get out of LLMs is pervasive and really interesting. In the beginning I was dismissive of those with bad experience with a "you are holding the tool wrong" smugness. But as I read more and more experience, I see all combos and I now know my initial knee jerk conclusion was clearly wrong. There are newbie programmers getting good or bad results as well as experienced developers getting either flip of the coin. I don't know what to conclude. I really want to know what are the lines that explain these very different outcomes. Is it the types of problems being solved? The harnesses? The programming languages? FWIW, my experience has been that among my cohorts of mid to deeply experienced developers working in the domain of experimental physics, all have leveled up various degrees after adopting Sonnet and Opus level LLMs using claude code CLI in Python, C++ and web tech, small scale scripts up to multi-package novel system develop and green field as well as incremental development and code maintenance.
Maybe it was a thing from before clock speeds saturated and Moore's law mutated into being satisfied by ever increasing core count? It could have been useful when spec'ing hardware with the goal of running multi-threaded jobs that scale both their throughput and RAM requirements linearly with number of threads. That would make it sort of a continuous version of the more discrete GB/core rule of thumb. However, such linearly-scaled MT jobs are a subset of all MT jobs. And, ST jobs are not covered. A 2GB ST job on a 1GB / 1GHz machine will again need two cores, wasting one. When run on a 5GB/5GHz machine the job needs only its one core but must waste 3GB.
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.
In particle physics, processing jobs face a limit of about 2GB/core. This is driven by the realities of "grid computing". The hardware in the computing facilities have approximately 2GB/core and jobs allocate based on number of core. This ratio has been fairly stable for a long time. Some facilities may have a bit more RAM per CPU core but 2GB/core is the general rule of thumb. I hazard a guess that this will not change throughout the (hopefully small number of) years that this memory cost bubble persists. In fact, the increase in cost may lead some facilities to keep older hardware going beyond its EOL/warranty period, prolonging a ratio that may actually be relatively generous compared to today's hardware systems.
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.
Yes, the spam arms race is a really good analogy. In that light, my thoughts are aligned with heuristics that might be applied with procmail or in the original, pre-learning, spamassassin.
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.
I think everyone / every project needs to adopt a strategy consistent with their values.
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).
And, the whole idea of copy/paste having to use both mouse AND keyboard (select Ctrl-c click Ctrl-v) is barbaric. X11 got it right and it seems all "modern" apps are trying really hard to introduce barbarisms.