frumiousirc

> One Google search (yeah I'm old, sorry, nobody "Googles" anymore)

Maybe that's your answer. Search is so bad and LLM so good that it's faster and easier to re-implement than reuse.

The only thing that slows down the new paradigm is the apparent requirement of posting the output to HN so others will find it.

That irony is not lost on me.

> cmd+v just pastes images

Can I use normal X11 text selection with mouse button-1 and pasting with button-3?

In the end, failure to handle basic X11 select/paste is what keeps me away from herdr and tmux.

I guess it was a figma of our imagination.

Yes, this sounds like the interview that I was remembering.

>Fundamental forces just are, and you understand them by studying them.

This is largely the point I was trying to make. One must understand QM using non-everyday ideas developed with math and measurement. But once those ideas are held, similes/metaphor (sometimes actual isomorphs) can be useful parts of that understanding and its communication between those that share the basis for that understanding.

Am I alone in thinking type hints are largely a waste of time in Python and can be actively harmful?

I had claude run ty via this new "uv check" on a moderately sized Python package (cli+tui to a multi-transport messaging system) and it found 67 things. Claude checked each finding for bugginess and found 1 is marginally worth fixing. A large fraction of the findings were ty guessing the type and being wrong. Hinting would I guess remove those wrong guesses but hinting is a PITA and greatly increases code size, both of which is bad for human and LLM.

Do people really get benefit from going all-in with type hinting?

I take issue with "understand". I agree QM can not be understood in terms of everyday experience. One must build experience, language and proper metaphor for the understanding. For example, in the intro Ross uses the example of explaining a waterfall to someone who never saw it. He says that can be done but he relies on implicitly the listener knowing what people on Earth may take for granted. That understanding of a waterfall can only happen if the listener already has some understanding of fluid flow and gravity. We do, but say a newly found alien friend from a dry environment that had never experienced fluid flow would not have the mental building blocks to understand it. Feynman gave a famous interview where he said, essentially, "no, I can't explain it to you because you are too ignorant" (he said it more politely). Going the other direction, Physics steeped enough in quantum theory do understand QM enough to have meaningful discussions free (at times) of rigorous math. They do this because they have a shared language, vocabulary, metaphor. Sure, they must rely on math and experiment to ground that understanding in truth but I guarantee they do not communicate understanding (solely) in math and measurement data.

Or at all. Not even a "this page is useless without javascript because the author is too incompetent to provide text as direct HTML" message.

If you are paying for the API anyways, I don't think it makes a difference. What is different is if you are on a subscription then you need to pay more to use `claude -p`. But then Anthropic started adding free credits, at least for Team and above plans, to offset the cost. Drug dealer pricing.

But don't worry, I'm sure next week it'll all change in some new and confusing way. And not for the benefit of the customer.

Or, wrong by design. There is something about nudging users to use the claude CLI from which Anthropic extracts value. Otherwise they would not charge extra for "claude -p" or ACP access.

The tmux send-keys + terminal scrape is the LLM version of the analog hole of DRM'ed audio.

Money for the Genesis Mission is coming out of science budgets. Given how damaging this funding for Artificial Intelligence as been for US science, can't wait to see what Super Intelligence funding does to it.

There exists https://github.com/asg017/sqlite-vec

And for small enough vector sets, holding them in memory is reasonable. Most personal photo collections would fit that scale.

I assume individuals have to meet in order to become peers.

> I do not fully understand where the disconnect comes from. I do believe people that say that they get crap from LLMs, and I suspect I can guess some of the reasons for that, but I cannot be sure.

Same here. There is an introspective comment below by khazhoux asking the question from the opposite experience. Why do developers end up on different sides of this coin?

LLM capability is obviously important variable. But those with bad experiences report using top tier models, so that isn't it. Likewise, level of experience can be ruled out. Each side of the coin have experienced developers reporting.

A lot of the other variables are not reported but I can go from my own experience.

Greenfield vs brownfield? The first is indeed usually easier but I get great results updating large code bases with decades of development. And I suspect developing greenfield with LLM is easier as the code is better written from the start.

Rarity of the subject matter? In principle, yet another XYZ app or web page is well represented in the training data so the LLM should have an easy go at making similar. In the past with low-end LLMs, this was noticeable. Working in relatively obscure programming languages produced just garbage. But, that was prior to the inflection point. And today I get good results working on relatively arcane scientific/mathematical algorithm as I do when I ask the LLM to barf out some web app.

Different levels of testing and validation and expectation? Even best LLMs make mistakes. The better LLMs make fewer and expose fewer still to the human as they create internal tests. Maybe people have different expectations and those with bad experience expect perfection from a single prompt? Perhaps, but any experienced developer knows bugs are a part of software development.

What else?

Whatever the answer, it's not a simple one and it may be a confluence of many smaller things. Maybe different developers have a multi-variant function in their brain that pops out a different quality-of-software score and also a different threshold that divides good from bad and all we see in their reports is that binary conclusion.

HTTP is also still somewhat popular.

But, seriously, that got me curious. There are many protocols from that early era that are still with us today. NTP, DNS, SMTP, IMAP, BGP, SNMP, NFS, ICMP. If you allow the 1990's as counting as "old" we can add SSH and SSL, DHCP, LDAP.

Org-roam helps this problem for me in two levels. Sometime around the turn of the millennium, I started with org by writing files in a directory where I made a "topic" sub directory for each "thing" I wanted to note. This is rather high level and made creating each new "topic" feel too formalized, like I was writing a paper or a blog. That raised some mental bar to staring a new note and so I didn't write as much as I wanted to. org-roam-node-find helps by making it easy to emit disconnected bits. C-c n f and time some bits and either accept an existing match for update or start a new file is a much lighter-weight version of my "topic" directories. Then, even lighter is org-roam-dailies (C-c n d d) which does not even require me to be coherent enough to think of a "title". For this approach to be useful needs good recall methods and frankly that part is a bit weak in my setup. I use deadgrep or org-roam-node-find but would like to add some search that is a little more comprehensive and low-friction.

You are ignoring that prompting is fractal all the way down to the scale where the human writes everything by hand.

If I say, "start a C++ package skeleton" I'm getting CMake, not waf, make, bjam, or whatever. If I state the build system, then I'm still getting some package layout drawn from the training distribution. If I specify that, I'm still getting snake_case or CamelCase or whatever naming convention, drawn from the training distribution. If I specify that, etc etc.

It is distribution sampling all the way down.

So, yes, literally LLMs ARE reaching for "it".

> (and HEP in general)

Not for any neutrino experiment I know of. There are paper committees that govern publication but the actual preprint submission to arXiv is always done by one of the authors.

> I would think arXiv can work something out for these cases.

Yes, I also expect special cases would be defined.

I've used org-babel in big and small contexts for more than a decade. I generally reach for the patter for a few goals:

- Keep diagram source (eg Graphviz dot) with the document.

- Write software developer manuals that can reference code robustly as the code changes (eg include code snippets from source based on regex).

- Literate Coding / Reproducible Research pattern. Eg, org file explains and generates/builds/runs code and graphs/figures which then get included back into the document.

Some of the problems

- At some scale, one needs a DAG (eg make) or to make every command idempotent with fast no-op. Otherwise, each little change to a source block takes too long and there is a worry that something didn't update which should.

- At some scale, the document becomes the size of a library/package and it does not compose and/or I want to run the code outside of the document.

- The unenlightened around me do not use Emacs so an org file is a "me" file. In some ways this is a plus as it keeps others fingers out of my pie but it also means no way to share the baking.

That was in the days before LLMs. As ellieh's #3 points out, things are different now (we all know that). I now have an LLM externalize org-babel. The LLM maintains an org or LaTeX document describing bits of work, an external library/CLI which runs to produce content including putting numerical results into LaTeX macros, a Makefile or Snakemake to regenerate content and figures. When things are found to change prior understanding the LLM remakes a section of prose in the LaTeX document. I then write my own notes or another LaTeX document so that the trip through eyeballs to fingers on the keyboard assures I keep some level of understanding.

Likewise, in the software documentation goal, it's far better to give a good LLM access to the source and have it generate documentation targeting some learning goal with follow exploration via Q&A than it is to read some prepared document that assumes my goal. Software documentation is kind of a relic useful only for those people that have not yet taken up LLM tools.

The basic idea of Lifestreams is good for its metaphor but a lot of important implementation problems are ignored: ballooning storage from "clone" operations for every edit, ever increasing "view" query time, lack of a provenance back pointer. I think a lot of this can be solved with an SQL store, git style content hashes but there are still leaks to plug. One big one is how to resolve hashes given the content stores can move or disappear? Here I am assuming the system does not attempt to intern and reinvent git, github, dropbox, Maildir, etc? Then there is the huge footprint of how to collect inputs. Plugins for browser, email, git, perhaps even file system. It's all rather daunting to contemplate yet also feels like such a workable system is just within reach.

TRAMP actions are also rather slow (high latency). OTOH, tramp-rpc relies on a little tool to run on the remote and is much snappier. This proves there is a better middle ground than TRAMP with nothing and whatever abomination VSCode injects. Basically, busybox with a persistent RPC connection is all one needs.

> Published

Posted. Having a preprint on arxiv is not publishing.

The meta problem with all this desktop UX design discussion is that it's not actually very problem driven.

Many of us solve our UI problems and we land into our own happy minima.

Many of the UX "solutions" are either invented problems or not my problems or worse, grinding some anti-me agenda.

Like many, a lot of my UX improvements have been to simplify the UI. Tiling, with just a few windows per virtual desktop in herbstluftwm: kitty, emacs, browser and some rare transient application (usually PDF or image viewer).

The idea in the screen shot horrifies me. Why would I buy an expensive high pixel monitor just to use only 10% of it to display a single window? Why would I want to waste CPU to animate the migration of a full window to a single button icon (another example given)?

These UI "innovations" are great for movie props but do they actually help in reality? Not that I see. The "stagnation" of UI to me is more a plateau. Anything truly new must be driven by new "I", no input/output channels between user and computer.

The one interesting idea I saw in the article was Lifestreams. I think storage and recall is something that needs improvement and new ideas because for me that is a problem. I produce and consume too much info while recalling it is hard and while also I often do not produce or consume info that I wish I had.

Again, it's the I/O that drives the progress.

What is the interplay between such delegation and token cache timeout? If Fable is truly active for 4 days, enough to keep the cache hot, the cost would be astronomical. OTOH, if Fable idles while subagents are active, then each awakening is a cache miss.

The point is you can quickly get any yes's, and then subject them to more expensive scrutiny.

> the maximum achievable throughput is 26 bps at 1.5 m and goes down to 22 bps at 4.5 m.

And when there are more than one transmitters in real world conditions instead of anechoic chamber?

It's cool and all and if this work is for it's own sake, for the sake of research, no issues. But otherwise, I struggle to think of practical use cases. I grant that my imagination may be deficient.

Thanks! I've used graphviz for more than a decade and had never learned of gvpr.

Do you have thoughts on the prospects for inter-operation between the "recoll" application and hister? Like, maybe an adapter that let's hister read recoll's xapian database/index? Or, a tool that converts/syncs beween hister's store and recoll's?

They also define and measure an "IPJ" as well as "IPW"

> the NVIDIA B200 achieves 1.6× to 2.3× higher intelligence per joule than the APPLE M4 MAX across QWEN 3 and GPT-OSS model variants

The B200 = "cloud", M4 = "local".

So "cloud" does even better in energy than it does in power compared to "local". Or, to flip it, "local" is both slower and more expensive than "cloud".

> Unless I misread it, are they saying local GPUs use less energy?

You misread it. From the abstract:

> local accelerators achieve at least 1.4× lower IPW than cloud accelerators running identical models

That's "intelligence per watt". They also have IPJ, per Joule.

So, they find local is 40% "dumber" than cloud for the same power or 40% more power for the same "intelligence".

Tables 13 and 14 summarize their IPW and IPJ metrics.

But, to your actual point, I think the "local is 40% dumber per watt than cloud" message is still an understatement. And maybe this is something I failed to find in the paper but they seem to ignore the "idle baseline" costs and talks about explicitly focusing on the power consumption of just the accelerator under load.

There is a large baseline power consumption just to support the accelerator. CPUs, memory, PS losses, network, fans, general environment cooling. This "cost floor" is different for data centers and a "random local computer" and I think must be in favor of data centers which are designed and built with efficiency in mind.

Idleness should also be considered. My local GPUs at $WORK and home are idle more than they are used. Idle time energy in real world scenarios should be somehow attributed to those brief, punctuated times when LLM functions are actually active on the accelerator. Actual, local LLM usage of a GPU is brief (assuming one user per PC). Even with my heavy usage developing s/w I'd guess I heat up a GPU about one hour per day total, sometimes much less. If that is local then one must pay 23 hours of idleness for that 1 hour of "intelligence". Of course a local PC is used for other things and the idleness penalty must somehow account for that. OTOH, data centers try to maximize utilization so their idle time penalty would be much less, perhaps close to zero, by construction.

Apparently, nearlyepic is trying to deliver two veiled insults and a critique of judgement or perhaps of the current state of broader affairs. I'll attempt to translate:

- "no idea what you’re talking" = "you have outsourced expertise to an LLM"

- "solution that doesn’t actually work" = "piecemeal blocking leaves many problems still active"

- "used to be free" = "you / others in general now pay LLM services for the outsourcing leading to poor solutions while in the past poor solutions came for free"