this post was submitted on 17 Feb 2026
86 points (92.2% liked)
Linux
62949 readers
376 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 6 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
GUIs just being front-ends for a CLI tool is a horrible idea. This is why most git GUIs fail so terribly. I have seen too many of those where all the buttons were just replacements for CLI calls. If it is just a front-end for a CLI, then why the heck not just use the CLI?
A good git GUI has not been designed to just wrap the CLI. Instead, it works with the structure of git (commits, branches, tags, etc), and builds around those from the ground up. Only once the functionality has been designed should the question arise: What CLI commands do we need to implement this?
Have you seen debugging in an ide, they usually just run gdb / lldb commands
I have barely any experience with raw gdb, but debugging is something that allows for a lot of contextual actions. Even just placing a breakpoint is simpler if you can click the line instead of copy-pasting the line number. But also evaluating expresssions while on a breakpoint, or a graph with an overview of all threads. I doubt these are straight-forward commands in gdb, and if they are, you need to figure out the exact parameters (like line number).
Furthermore, I have tried raw gdb once, and got super confused as to what I was supposed to do or look at. Yet every IDE makes it trivial to use debuggers. Learning the options available to you is much easier in a well designed GUI.
In general, I agree that you can always use the CLI raw, but a frontend is a lot more friendly for many. It's the reason some people prefer TUI over CLI as well (some people really like
lazygitandlazydockerwhich are just frontends wrappinggitanddockerCLI calls and presenting it in a TUI). A TUI/GUI can structure information in panels, it can be more context-sensitive and it can help provide visual representations of the operation.Also, wrapping CLI commands (whether through a GUI or a TUI) means the wrapper can automatically combine the commands in whichever way it's best for a particular goal, or more conveniently set up batch processing... it's helpful for people who don't like having to make their own scripts, or craft long oneliners.
Plus: lets say you have your computer hooked to your TV and don't have space for a keyboard (but can use a small wireless mouse on the arm of your couch), a GUI wrapper that allows you to perform operations with just a mouse can be very convenient.
I don't know what kind of GUIs are you imagining, but I've hardly ever seen 1-to-1 recreations to a single individual command (unless that command is extremely complex or a graphical representation would be actually useful).
Some examples:
Gparted creates a job list of terminal commands for the disk manipulation, but it presents a graphical representation of the disks before you actually commit to executing the commands internally, so you can see what would be the result of the changes in the GUI side before actually pressing the button that actually executes
parted,fdisk,mkfs,resize2fs, etc. (they do wrap the commands when it comes to executing the changes), without you needing to go through the steps and specific syntax of each of them on your own.There are wrappers to
ffmpegfor video editing or transcoding that some people find convenient for discoverability of the options available and/or to have a limited list of presets / sanitized options for those who don't want to bother creating their own scripts. Sometimes also showing video previews for the graphical representation (useful when the operation is about cropping the image, or picking the exact millisecond where to cut). An example is LosslessCut, they keep a log of the ffmpeg calls.. or maybe Shutter Encoder (press Alt+C to see the console commands).In Synaptic, the GUI package manager, pressing "Apply" calls the appropriate APT commands as a CLI app inside a VTE with the selection of the packages you have decided to add/remove/update, which you have previously selected in the listing that is generated from the GUI view of the app. Some people like having a graphical detailed listing which might be useful for conveniently browsing packages and seeing their detailed description, while still you get the raw information and accurate log from the installation that you would get when you are just using the CLI.