MaST is an effort to continue YaST in a different way. Note: it is still in Alpha state.
In 0.0.22 version, we added Users & Groups management module. If you are interested, try it out and give some feedback!
WARNING: changing users and groups is very dangerous! Try it in a virtual machine is recommended!
Install from software.opensuse.org:
https://software.opensuse.org/download.html?project=home%3Aguoyunhe&package=mast
Install via opi:
opi mast-qt6
# or
opi mast-gtk4
Are there really only two users in that system?
And normally one differentiate also between “system” users and “local” users (and root should be part of the first and guo of the second category).
Usually, we only show users that can login. Here are some other users, like wwwrun user of Apache. But they are usually not configurable (can break system). So they are not shown in the user list.
If only root is a special user, I think pin it at top is enough. I can additionally add red color to root username, which make it more obvious.
It is your project, but what you use as arguments is against the convention.
I didn’t know such convention before. Can you share some screenshot examples of categorized users list?
It’s available in the YaST User and Group management module. The one which you try to “revive”. There is a dropdown to show all system/local/LDAP/user defined list of users.
I see. Will add this feature in next version.
As @hui says. I thought you used YaST Users and Groups as a starting point.
But as I said, it is only a convention. No significance to the system (kernel) all. And as it is difficult to prove a convention with a screenshot …
Users with UID < 1000 are so called “system users”, they are created for certain system programs (e.g. daemons). Mostly blocked for real login (which is easy to see, they have e.g. in the shell field /bin/false or /usr/sbin/nologin
Likewise for groups. The convention is now also GID < 1000, but it earlier was GID < 100. The last seems to be the case in the system your screenshots are from, the GID of the non-system group users being 100.
That said, I am willing to explain a bit about Unix/Linux basics, but when you are trying to make a system management tool without basic knowledge, you will have a hard time (like @shundhammer explained in the other thread).
Do you really want to support 32bit?
Also make sure you look at fixing the build/rpmlint warnings…
“6 packages and 0 specfiles checked; 14 errors, 245 warnings, 40 filtered, 410 badness”
https://build.opensuse.org/package/live_build_log/home:guoyunhe/mast/openSUSE_Tumbleweed/x86_64
I’d go even further: The business logic is the core of an admin tool. The next level is the presentation (the user interface and its usability), i.e. how to make the technical details approachable for a normal human. Then there is the UI implementation which is the easy part.
Creating (and maintaining) a good admin tool means to master all those levels.
Never rely only on color to show anything important: A good portion of all users is color blind (8% of all men, 0.5% of all women). And that doesn’t even include other kinds of visual impairment.
Color can be used as an additional cue for those who see it, but there always needs to be an alternative way to show that information.
After thinking about all the stuff HuHa wrote, i stumbled over several things.
What is the intention behind this project? Many of the functions you try to recreate with Mast, are well maintained available in Cockpit. So you spend energy for modules and functions which are already existing and are maintained already by a lot of ppl.
As you seem to have some coding skills, why not helping develop Cockpit further? It is growing day by day but for sure some modules are missing. You could spend your energy with providing the new Cockpit modules. They even have a extensive documentation how to code and develope for Cockpit. So your start would be really fast.
The benefit would be: you are not the only maintainer. You would have help from a big community. You wouldn’t ride a dead horse. You wouldn’t try to recreate already existing software modules.
Oh dear… 
On Tumbleweed using kgx, when I ssh to another system the Title bar turns purple (for me…), then if I switch to root user (I’m using account-utils and enable NoNewPrivs) I now get a red (for me…) circle in the Title bar…
@guoyunhe The best person to ask on the MaST-team ( horrible name btw, open invitation to … jokes ) would be @shundhammer, no one in the openSUSE Project will be better fitted. And I bet € 100 that he will not redo 30 years of work that an entire team did.
Meanwhile @hui has posted, I was going to write ~the same. And, I would add some advice from experience: don’t burn yourself out on this. Even if you get let’s say the most basic YaST modules rewriten, you will carry the burden of maintenance in a continuosly changing world of what you need to support. Personally I’d rather attempt to write a completely new architecture independent kernel ( which I’d call “kore” from scratch in binary APU instructions, though the guarantee for failure would only marginally bigger.
Yes, @shundhammer is right about that.
I’m not color blind, but I do have abnormal color vision. The first thing I do after installing linux, is try to work out how to disable the coloring which makes it hard for me to read.
I made the same suggestion here (in the first topic they created on the subject)…
I don’t understand the criticism and the bashing going on here. Do some people here feel slighted because, well, not everyone wants Cockpit after all? Because there are probably still loads of people who miss YAST and would prefer to use it?
Let’s just let him get on with it. I think it’s brilliant. And I’m keeping my fingers crossed that it’s a success.
And if not, his efforts are still worthy of praise.
It’s definitely worth a try.
You misunderstand.
There is only technical and organizational comment on the project.
And people try to warn for the challenges that such a project offers .
In other words: please do not take this too lightly, else you will end up very frustrated.
Well, I don’t see criticism nor bashing. None. Unless in your dictionary “realism” and “caring warnings” are synonyms to those.
About 35 years ago, a similar opinion was sometimes raised in connection with a project by a certain Mr. Torvalds questioning why one should not simply improve Minix instead. Sometimes, it can indeed make sense not to follow the default path.
