this post was submitted on 14 Jun 2023
9 points (100.0% liked)

Linux

48145 readers
894 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

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
AgreeableLandscape@lemmy.ml
nooter692@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
9
Why aren't there more admin level graphical tools available for Linux? Or if there are, what are they? (youtu.be)
submitted 1 year ago* (last edited 1 year ago) by jarredpickles87@lemmy.world to c/linux@lemmy.ml
27 comments fedilink hide all child comments
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] TheTrueLinuxDev@beehaw.org 2 points 1 year ago* (last edited 1 year ago)

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.

@steph@lemmy.clueware.org 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:

  1. 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.
  2. 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?

  1. 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.
  2. 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.)
  3. 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.
  4. 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.
  5. Solve the chicken and the egg problem when attempting to fork off X11 (This is something I am seriously considering.)
  6. Written in C with Object Oriented Programming Paradigm (Similar to GTK, but without GObject)
  7. 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. If we want to get GUI on Linux, we have to leverage GUI developer familiarity on Windows operating system to also find GUI on Linux just as intuitive. This is crucial if we EVER want to get GUI to take off the ground on Linux.

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.