[dangoodmanUT]

Giving agents linux has compounding benefits in our experience. They're able to sort through weirdness that normal tooling wouldn't allow. Like they can read and image, get an error back from the API and see it wasn't the expected format. They read the magic bytes to see it was a jpeg despite being named .png, and read it correctly.

[storystarling]

Matches my experience with print-on-demand workflows. I tried using vision models to validate things like ICC profiles and total ink density, but they usually just hallucinate that the file is compliant. I ended up giving the agent access to ImageMagick to run analysis directly. It’s the only reliable way to catch issues before sending files to fulfillment, otherwise you end up eating the cost of failed prints.

[jtbayly]

I don’t understand why you’d try to use an LLM for that step if there is already a tool that you can call to check it. Help me out.

[ndsipa_pomu]

> They read the magic bytes to see it was a jpeg despite being named .png, and read it correctly.

Maybe I'm missing something, but it seems trivial to implement reading the magic bytes. I haven't tested it, but I'd expect most linux image displayers/editors to automatically work with misnamed files as that is almost entirely the purpose of magic bytes.

Personally, I think Microsoft is to blame for everyone relying on file extensions too much as it was a bad idea which led to a lot of security issues.

[lpcvoid]

I don't understand why this is something special that somebody would need some LLM slop generation for? Any human can also do this in a few seconds using normal unix tooling.

[hex4def6]

That's like saying 'why give people calculators, when you can pull out a slide rule'

The whole point is that you are enabling the LLM through tool use. The prompt might be "Download all the images on the wikipedia article for 'Ascetic', and print them on my dot matrix printer (the driver of which only accepts BMPs, so convert as needed)"

Your solution using file / curl is just one part of the potential higher level problem statement. Yes, someone could write those lines easily. And they could write the wrapper around them with only a little more difficulty. And they could add the 404 logic detection with a bit more...

Are you arguing LLMs should only be used on 'hard' problems, and 'easy' problems (such as downloading with curl) should be done by humans? Or are you arguing LLMs should not be used for anything?

Because I think most people would suggest humans tackle the 'hard' problems, and let the tools (LLMs) tackle the 'easy' ones.

[darknoon]

I think you'd find that it's far from "any human" who can do this without looking anything up. I have 15y of dev exp and couldn't do this from memory on the cli. Maybe in c, but less helpful to getting stuff done!

[toddmorey]

Well LLMs do make normal Linux tooling more accessible. I needed a video reformatted to a new aspect ratio and codec and Claude produced a rather complex set of arguments for ffmpeg that I hadn’t been able to figure out on my own.

[Lerc]

I think this is missing the point, These are tools that enable the LLM to do things that humans can do easily.

It stops an LLM from being blocked by the inability to do this thing. Removing this barrier might enable the LLM to complete a task that would be considerable work for a human.

For instance, identifying which files are PNG files containing pictures of birds, regardless of filename, presence or absence of suffix. An image handling LLM can identify if an image is of a bird much more easily than it could determine that an arbitrary file is a png. They can probably still do it, wasting a lot of tokens along the way, but using a few commands to determine which files to even bother looking at as images means the LLM can do what it is good at.