If we want the year of the Linux desktop to actually happen we need to have good GUI tools for almost everything. The second you say “command line” most people’s eyes glaze over and they say they’ll stick with Windows. Believe it or not guys, most people just want something that functions out of the box and they don’t want to mess with it.
You disgust me
I do like the “lazy” trend though. Lazygit, Lazydocker, etc.
I’ve been at risk for carpal tunnel before, which is why I primarily use a keyboard.
…on a GUI.
Linux is great for a lot of things but so many open-source apps are terrible about giving you a visual interface for something, and then letting you use your keyboard to navigate it. Granted, Windows has steadily enshittified its lead on that front as well.
I like GUIs because it makes æinux usable for my young daughters, my mom and casual users, that just want to point and click. I also like to have both options. A more userfriendly linux, benefits all.
crying chudjak “Sob…sob… YOU’RE MISSING OUT ON SO MUCH!! You’re even ruining open source by forcing developers to make their things more usable for normies instead of fixing bugs! I’m so frustrated! I used to remember the time when I knew all the Linux users, hazing newbie users, now its full with woke people pushing Rust on everyone!”
I like well ordered man pages.
You like OpenBSD.
I don’t really care. GUI or Cli, it don’t matter. But sometimes GUIs are far better even in Linux.
A real gripe I have with the Cli is when you install nVida drivers in Fedora from the terminal. Whether you are newb or a grizzled veteran of the Unix wars, you are going to enter, (or copy and paste for newbies), all the proper commands and things will go well until you get to the very end. When you are all done entering all the commands it says to reboot and you are looking at that blank blinking cursor, you would think you were done and ready to go.
But if you are in a hurry and missed the ‘fine print’, you probably missed the part where it says to wait for a while like 5 minutes or more BEFORE you can reboot. And no one knows how long for sure because the computer is recompiling your new kernel.
So there you sit, staring at your screen and a blank, blinking cursor without the slightest hint when the compile is done and wondering if it’s safe to reboot. Me, I go make a cuppa and go look out over the lake for a while. But it catches the beginners at least once.
Bring on the GUI and a bloody progress bar!
Yeah, that there was never a standardized call to the terminal to display a progress bar?
I type like a chimp throwing bananas at a keyboard. GUIs prevent the inevitable “command not found” oopsie.
That’s weird, other package systems have that solved by recompiling the kernel as a post-update hook that the update command waits for before exiting.
Seems like a bug that fedora’s packaging system doesn’t work like that.
I guess it’ll be a thing of the past when all systems use the new open source Nvidia driver, but there are still a lot of GPUs out there that aren’t supported by it.
Me too bro. Me too
In the same way some GUIs are trash, lord have mercy some CLIs are trash. Things like adding two verbose flags makes it extra verbose. Things like the parameter order mattering. Yeesh. It can be rough. It really varies tool by tool.
Things like the parameter order mattering.
I imagine this is unavoidable in many cases.
Yeah, I guess that’s true. I suppose given more time to think about it I wouldn’t really complain about that. It’s mostly things like
script in outthat are sort of annoying versus something likescript --in foo --out bar.I believe API (CLI or programmatic) should never have 2 arguments of the same type but different roles next to each other without visual cues.
No
fn("in.txt", "out.txt")and noscript in out
two verbose flags makes it extra verbose
tcpdump intensifies
But what tool did you have in mind?
I like GUIs if they aren’t web browsers pretending to be a desktop applications.
I CAN interact with CLI, but i WANT to interact with good GUI. I don’t want to learn CLI commands when I don’t have to. Especially in the cases where I use it rarely
Are you kidding? There’s nothing I love more than hand typing a 400 character file path.
fish
Tab?
Yeah and that’s totally fair enough, but people who like using a command line and know the tools well rarely if ever have to type out long paths or commands. Tab completion and history suggestion (especially in a modern shell like fish or zsh) is a joy to use, and doesn’t just do file paths but command options and arguments. Man pages are very overwhelming at first, but if you’re practiced at scanning them, then it’s a lot more convenient to get the info right where you are than to navigate to another window. But the learning curve is steep and I get why someone wouldn’t want to bother.
let’s compromise with a TUI
The main advantage of CLI is that its easier to instruct people on what to do and easier to get answers from people about how to use a CLI, and you can copy paste. If you know how to use the GUI though it can be a powerful tool as well.
Good GUI are hard to make while a good cli is rather easy.
Nothing wrong with a GUI that does what it needs without fluff.
The cli has one other benefit which I think is rarely recognised: it’s pretty easy to tell someone you need to run “xyz -a -b -c” (bringing the safety risk with it to be fair), but it gets a lot harder to be like “so in the top left there is a cog button that opens a panel on the right where you’re looking for the 2nd tab and there’ll be a checkbox”.
The things I appreciate even more than a good gui are programs with a good gui and a cli.
A well documented CLI is easy to generate a GUI from.
Wait what?
Most screen recording programs are actually just ffmpeg in the back.
Well can even make a little Custom Floating HTML Prompt in Keyboard Maestro to push commands to a CLI - just one way
I don’t know about well documented, but if you use a standardized argument parser, you can even generate a gui from that.
Good UX is the best, whether that’s CLI or GUI. UX is under-appreciated.
It is very easy to tell someone type this and shut up. I’ve never seen an explanation of why -a -b and -c are necessary or what they do. Although I recognise that a lot of people just want magic, and running “xyz -a -b -c” is the next best thing.
I would love to see what cli commands the gui uses, they would be much easier and faster to learn.
That’s one of the things I like about yt-dlp-nis on android. You can select all the options you want through the UI and grab the resulting yt-dlp cli command.
As the other comment says, use TLDR. it doesn’t tell you everything, but it does usually explain the most common uses. If you need something more advanced than you need to do more research anyway.
While it is an improvement, it’s aimed at people that already knows the commands.
For example:
- Extract a (compressed) archive file into the current directory verbosely:
tar xvf path/to/source.tar[.gz|.bz2|.xz]
What is that [.gz|.bz2|.xz] at the end? to someone that knows the tool it’s too obvious to even think about, to anyone else, it’s just there to mess with you because there’s zero reference to it and some examples include it and others don’t.
- Extract a (compressed) archive file into the current directory verbosely:
Grsync too
man xyz | grep -E "^ *\-(a|b|c)"More cryptic commands to the rescue! Lol
alternatively try tldr, which lists the most common options and explains them. It’s a livesaver for noobs.
Edit: oh i see it was already recommended lol
And dude has changed icon set, so its not a cog, its a wrench and screw driver
It’s also far easier to automate and use a CLI in a script - as long as it isn’t a TUI.
Also CLI are more accessible for blind people.
Tbh a lot of things are just easier to show/explain with images and icons in addition to text.
And in many cases mouse control is just super handy and fast
And while a terminal can show all these things… its just not comparable, IMO.
I wouldt want to write my job application in the terminal, or design a product, or whatever else requires just a smidge of graphics
I’m just a faster typer and when I have to go back to the mouse controls I feel sluggish. Of course, the right tool for the right job, I will never find myself with a tui to manipulate 3D objects or editing images but I will go to vim for editing documents using latex
OpenSCAD would like a word lol
LaTeX and Typst enter the job application chat
Yea that made me laugh; I just updated my resume from LaTeX to typst a few months ago actually
I’ve had my resumé in JSON for years, and in XML for years before þat. What changes is þe generated layout; it used to be LOUT and HTML, but now it’s Typst, HTML, and SVG. SVG is web-embeddable while preserving þe formatting.
I’m sad jsonresume.org never really caught on, because most companies require uploading a document and you still end up reentering an entire resume in web forms, a process which I loath.
“I am the commander of the CLI! The CLI Commander!”
So true. I mostly live in the embedded world but have had to write GUIs from time to time, mostly to connect and send commands to some sort of embedded device.
I always start with a cli version for testing and then write the GUI. A quick wrapper around the comms library and I’m done.
But there are so many annoying fiddly little details in the GUI to deal with that it usually takes as long just to write the GUI as it does the entire rest of the code. Layout, menus, tooltips, icon choices, dealing with screen sizes, DPI, resizing windows, responsive data, etc.
Edit: A simple example that I’ve dealt with many times is reading and writing config data. For the CLI version it’s typically two commands:
‘tool read_cfg’ reads from the device and prints the config to stout
‘tool write_cfg’ reads a config from stdin and sends to the device.
Add a ‘-f’ option to use a file instead of stout for people that don’t remember how to use redirects. Add a couple of documentation sentences to the help command. If there are any issues, print them to stderr and bail. If the user wants to edit the config they can use whatever $EDITOR they prefer.
The same functionality in a GUI means that you have to first implement an editor for values. In my case that was generally a bunch of nested key/value pairs so I could probably find a widget that would work. And then understand how it handles being resized, gets styled, uses tooltips, etc. Of course there would need to be some code to get the data into and out of that widget which would probably need massaging. Then I need to let the user know if there are local edits. And then there is the fact that the data is now in three places, on a local disc, on the device, and in the editor and I need to communicate with the user that there is a difference between loading and saving from disc vs the device. Do I give a warning that loading from once place will overwrite anything they’ve changed in the editor? How do I make the four load/save buttons have obvious icons? And how to handle errors? An annoying pop up? Partially load the data? Something else? So many little things that have to be designed, implemented, and tested.
