The commands in their example are not equivalent. The ps | grep thing searches the full command line including argument while ps -C (and, presumably, the psc thing) just returns the process name.
Should you for some reason want to do the former, this is easiest done using:
pgrep -u root -f nginx
which exists on almost all platforms, with the notable exception of AIX.
Their other slightly convoluted example is:
psc 'socket.state == established && socket.dstPort == uint(443)'
Many new tools appear because people don't know how to use the existing tools or they think the existing tool is too complicated. In time the new tool becomes just as, or more, complicated than the old tool. Because there is a reason the old tool is complicated, which is that the problem requires complexity.
I too am dumfounded by this. Is it an off day? Have all the people that actually know how to do things with computers gone somewhere else? What is going on here?
Yeah I feel like I'm missing something here. I'm not sure if people being so dependent on these LLMs generating code is that widespread at this point or if this is some kind of publicity stunt.
You're not very off the the mark. To add in that extra detail, xAI is using portable gas turbines that are meant for providing emergency backup power in case of a catastrophic loss of power, like in the event of a natural disaster. Being portable, they lack the systems necessary to avoid polluting the surrounding air with oxides of nitrogen and formaldehyde - really nasty stuff. That shouldn't normally cause a serious issue, since the turbines are meant for temporary backup alone. But at Memphis, xAI is stretching the meaning of 'temporary'.
This isn't the first time: In 2019 Tesla illegally prevented OSHA officials from entering a Tesla site in Nevada (with a warrant and officer from the sheriff's office) to address serious workplace injuries.
These are what are claimed to be the onerous regulations slowing down innovation.
- it puts the command in the shell editor line so you can edit it (for example to specify filenames using the line editor after the fact and make use of the shell tools like glob expansion etc.)
- it goes into the history.
- It can use a binding so you can start writing something without remembering to prefix it with a command and invoke the cmd completion at any place in the line editor.
- It also allows you to refine the command interactively.
I haven't see any of the other of the myriad of tools do these very obvious things.
Thanks. I guess it all depends on the perspective. I do not see how editing the command is a good tradeoff here in terms of complexity+UI. Once you get the command suggested by the LLM, you can quickly copy and modify it, before running it.
qqqa uses history - although in a very limited fashion for privacy reasons.
I am taking note of these ideas though, never say never!
> Once you get the command suggested by the LLM, you can quickly copy and modify it, before running it.
Copying and pasting tends to be a very tedious operation in the shell, which usually requires moving your hands away from the keyboard to the mouse (there are terminals which allow you to quick-select and insert lines but they are still more tedious than simply pressing enter to have the command on the line editor). Maybe try using llm-cmd-comp for a while.
> I do not see how editing the command is a good tradeoff here in terms of complexity+UI.
I don't find it a tradeoff, I think it's strictly superior in every way including complexity. llm-cmd-comp is probably the way I most often interface with llms (maybe second to basic search-engine-replacement) and I almost always either 1. don't have the file glob or the file names themselves ready (they may not exist yet!) at the time when I want to start writing the command or they are easier to enter using a fuzzy selector like fzf 2. don't want the llm to do weird things with globs when I pass them directly and having the shell expand them is usually difficult because the prompt is not a command (so the completion system won't do the right thing).
But even in your own demo it is faster to use llm-cmd-comp and you also get the benefit that the command goes into the history and you can optionally edit it if you want or further revise the prompt! It does require pressing enter twice instead of "y" but I don't find that a huge inconvenience especially since I almost always edit the command anyway.
Again, try installing llm-cmd-comp and try out your demo case.
Don't use doom etc, just standard emacs, otherwise you won't have any
understanding of what is happening and how to fix it. Here's a list of
what I think is important, roughly more important to less:
- corfu+marginalia+vertico+embark+orderless is the standard completion stack now
- magit (maybe also see also the "casual" the transient front end for other modes)
- avy
- (fset 'yes-or-no-p 'y-or-n-p) ; 'Y' or 'N' instead of 'Yes' or 'No'
- (setq confirm-kill-emacs 'y-or-n-p)
- evil (optionally if you like vim keybinds, you still need to know basic emacs))
- if using evil: evil-collection, evil-args, evil-goggles, evil-traces, evil-escape, evil-nerd-commenter, evil-lion, evil-surround, etc are not "standard" but still useful
- configure melpa source
- which-key
- helpful
- undo-fu
- gptel
- projectile
- eglot
- saveplace
- desktop
- uniquify
- dired/wdired
- flycheck/flymake
- treesitter
Stuff that is nice but less essential:
- general (for making your own keybinds)
- some kind of multicursor mode (I use iedit but it's simple)
- yasnippet
- org (usefulness depends on the person)
I haven't switched to corfu+marginalia+vertico+embark so I don't know
what the equivalent is but helm-swoop is nice.
Also, very important, learn the help system (C-h <key>), especially
C-h f, C-h k, C-h w, C-h c. And the info system
For modal editing but more similar to the kakoune/helix model there's the meow package which I prefer compared to evil, for some people it might be worth looking into as its more customizable and allows you to have as much or as little modal editing as you want. I use meow and regular Emacs key chords at the same time without issue for example.
> Don't use doom etc, just standard emacs, otherwise you won't have any understanding of what is happening and how to fix it.
Doom and Spacemacs are IMO sufficiently good abstractions that you will almost never need to have understanding of the underlying system and to fix things. Sure for curiosity's sake you should still learn what's happening under the hood. But the abstraction is almost never leaky. I think everyone beginning Emacs should start with Doom or Spacemacs and optionally build their own config later on.
reply