> In that sense, LLMs are embodying the Unix philosophy. Of course, this analogy has holes so big you can easily ride a horse through. LLMs are neither small nor do they do one thing—you could even argue that some of the things they do, they certainly do not do well.
- parse command line arguments in a slightly different way from other tools
- parse some ad hoc input format specific to itself
- do one or more actual jobs
- produce output in its own ad hoc format
- produces a termination status; here there can be variations: tools written "void main" that return a nondeterministic status; tools that use multiple nonzero codes for multiple interesting non-success conditions.
This messy way of doing things has "won" in AI ecosystems, I suppose.
People love to say the Unix philosophy is "Write programs that do one thing and do it well". But this does not really seem to me to really match Unix practice. And it doesn't match LLMs either, as the article notes.
(So what is this article talking about? I guess it's talking mainly about "Write programs to handle text streams, because that is a universal interface".)
My Java, .NET, Go, JavaScript/Typescript code running on serverless deployments, or low code/no code agentic tools, don't care what OS is powering the underlying type 1 hypervisor running their containers.
He's talking about philosophies in the article, one of which is that "text is the universal interface". LLMs are embracing this, as Unix did decades before.
That famous phylosophy only exists on a book that gets idolatred by some.
Go check the man pages of any commercial UNIX to see how many of the commands actually abid by such famous phylosophy that gets passed around, of each command doing a single thing well.
It is a endless list of options, and multiple capabilities for each of them.
The biggest slow down on MacOS compared to Linux is the default filesystem APFS (but hey HFS and HFS+ were also slow). But not just that, the Linux dirent cache is optimised to within an inch of its life (it's deliberately sized to match CPU cachelines among other optimisations). And one of the chunks of that slow down is upper / lower case checks (Mac filesystems be default treat upper and lower case as the same thing when it comes to matching a filename).
Because of that Linux works so much faster with small files, and text files are small compared to audio, video, etc.
> Many of the command-line tools I use have been around for quite some time now1 but they still work admirably and allow me to do things like this:2
> [...]
> If this reads like gibberish to you, my younger hothead self, full of (neo)vim and vigor, would have hit you with the old “Linux is very user-friendly; it’s just also super picky about its friends.” Yes, younger me was adept at making enemies like a craftsman
No, it reads like you are an entitled fanboi and need to touch gra^W^W talk with a real human beings outside your small citrcle of nerds. Even better - to work a couple of weeks with your own hands and your own back. That helps.
> In that sense, LLMs are embodying the Unix philosophy. Of course, this analogy has holes so big you can easily ride a horse through. LLMs are neither small nor do they do one thing—you could even argue that some of the things they do, they certainly do not do well.
So the title is just clickbait
yep. so exhausting.
OT: Please refrain from commenting and just flag the article. This might seem harsh but it’s a strong signal to the submitter to find better content.
Flagging is for content that breaks the guidelines, not for content you disagree with.
Every Unix tool does four-and-a-half things:
- parse command line arguments in a slightly different way from other tools
- parse some ad hoc input format specific to itself
- do one or more actual jobs
- produce output in its own ad hoc format
- produces a termination status; here there can be variations: tools written "void main" that return a nondeterministic status; tools that use multiple nonzero codes for multiple interesting non-success conditions.
This messy way of doing things has "won" in AI ecosystems, I suppose.
People love to say the Unix philosophy is "Write programs that do one thing and do it well". But this does not really seem to me to really match Unix practice. And it doesn't match LLMs either, as the article notes.
(So what is this article talking about? I guess it's talking mainly about "Write programs to handle text streams, because that is a universal interface".)
Indeed:
https://news.ycombinator.com/item?id=49393741
My Java, .NET, Go, JavaScript/Typescript code running on serverless deployments, or low code/no code agentic tools, don't care what OS is powering the underlying type 1 hypervisor running their containers.
He's talking about philosophies in the article, one of which is that "text is the universal interface". LLMs are embracing this, as Unix did decades before.
That famous phylosophy only exists on a book that gets idolatred by some.
Go check the man pages of any commercial UNIX to see how many of the commands actually abid by such famous phylosophy that gets passed around, of each command doing a single thing well.
It is a endless list of options, and multiple capabilities for each of them.
Not only are LLMs perfectly equipped for command-line interfaces, Linux is also the most performant OS for hosting the models locally.
How so? Compared to say Mac OS? (Just curious)
The biggest slow down on MacOS compared to Linux is the default filesystem APFS (but hey HFS and HFS+ were also slow). But not just that, the Linux dirent cache is optimised to within an inch of its life (it's deliberately sized to match CPU cachelines among other optimisations). And one of the chunks of that slow down is upper / lower case checks (Mac filesystems be default treat upper and lower case as the same thing when it comes to matching a filename).
Because of that Linux works so much faster with small files, and text files are small compared to audio, video, etc.
> Presenting at first nothing but an input box to the user, they constituted a deliberate break in habits for many
No, users were used to it because that's how Google works.
s/Unix/The CLI/
But yes. That’s true.
> Many of the command-line tools I use have been around for quite some time now1 but they still work admirably and allow me to do things like this:2
> [...]
> If this reads like gibberish to you, my younger hothead self, full of (neo)vim and vigor, would have hit you with the old “Linux is very user-friendly; it’s just also super picky about its friends.” Yes, younger me was adept at making enemies like a craftsman
No, it reads like you are an entitled fanboi and need to touch gra^W^W talk with a real human beings outside your small citrcle of nerds. Even better - to work a couple of weeks with your own hands and your own back. That helps.