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.
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â
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.
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.
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.
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.
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.
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.