4 ms·
>the trade-off is not so clear. Assuming very basic knowledge of CLI on Linux for i in *.pdf; do convert "$i" "$i".png; done 10 seconds flat If you've n
by ur-whale 1y ago
>the trade-off is not so clear.
Assuming very basic knowledge of CLI on Linux
for i in *.pdf; do convert "$i" "$i".png; done
10 seconds flat
If you've never heard of convert (part of imagemagick) then:
open chatgpt/gemini/claude/whatever, enter prompt:
linux cli tool to convert pdf to png
Adds 30sec tops
Thank you for making my point for me.
- delta_p_delta_x 1y agoSo I, running Windows, using PowerShell, already knowing CUA shortcuts, generally familiar with Acrobat and its features, having to eventually use the mouse and keyboard anyway to navigate a JS-heavy insurance website, additionally have to: 1. Install sh/bash to get `for`, or convert your 'handy one liner' to PowerShell, and verify it works 2. Install ImageMagick, then ask an LLM to tell me what to do 2.5 And somehow LLMs don't present `convert`, but `pdftoppm`, or worse, both, and give me one giant essay, without my pre-configuring the system prompt to be concise and not overly wordy and avoid meta-sentences like 'if you want more help let me know'; 3. Then navigate to my website anyway, and upload everything. So no, point not made for you. With my existing environment and existing knowledge, it took me two minutes to get the work done. Even the slightest search would have brought me above that measure. There is a local minimum for a certain n at which discoverable GUIs absolutely excel over CLIs.
- ur-whale 1y ago> So I, running Windows, using PowerShell Well, what can I say other than people don't usually get in races with lead weights tied to their ankles.
- delta_p_delta_x 1y agoIt's not a race; it is optimising the process for the input size, one's existing knowledge, and context-switch duration from an existing environment. If I had fifty PDFs, I'd look at scripting the result immediately. I had six, and I had Acrobat. I chose the GUI option, and it got me a decent result quickly enough. A code analogy: it's a bit like how O(n^2) sort algorithms are the fastest for small n, and how most library sorts choose a different algorithm for different `n`. This is what I meant in my initial comment when I said > Sometimes, the trade-off is not so clear.