YaST3 project (unofficial)

I have not used YasT for years.

gdisk, zypper, an editor (kwrite or vi) and a few more (e.g. useradd) are my main configuration tools.

The (big) advantage: If time should come and I would have to move on to another distribution I would find most of those tools available.

2 Likes

I think YaST like tools are some kind of exercise bikes. It is good for beginners. Once they settle down, they will learn deeper things like zypper commands, vim, etc.

4 Likes

Why would anyone use the internet to adjust the innards of their system? That’s stuff that should be done locally.

tom kosvic

You can run cockpit on localhost. So no internet involved.

2 Likes

What @susejunky said, I use ssh everywhere here, so it (flatpak Cockpit) just connects to the localhost over ssh. So only that service needs to be running on remote systems as well
 Likewise I tend to use su - however on a test system running the newer services it’s run0-sudo
 but I can still connect over ssh even with NoNewPrivs.

Thanks, your effort is appreciated. I still use yast a lot (firewall, services, bootloader, partitioning). You might want to take @shundhammer’s insights and also use AI start addressing those.

I had a look at the code and saw a lot of hard-coded UI setup. You can use AI again to refactor this into a UI description in terms of, say, a dictionary which is then wired up into the interface. This, I believe, would be required for making the code base maintainable.

You might want to have a look into pyinfra as a means of performing the admin tasks. This way, reproducible machine configurations could be created for free.

PS: the only relevant UI for me is the TUI. This allows to admin broken and headless machines.

Is TUI working for you?
I’m getting an error message:

Traceback (most recent call last):
File “/usr/bin/mast-tui”, line 3, in
from mast.tui.main import main
File “/usr/lib/python3.13/site-packages/mast/tui/init.py”, line 3, in
from mast.tui.cron import CronModule
File “/usr/lib/python3.13/site-packages/mast/tui/cron/init.py”, line 7, in
from mast.tui.cron.window import CronWindow
File “/usr/lib/python3.13/site-packages/mast/tui/cron/window.py”, line 14, in
class CronWindow(Screen):

<231 lines>

self.show_message(_(“Cron job updated.”), success=True)
File “/usr/lib/python3.13/site-packages/mast/tui/cron/window.py”, line 100, in CronWindow
def on_data_table_cursor_changed(self, event: DataTable.CursorChanged) → None:
^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: type object ‘DataTable’ has no attribute ‘CursorChanged’

I am currently focusing on Qt and GTK. The TUI is not reviewed yet (100% AI generated stuff), so it might not work.

Why Python?
YaST2 is mainly Ruby.

Python has official GTK (PyGObject) and Qt bindings (PySide). This means we can use everything from GTK and Qt with no additional efforts.

Ruby on the other side, is quite limited in native GUI bindings. Doing simple things can be very difficult. For example, YaST2 still uses Qt5, not Qt6.

Great news and I wish you every success as Yast2 was an excellent tool.

I feel that Yast set Opensuse apart from other distributions. The loss of it’s functionality is unfortunate and I miss it. I would fully support the development of a successor it it fit properly into the scheme of things.

Yast is still available in “openSUSE Tumbleweed”, though I don’t know for how long. Yes, it is gone from Leap 16. But Leap 16 is based on SLE, so perhaps it is really SLE that is set apart.

It’s part of life, that things change over time.

2 Likes

The name of this project has been changed to MaST following the advices here

Why both gtk and qt? :exploding_head: What does one not have the other has?

Regardless, even if I agree with @shundhammer I’m sure some people will look at this with some mix of hope/nostalgia.

(from a new user suse user who’ve never used it)

YaST used to support both GTK and Qt. Though in the end they give up GTK, I feel supporting GTK and Qt equally does make sense. Users can get native look and feel across all desktop environments. It is also a good chance for me to learn something new. I haven’t do much GTK before.

Yes, it is not going to be something that everyone needs. The world is changed forever. People are now listening music from Spotify or Apple Music. But vinyl records, cassette tapes and CD are still choices for some.

3 Likes

I think a good way to keep Yast intact would be to make a Yast looking interface to an app that would just call the current implementation of the same functionality of the old Yast function from wherever it may now be located. This is instead of constructing new functions. To me the best feature of Yast was that all the key system functions were in one place.

1 Like

What YaST modules did you actually use, that you cannot deal without, except Software since that is already covered in Myrlyn?
Are you aware that over the years a lot of modules were deprecated, because they could no longer meet modern standards ?

Anyway, I’d rather put my bets and hopes on world peace.

Over 15 or more years when I had some problem I used most of the Yast modules for one reason or another; maybe all of them. Hopefully, with Yast you fixed something and didn’t need to repeatedly use it. Ultimately, the goal would be that you never needed to use Yast. If you didn’t need to use Yast that was it’s raison d’ĂȘtre. If Yast usage went down that was a good thing but it was Yast success that made it’s usage go down.

But when you had another problem, everything you were likely to need to diagnose and solve it was in one place (Yast) and you didn’t need to look up where something needed was and search everywhere to find what you might need.

1 Like

That works in theory if all you ever use is SUSE distributions. But if you’re coming from any other Linux distribution, having to learn another tool for system management is a barrier to adoption.

This is IMHO a good reason to adopt tools that are more commonly used across distributions - so knowledge those who don’t use SUSE/openSUSE distributions have isn’t useless when switching.

While I don’t know for a fact the reasons why SUSE decided to deprecate it, it logically makes sense to me that if they want to grow market share in their commercial offerings, they would make it easy for prospective customers to migrate, and that means looking at the barriers to entry and addressing them.

What I do know is that this topic has been discussed to death over the last several months, and the decision to deprecate seems to be final. The option is for the community to step up to maintain it or replace it - and that’s what this effort is (as well as the efforts behind Myrlyn). So I say good for those who want to take that on.

But there’s little point IMO in pining for YaST2 to make a return and be the main admin tool in the near term. For reference, see every single discussion that has been had about YaST since it was announced that it would be replaced by Cockpit in Leap 16.0. :slight_smile:

1 Like