People have been complaining about the fragmentation in the Linux world since at least the turn of the millenium - desktops, admin tools, all kinds of other things.
Does it help to add even more fragmentation?
Does it help to ignore best practices and basic project management - things like the project’s scope, requirements, target audience, target platforms, limitations, discussions with interested parties?
Of course it’s more fun to just start merrily hacking away. It will deliver some code quickly. But will that code deliver the desired results? Nobody knows, because those required preliminary steps never happened. You can’t meet the goal if there is no goal.
I do not want to be the spoil sport, but I really ask myself what your goal is.
In this thread we are comparing three candidates: YaST > Users and Groups management, MaST Users &Group module and the equivalent of Cockpit. Above we see a screenshot of MaST. Here is YaST:
I cannot show you the same from Cockpit (until now I did not install it).
But it is clear that the two above are different in approach on how to combine and show the data.
My idea was that you want to make things (almost) the same in MaST as in YaST, so that system managers feel completely at home in MaST and know blindly where to click to get what they want. I assume that is what people want to have as they complain about the deprecating of YaST. Only the name then changes (but that can be undone with a soft link of course).
This is not the case. And I now wonder why one should change form YaST to Mast and not from YaST to Cockpit. Learning a new inrerface is to be done in both cases.
Original YaST is limited by its Ruby based UI framework. Its UI sometimes looks a bit strange because it has to align same UI layout across Qt5 GUI and TUI. MaST goes into a different way: Qt6, GTK4, TUI are independent, which allow using the design that fits the UI toolkit best.
The goal of MaST is to continue YaST’s major functionality. But we will do some UI changes. Changes are always happening. Even during YaST2’s lifetime, its UI changed a lot from beginning. For example, the firewall module is totally re-designed since firewalld replacing SUSEFirewall2.
MaST doesn’t mean to compete with Cockpit. People who like web UI, they use Cockpit. People who like Qt6/GTK4, they use MaST.
For old YaST users, MaST should be much easier to learn that Cockpit. At least the module is still called “Users & Groups”, not “Accounts” in Cockpit. MaST inherits much more things from YaST than it changed. However, Cockpit is a totally different thing to learn.
Just to clarify, I use Cockpit, but nothing web related about it, stand alone flatpak client… It doesn’t have all the plugins specific for openSUSE, but it’s a simple flatpak install and can manage multiple machines without any extra tooling on either the client system or remote…
Irrespective, for my use case it’s perfect, it’s stand alone, uses ssh and nothing needs to be installed on the remote system, I have RPi3’s, RISCV64 and multiple x86_64 systems, one client and I can manage them all from my desktop as my user.
If using the web based version I would still need to install at a minimum the cockpit-bridge on all my systems.
Wanna laugh? One of the people I locally support “hates” web apps ( never heard him explain why, but he is a youtuber fanatic ), and since ~6 months he is using cockpit with the cockpit-client-launcher happily ( read my Open Chat post ), and I am not going to tell him he’s using a web app. I don’t think the flatpak is no web app either, but never checked.
I use the (3) different interface types of the Cockpit tool: Flatpak, and using a browser via the “:9090” URL, and using the Cockpit Client Launcher. I jumped into Discover app and tapped on the Cockpit Flatpak and here’s the description:
"Web-based server interface via ssh
Cockpit Client provides a graphical interface to your servers, containers, and virtual machines. Connections are made over SSH, using the SSH configuration of the local user (including aliases, known hosts, key files, hardware tokens, etc).
The server needs to have Python installed, but the Cockpit webserver doesn’t need to be enabled, and no extra ports need to be opened. "
