I understand the usefulness of the terminal and how universal it is for troubleshooting across distros. But can’t there be a way to make a nice graphical tool for the various admin level tasks that need to be performed?
Edit: Thank you to the outpouring of feedback on this. It has greatly opened my eyes to how much I don’t know about. I did see a couple suggestions though, so I’ll be sure to check them out.
I’ve been using Linux since ~1996; I used to wonder about this a lot.
The tl;dr answer is, it’s too much effort only to solve the problem of making life easier for new users, and it can be a disservice to users in the long run.
As others have pointed out, there are limited GUI tools for common administration roles.
Power users are much, much faster at doing things via CLI. Most administrative tasks involve text file management and the UNIX userland is exceptional at processing text files.
A graphical tool would have to deal with evolving system software and APIs, meaning the GUI tool would be on constant outpatient care; this is counter to the UNIX philosophy which is to make software simple and well-defined such that it can be considered “done” and remain versatile and flexible enough to live for decades virtually unchanged.
It wouldn’t be that much easier for things like network rules unless a truly incredible UI was designed, and that would be a risk since the way that’s implemented at the system level is subject to change at any point. It’s hard enough keeping CLI userland tools in sync with the kernel as it is.
It would need to be adaptable to the ways different distributions do things. Administration on CentOS is not always the same as it is on Debian.
And ultimately, the longer a user spends depending on GUI tools, the longer it will take them to learn and become proficient with the CLI, which will always be a far more useful skill to have. You’ll never learn the innards of containers or VPS’ if you only know how to do things from the GUI.
Well put. I do need to learn much of the basic workings of CLI. Any recommendations on how to approach learning?
I think its because a lot of this stuff is faster to do through command line. And people developing GUI tools are ones that are already good at CLI so they might not understand why a graphical tool might be needed and then ones that do, start learning CLI to program a tool and on the way might realize it’s just easier to console. Kinda where I’m at. Plus if there are many of the same tool it might vary in GUI and when giving someone instructions it’s easier to just say the command to type than to cover every possible variation of GUI environment. That’s my take on this.
on the way might realize it’s just easier to console. Kinda where I’m at.
Me too. Discovering lots of good tools are CLI, so just getting familiar with that instead.
What kinds of “various” admin level tasks are we talking about here?
A lot of desktop distros do have these kinds of tools in place. You can create and edit users and groups, set file permissions, create folders and files, download and update packages on your system, view disk usage, etc, etc. Shoot, specialized distros like gparted can be used to partition disks, or live boot a system to repair it.
But for a lot of things, building a GUI for the interface just takes so dang long to do, and takes so much more time and effort to get right than building out text commands, that it just really doesn’t make sense to make it as big of a focus.
Simple: because it goes against the KISS principle. The GNU tools that constitute the user interface to the system comes from a philosophy that started with Unix: simple tools, doing one thing well, communicating through “pipes” - i.e. the output of one tool is supposed to be used as the input of the next one.
Such philosophy allows to assemble complex logic and workflows with a few commands, automating a lot of mundane tasks, but also allowing to work at a large scale the same way you would work on a few files or tasks.
Graphical tools don’t have such advantages:
- UI are rarely uniform in their presentation or logic, as there’s so much way to present options and choices;
- Apple did something nice in the way of automating with AppleScript, but I’ve not encountered anywhere else. GUIs are rarely automatable, which means you’ll need some clicking and pushing buttons if a task has to be repeated - or the GUI has to be altered to be able to replay a set of commands for multiple items;
- interconnecting different GUIs so that they can exchange data is just impossible. You usually end up with files in dedicated format, and the needs to massage data from one format to another to be able to chain tasks from different GUIs
- more importantly, command line work with minimal bandwidth and tooling on the client side. Tmux, Mosh and similar tools allow to work with an intermittent connection, and have a very low impact on the managed system;
- in some specific fields - notably embedded and industrial systems - you just can’t justify allocating resources just for a graphical environment. On these system, CLI is as powerfull as on a full fledged server, and don’t requires stealing precious resources from the main purpose of the system.
Beware though: as time passes, Unix founding principles seems to get forgotten, and some CLI tools manifest a lack of user experience design, diverging from the usual philosophy and making the life of system administrators difficult. I’ve often observed this on tools coming from recent languages - python, go, rust - where the “interface” of the tools is closer to the language it’s written with than the CLI uniform interface.
