I’m just a long time SuSE user since after Mandrake days… What is going to be the selling point of future SuSe builds [Leap 16.X] when YaSt is removed?
I feel without YaSt, the justification of SUSE is lost. Especially for us who have SUSE deployed for servers. We dont want to open port :9090 or others to use Cockpit for another system tool…
I’ve managed numerous linux systems and various infrastructure, alot of them RHEL clones and others SuSe, Either SLED or OpenSuse Leap/Tumbleweed.
We can just SSH to our systems and use yast for some configuration needs. This is helpful, saves time. Otherwise, we can just manually configure services or configurations.
I Feel Mryln is a waste of energy from the SUSE developers.
Unless YAST will stay, and Mrlyn will be the replacement for YaST2 [GUI].
What TUI function will we have for when we’re ssh. Or will we have to also configure ssh x11 forwarding?
Why Mrlyn… for sake of change… development cycle time? Why not improve on Yast2…? This will kill off a huge long term support base, when there are other RHEL clones/distro’s out there.
Is this due to the new management at SUSE and trying to become the next RHEL?
@distort3dpixel Hi and welcome to the Forum
So if you install the flatpak version of the Cockpit client on the machine your currently using for ssh. You can then login with this client using ssh.
It’s what I use here to manage machines on the local network. The added bonus is nothing needs to be installed on the remote system aside from setroubleshoot-server if it’s running SELinux…
Configuration of new Leap 16.0 installs can be done via profiles.
Wow, is everyone that indiferent or salty about YaSt? The immediate replies makes me feel YasT was never a “selling” feature or a great tool.
Ofcourse can install flatpak, or another utility. But Yast…works as a TUI…
Sure, we can manually edit files, or manually configure SSSD to join domains,etc. But… YasT removes some of the grievances.
I take it the ship has sailed and decision set in stone from those powers to be? No one, or community driven support can ignite the passion and keep yast going? Cockpit the way?
uh… ofcourse it is personal choice to use yast or any management TUI. Foreman, satellite, etc.
Perhaps I’m speaking to wrong crowd… more home-user, lab, personal? Regardless of use-case - yast was flexible for anyone. Yast2 - sure… that can go away. But YaSt TUI… welcomed.
Regardless, I get the sense that Mrlyn is the new, out with the old?
IMO - cockpit is garbage for management purpose. It’s like giving iPads to kids. Trying to be Windows Admin Center…? Or SUSE and new management trying to make it a RHEL replacement parody; given the IBM exodus? YaSt was a BIG differentiator as a tool on the distro. Otherwise… RHEL…? What is Mryln going to give us over any other GUI package manager that exists from other distro’s?..
Zypper is great package manager in its own, adding YasT gives another tipping point for some.
I wish @shundhammer would add opinion to this, given his long contributions and passion to various projects…
The reason YaST’s deprecation was not arbitrary is mostly about maintenance and relevance. The codebase is large and Ruby based, and few developers are willing to maintain it. There were many opportunities for people to step up and contribute, but without sufficient long-term support, keeping it viable became increasingly difficult. In reality, many modules are no longer needed in modern Linux, so the effort required to keep YaST working outweighs the benefits.
From a package management perspective, zypper (CLI) plus Myrlyn (GUI) provide everything most users need. Myrlyn preserves YaST’s key functionality, including package search, repository management, pattern and patch installation, version selection, and dependency handling, while using a modern, maintainable framework. We owe @shundhammer a debt of gratitude for his efforts with undertaking this project.
YaST is currently in the state “deprecated” – because, nobody, to date, has proposed that, they’re able to takeover the responsibility for the maintenance …
If, you’re maintaining servers then, without a central System Management environment, with local access to the server systems, effective management (and everything that means in terms of administrator {employee – a human being} time and effort and costs) is difficult.
I recall that, at one of the Cebit computer expos around 2010, Microsoft were proudly claiming that they had a system management product which could support about 50 or 60 Windows machines per administrator – at an adjacent booth, Hewlett Packard were quietly mentioning that their system management product could support about 120 UNIX® systems per system administrator …
You can examine the figures for the current SUSE system management tool for yourself – sufficient to say that, the number of machines supported per system administrator has dramatically increased since then …
X11 – on a server ???
Are you using Virtual Machines on your servers or, are do you prefer to use Containers?
And, for the case of a server, apart from routine Btrfs housekeeping and, applying software patches and updates and, inspecting the system Journal, is there really anything else to be done on a regular basis?
I can only think of remedial action in the case of an application failure and, YaST will not help you in that case.
And, the simple system management tasks mentioned above can be easily automated by means of scripts and systemd services.
Mrylyn is only meant to be a basic graphical interface for basic system management tasks for users who aren’t Linux/UNIX® system administrators.
Red Hat was acquired by IBM in 2019.
SUSE is currently not listed on the Stock Markets.
OK, correction taken and accepted – I should have taken more notice of the zypper info for Myrlyn.
Another point, for the case of servers, how often is package management a task which has to be executed by the system administrators? (Apart from package patches and updates … )
Are you using Virtual Machines on your servers or, are do you prefer to use Containers?
And, for the case of a server, apart from routine Btrfs housekeeping and, applying software patches and updates and, inspecting the system Journal, is there really anything else to be done on a regular basis?
I can only think of remedial action in the case of an application failure and, YaST will not help you in that case.
[quote/]
No, I’ve personally never used DE on a linux server - no need. You can, however configure x11 forwarding using SSH. IE: Forward over a gtk app to another machine using forwarding.
We do not run OpenSuse for our virtualization or hypervisors. Previously ran Ovirt/RHEV or pure KVM using virsh. Otherwise, been VMWare. Have leveraged Satellite and Foreman or awhile back Spacewalk for system provisioning and patching.
So we gain another GUI Based management tool… What will there be, if any for TUI based - a direct YAST replacement? We have to simply be okay with Cockpit and zypper. Just a change of what we were all spoiled with for this distro?
Given Myrln is GUI based off gtk - no way to run it on a server, not without x11 forwarding or using the mentioned flatpat on another system as a jumpbox or orchestration host.
Perhaps myself and others just need to accept that yast is dead going forward. I know myself and others feel a certain way with this going away and the shift to Mryln. Where will this position OpenSuse over all the other linux distro’s – it’ll then feel like … yet another RHEL clone with a better package manager.
YaST is on its way out. It’s only a matter of time. For Leap 16.0 / SLES-16.0, it’s already officially gone. Yes, you can do some tricks to bring it back to life in the NCurses mode on Leap 16.0, but that’s just a glitch in the matrix; don’t rely on it.
This would leave you with Discover in KDE Plasma or GNOME Software in GNOME, both offering you mostly the high-level applications that are tailored to that specific desktop; and the zypper command line.
This would be it. That was the plan. Nothing else. Nada. Gar nix.
So I decided for the 2025 SUSE Hack Week to “liberate” my good old YQPkg, the YaST Qt Package selector, so it could become a standalone program. I had written the first iteration back in the early 2000s, then later with SUSE 10.1 I did the port to libzypp.
That part had been sorely neglected for many years; there simply was never time to maintain it well. So much YaST stuff to do, so little time.
And then with the advent of 16.0 and the looming demise of YaST, I decided to take a sharp scalpel and cut this part out of YaST; it was a pure Qt high-level widget. But it needed some glue code to hold it together; loading and refreshing the repositories for startup (which had been done in YaST Ruby code before), and executing the package transaction, i.e. download and install the packages.
And so Myrlyn (initially named YQPkg) was born. Because I wanted it, and because I thought many users would want something like it, too.
Right now on Tumbleweed, they coexist: YaST sw_single, Myrlyn, zypper.
You can use them alternatingly, but if you want a GUI you will very soon realize that Myrlyn not only offers some extra features (zypper dup and zypper up equivalent, much advanced zypp history, advanced search features), but also received all those little fixes that YaST sw_single never got over the years, such as the package list and details views initially filled, subtle GUI enhancements to make it look less baroque and 90s style, a non-root read-only mode, and more.
I consciously decided against an NCurses TUI mode: This was the one thing that had always held us back in YaST. We always had to take into account that any UI also needed to fit into a 1968 VT-100 80x24 text terminal, and limit UI complexity accordingly. This is why we had to endure all the young “kewl” kids on social media complaining about the “ugly 90s look”.
For the package selector, there were actually two completely separate versions in YaST: YQPkg, the Qt version, and an NCurses version based on libyui-ncurses, the C++ widget set. It was literally duplicate work, and the NCurses version was not only more limited (because of the 80x24 minimum window size), it was also much more complex to implement.
I am not going to duplicate this again for an NCurses Myrlyn. There is always the zypper command line; it may not be as convenient, but it can do the same operations and more.
For servers, we (the YaST team) were told that our business customers would either use one of the one-to-many management tools like SUSE Manager (today known as SUSE Multi-Linux Manager) or one of Puppet, SALT, Ansible, Ignition / Combustion.
Whatever; I don’t know if this is an entirely realistic assessment of the situation.
But Myrlyn is intended for the openSUSE community. Business customers are welcome to use it as well within its constraints, but I will always be on guard against any attempt of enshittification just because some business partner wants to showcase their favorite proprietary package, or goes crazy with license pop-ups.
Case in point: There is already a license cache in Myrlyn that takes great care to present every OEM license (like NVidia) only once. If you already confirmed this exact license text during this program run, the other 29 packages that also want to display it will get it confirmed automatically without bothering you again.
I personally use Myrlyn all the time. I will do whatever I can do keep it well usable.
YaST on the other hand will go away some time in the not too distant future. It was good while it lasted, but everything must come to an end eventually.
Thank you so much for the detailed reply and stitching together from you previous posts. Greatly appreciate your hard work and dedication; especially given you saw the “writing on the wall” with the executive decisions.
I feel the powers to be are thinking like Broadcom, and purely focusing on enterprise level customers. This will put a big fork and segment the SMB world who rely on RHEL clones or OpenSUSE for their server infra. There’s also others who will pay for SUSE support and run smaller scale deployment of SLES.
Many of us system administrators dont care about what the “kewl” kids think. The 90’s looking TUI menu works great, pure functional… There is even the nmtui…
So for server use of Leap 16.0 and SLES 16, moving forward. Management will purely be driven by Zypper and Cockpit and third party orchestration/management tool stack… The decision is a paradym shift and perhaps a money grab for enterprise customers in that sector/vertical – have the current SUSE customers move to paid manager product.
Mrlyn only helps those that run Desktop Environment…
I’m beating a dead horse here. Myself and others need to accept.
Until the powers to be realize their decision and becoming yet another RHEL clone. I feel the new CEO is trying to revive RHEL within SUSE.
Sure, Mryln will be fine for regular desktop users and perhaps distro hoppers.
