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 my best advice would be to make a philosophy out of it. Learn how to solve every problem you come across with the CLI. Only use Google or ChatGPT when you hit a wall, and utilize the man pages to understand why the answer works.
Make a habit of automating common tasks using shell scripts. Over time you’ll accumulate a library of cookbook code for doing common things that you can always refer to. Write comments in them to save time when you come back and refer to them. It also saves time to automate common things.
Long ago I followed the Linux From Scratch guide and it was very enlightening. It walks you through installing a working Linux system from scratch, starting from within another installation. So you could e.g. install Debian to a VM, add a second virtual hard disk, and follow the guide to iteratively install each bit of the system on the second hard disk until you can boot it and use it. This is an intense (or at least time-consuming) process but it’s worth it.
Although it’s terribly outdated now, I got a lot out of the book The Unix Programming Environment. It lays out the history of the system really well. In general, anything written by either of those two authors (Kernighan in particular) is just gold, they’re both excellent teachers. It helped me intuitively understand concepts like pipes, “everything is a file”, shell programming, awk, etc.
Another good resource IMO: Linux Journey
GUI is hard to build right and expensive to build at all. CLI tools is much cheaper to build and can be scripted. Microsoft is rich that’s why they can build GUI, and even then sysadmins have asked for Linux type of CLI tools so they can automate. So generally unlike consumer tools, sysadmin tools focus on utility instead of ease of use.
Windows is still using unresizeable letterboxes in many of their administrative interfaces so I wouldn’t consider it a paradigm example
A lot of Linux deployments are in situations were a gui would use more resources than the application. There is also decades for knowledge of troubleshooting from the cli would have to replicated for a gui solution to take off. That being said cockpit is getting really good and is ansible for most repos
Combine that with the fact that most experienced admins can work a lot faster in a CLI compared to GUI, and the fact that a CLI allows you to replicate previous actions with no effort.
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.
There aren’t many because there is no request (“market”, if you will) for them.
OpenSUSE has Yast which might be what you are looking for (“might” because, despite using tumbleweed, I never used it and I even actually uninstalled it).
I always recommend opensuse for ex-windows admins because it’s stable, long term version (don’t need to move to a rolling model that tends to confuse people), but most importantly YaST. It’s a big ol do everything GUI for managing the system
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.
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.
Building a gui app is building a console app and adding a gui on it (in this specific case). Since the people building the admin tool just want it to work, they stopped when the console app worked.
Also, as someone working with servers a lot, servers don’t have screens. We always always always ssh into them, so graphical tools would be useless to us.
It mostly comes because a linux system is essentially a collection of much smaller programs that do one simple thing each, and each of those programs has alternatives.
So doing a gui for one program would allow you to control that one and not the others, and if you were using an alternative, you wouldn’t have that gui.
Now trying to make a gui that agglomerates the most common ones has been done for userspace, mostly on specific distros… but when it comes to administering systems… it’s a different story.
services, dns, ntp, boot, wm, lm, firewall, dhcp… all of these have important things to touch, but also have different programs that implement them.
Most authors of these programs don’t bother with gui, mostly because it’s quite some work, but also because it’s not their problem. UNIX philosophy is very much do one single thing and do it well… and when you can do a simple CLI that allows users and PROGRAMS to communicate with your program, why bother with GUI if it only accommodates one part of that equation?
Devs don’t bother with GUI not because they think it’ll be useless, but because it’s a lot of extra work for something that ultimately will be less reliable than CLI…
One reason why linux is so good at doing servers is that no system software needs a GUI to work. Windows server has a headless version, but look how many applications are just unable to run on it as they all rely on GUI…
So in a way, having CLI first and GUI second is a blessing, even if it makes the first approach more difficult for users.
You probably got your answer from system administrator perspectives, but I’ll put mine in as a developer perspective who also developed some niche admin tools like SELinux Editor.
TL;DR: It require reinventing GUI on Linux and no, I’m not joking. I’m working on it as it is leveraging Vulkan by default.
@[email protected] did a good job laying out on some of the issues that arise from GUI Toolkit that we currently have on GTK and QT which are the two mainstay GUI on Linux. One of the problem is the lack of automatability in GUI, but it can be solved by establishing an Interprocess Communication Protocol. With an agreed upon convention, you can subscribe events or issue commands such as clicking on button or whatnot and that allows for each GUI Toolkit to also interacts with one another as well. Think of Wayland, but for between GUI.
Some challenges are impossible in CLI, but possible in GUI, and those can be SELinux, Firewall, or other administrative tasks that require as many widgets, visualizer, debugger, or whatever available to aid you. So I think people here need to realize that there are significant merit to GUI workflow for administrative tasks.
So with the current GUI Toolkits that are available on Linux, most developers aren’t very inclined to use limited features offered by GTK and a difficult to use C++ GUI and so, some of them consider developing web application, but it comes with it’s own baggage too. This is kind of a no-win situation for those who are looking to make a GUI for Linux. This is one of my pet-peeves with Linux and why I am working on it.
If you are interested to learn more on GUI Toolkit situation which I am working on at this time.
On Linux, I’ll summarize the issues for GUI Toolkits:
- GTK Toolkit is written in C language with GObject that emulates Object Oriented Programming, but it is far from intuitive for average developers and the documentation can be incomplete. For most of you, it can be seen as something like a huge bloat.
- QT Toolkit is written in C++ language and have limited binding options for Python, it have other option like QML for GUI, but it’s limited in flexibility. This limits a lot of choices for your average developer, because most of them don’t want to touch C++ with a 10 foot pole. I certainly don’t want to either.
Why do I want to make my own GUI Toolkit?
- Foreign Function Interface as a first class - Whatever programming language you want, PHP, Bash, Brainfk, whatever, it should be able to interacts with my GUI Toolkit, period. Binding for your language can be done by reading FFI-JSON and generating the binding. FFI-Json is just a JSON file that describe all of the interfaces and datatypes in GUI Toolkit library for your programming language to bind to.
- More memory efficiency - Uses 1/3 as much RAM as QT and 1/6 as much on GTK, utilizes Vulkan Graphic API and you can switch to CPU mode if you want to avoid using GPU. (Swiftshader for those wondering.)
- Everything is designed for 64 bits sized data, like if you want to open a 100 GB text file on a random text editor in my GUI, no problem, the text editor is designed to be buffer-based.
- Actual documentation with examples. This should be pretty obvious, but I am still surprised to this day that most GUI Toolkit documentation are rather poor even with corporate funding.
- Solve the chicken and the egg problem when attempting to fork off X11 (This is something I am seriously considering.)
- Written in C with Object Oriented Programming Paradigm (Similar to GTK, but without GObject)
- Familiarity - The API is inspired from System.Windows.Forms coming from C#, if you know what it is, then this GUI Toolkit would be second nature to you. That the idea I’m going for. API similar to WPF would come after that.
Before you suggest that I should fork off GTK, that would means I would have to comply with GTK’s licensing, which is GPL 2 and my project will be licensed differently. Also the whole project is redesigned from ground up, so it wouldn’t make sense for me to overhaul GTK which would be twice the work I have to do.
Webmin and Cockpit, my dude
Linux administration often involves a lot of everchanging tools. How many GUIs would be needed?
And how do you represent a echo foo > bar.cfg (or any other such command) in a GUI? Unfortunately it’s not that easy. :(
OpenSuse has yast, but whenever I try to use it, I feel like I could have done it faster from the terminal.
This… everytime I tried to use yast I just stopped using it (and OpenSUSE) because it’s just frustrating, even if it works.
Well, that’s true for just about every administrative task you can take in a Linux system, not really a shortcoming of YaST. If you know what you need to do, and how to do it in the terminal, it’s almost always (probably actually always, but I can’t say with 100% certainty) faster to do it in a terminal. The purpose of the GUI is to be more accessible to folks not wanting to do everything in the terminal, and I think YaST does a pretty great job of that. It feels a little dated, and could certainly use a facelift and some additional love put into modernizing it, but it still serves it’s purpose very well, IMO.
Windows users always come to Linux and complain about what they are missing way before they understand what they have gained.
While this may sound harsh, it is accurate.
Windows users are accustomed to monolith apps that hide complexity. When confronted with a blank command line and hundreds of small tools, they wonder why don’t we have a shinny interface to hide all the cruft.
You need to study the Unix philosophy to understand why things are done differently.
Window users come here fed up that Windows 11 is still using MMC from the NT4 days, or that there are 5,000 piece of legacy cruft from years and years of different GUI toolkits or that X doesn’t work exactly like Y did in Windows even though they hate Y.
It’s just a natural maturation process.
Webmin is a web-based server management control panel for Unix-like systems. Webmin allows the user to configure operating system internals, such as users, disk quotas, services and configuration files, as well as modify and control open-source apps, such as BIND, Apache HTTP Server, PHP, and MySQL. https://en.wikipedia.org/wiki/Webmin
Wow, I had completely forgotten about this package!
